University Crest

[wlug] X window programming

wlug archive index About the wlug list Mailing lists home
To The University of Waikato HomepageWaikato Home > Waikato Mailing Lists > wlug Info > wlug archives
Oliver Jones oliver@d...
Tue Aug 13 16:16:15 NZST 2002

And ImageMagick isn't just an image viewer either.  It provides an API
which you can use in other apps to do all sorts of image manipulations. 
>From your description what you need is (in order of importance):

A) A C/C++ linkable library that maintains API compatibility with your
existing library
B) Image import/conversion filters that support your variety of
scientific images
C) High colour display support
D) A more resource friendly implimentation.

There are a number of ways you could do this, some possible solutions.

1) You could write a wrapper lib which passes the image data to external
filters and display apps.  eg, filters that convert to PNG's and then
launch Eye of Gnome or whatever.

The downside to this method is that there is probably no way to feed
back mouse clicks or movement to the calling app (if they are needed).

2) Write external image conversion filters and use gtk+ & gdk-pixbuf,
imlib2 or similar in the lib to create a simple reusable display

I can't help you with any of this however as I've never written anything
for X Windows in C for either Qt or GTK+.


On Tue, 2002-08-13 at 13:51, Michael Cree wrote:

    Craig Box writes:
     > Surely there is a library that does what you're asking?  (As far as I can
     > tell from your message, it is just an image viewer).
    No, it's not _just_ an image viewer!  It is a C link library that provides
    an easy interface for the display of scientific images.  By scientific, I
    mean that images need not be unsigned byte (256 greyscale) or RGB (24bit
    truecolour) but may be signed integers (16bit or 32bit) or even
    floating-point (IEEE single or double precision).  Potentially
    complex-fields could be displayed too (but that is not currently in my list
    of desired attributes).
    The C library provides a function to initialise the display and another
    function to display an image. On calling the initialising function it
    performs a fork with one process returning to the calling program so that it
    can continue executing, and the other process maintaining the image display
    so that it can remain intact with cover/expose and other events.
    It also provides a very basic interface to return key presses and mouse
    moves to the calling program.  That's where the CPU waiting happens.  Churns
    up CPU time on a multiuser machine.  Not very polite!
     > If you give a bit more background on the application you need performed at
     > the end, someone might be able to suggest something that will do what you
     > want, short of porting the library you have. 
    I would prefer to use the library I already have - I have a reasonably
    substantial image processing library that depends on its function interface
    (but the display library is unuseable on the Compaq ALphas and now on Linux
    since we always use 24bit truecolour display now).  Admittedly, the
    interface to the image display library is partially abstracted and
    completely in one module, so an interface to another library could be done -
    but personally I would like to avoid that.
     > For example, the ImageMagick
     > library  ( does a lot of image processing and
     > display functions, and there could well be a viewer based on this that does
     > at least some of what you want.
    ImageMagick comes with the display, convert, identify and other programs.
    It does not support image types suitable for scientific image display.  I
    have just read the man pages and they make no mention of supported image
    data types.  I also attempted to display a TIFF image, that has an IEEE
    double precision floating point datatype (and the SAMPLEFORMAT tag
    appropriately set), with ImageMagick's display command and it failed.  I do
    not know of an image viewer - other than the one I wrote using the image
    display library which I would like developed further - that works on such
     Dr Michael Cree                Email:     cree@p...
     Dept. Physics and Elec. Eng.
     University of Waikato
     Private Bag 3105               Fax:       +64-7-8384835
     Hamilton                       Telephone: +64-7-8384301
     New Zealand

Oliver Jones > Senior Software Engineer > Deeper Design Limited. 
oliver@d...  >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the wlug mailing list
NOTICE: This is an archive of a public mailing list. The University of Waikato is not responsible for its contents.

The University of Waikato - Te Whare Wananga o Waikato