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
B) Image import/conversion filters that support your variety of
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 (http://www.imagemagick.org/) 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
Oliver Jones > Senior Software Engineer > Deeper Design Limited.
oliver@d... > www.deeperdesign.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the wlug
NOTICE: This is an archive of a public mailing list. The University of Waikato is not responsible for its contents.