Re: Simplified processing of image and rgbimage plots

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:
> Yesterday I committed to CVS a patch that Dan Sebald and I worked out.
> It removes many restrictions on the use of RGBIMAGE in 3D plots, and the 
> use of RGB color in polygons derived from image data. Now all terminal 
> drivers that can handle RGB colors and filled polygons can automatically 
> also handle image and rgbimage plot styles.
> 
> This extends the capabilities of svg, xfig, and maybe other terminals.
> 
> The specialized code for image handling could be removed from gd.trm, for 
> instance. Also x11. Is this worth doing?
> 
> The specialized image handling code in post.trm is still useful because it 
> drastically reduces the output file size, however.

I like this improvement, but I also suggest leaving the the broader image handling in place with the fall back to the polygon-based approach.  For x11, the image code is preferred from the standpoint of memory size and refresh speed.  For an image there is M x N pixel values and the location of its points and borders.  The same image as polygons is M x N pixel values and 4 x M x N pixel corner values.  More memory, more processing for the polygons (even though the code for polygon processing may be more straightforward).  The other thing that having all the image data in the form of one hunk is that if ever someone wants to improve anti-aliasing with the image, it would be possible.  With individual rectangular elements, signal processing on the image would be cumbersome.

For PostScript, there is the capability to place images at viewing angles.  (However, that terminal function doesn't have variables for that right now...  Hindsight is 20/20 I guess.)

For the bitmapped outputs like PNG and so on, it wouldn't matter if both the image routines and polygon methods produced the same output.  We could test that with a simple file diff, I think.

Dan