Re: [Plplot-devel] full color images with plplot

[Rafael L. <rla...@us...>]

* Sergei Steshenko <ser...@ya...> [2005-09-05 12:07]:

> as I wrote, I am mostly interested in dealing with already existing images,
> not with plots.
> 
> Plots deal with few (relative to Xdim * Ydim) pixels, so computational inefficiency
> is not that painful.
> 
> Dealing with ready made images means dealing with Xdim * Ydim pixels, so computational
> inefficiency becomes very painful.
> 
> Plplot has a demo with monochrome "Lena" image - it renders painfully slow.
> 
> And if I or anybody else sticks to the same design/architecture, full color Lena
> will render 3 x painfully slow.
> 
> When I'm saying "painfully slow", I mean compared to other image viewers, like 'xv', for
> example.
> 
> I am not yet designing/coding anything, I am thinking.
> 
> I would like to implement extensive image processing in PDL - its core routines
> written in "C" appear to be well suited for this, and ImageMagick can be incorporated
> too - it already has Perl interface, and it would be interesting to implement PDL interface
> to it.
> 
> The practically missing part is image display - I mean, what exists today (pgrgbi) and what
> can be written in plplot framework is painfully slow.

I did not mean that the new true-color rendering function must be slow
and inefficient like the current plimage.  Much to the contrary, your
initiative may be a good opportunity to get things done correctly.

For the sake of the exercise, let us say that this new function will be
called plcimage.  One possible interface for it would be:

    plcimage (char* file, PLFLT xpos, PLFLT ypos, PLFLT width, PLFLT height)

This means: "put the image in file at position (xpos, ypos) and adjust
its width and height".

(Of course, this is just an example.  Bitmaps could be added either in in
world or in viewport coordinates, we could add a parameter for
controlling clipping, etc.)

The plcimage routine (included in the PLplot core and driver-independent)
would then read the file (could be in jpeg, png, or any other popular
format) and would create an internal, rasterized, RGB+alpha
representation of the image.  An external rasterize library should be
used for doing that.

After this internal pixmap representation is built, the core routine uses
a to-be-created PLESC* code to pass it to the drivers.  Each driver would
then be responsible to rendering the pixmap into the devices.

For some drivers (xfig comes to mind) it would be better to pass directly
the file name.  Nothing prevents us to create a new field in the PLStream
structure in which the driver will tell if it prefers a file name or an
internal pixmap (like dev_text does for native text support).

-- 
Rafael