Re: Simplified processing of image and rgbimage plots

[Ethan A M. <merritt@u.washington.edu>]

On Sunday 19 November 2006 05:47 am, Petr Mikulik wrote:
> 
> However, your generic fall-back is OK.

I want to clarify something.  This is not just a fall-back.
It is currently the only way to place rgb data in 3D.  

So not only does it allow additional drivers (svg, fig, emf) to 
handle rgbimage in 2D, it also extends the capability of ALL drivers
to work in 3D.

However, as you noted it is rather expensive to describe an image
this way, which causes slow data transfer in x11 and large file
size in PostScript and PDF.

We could do better.

PostScript supports the specification of a general transformation
matrix.  Rather than using individual filled_polygons
to draw a rgbimage in 3D, we could simply include a projection of
the 3x3 rotation matrix.  This would drastically reduce the 
PostScript file size for such plots.   We already calculate this
same matrix in the core code in order to place the polygons; in
the case of PostScript it would be sufficient to provide the matrix
to the driver along with the original 2D array of rgb pixels.

Anyone want to have a go a coding this?

I believe that PDF and SVG also benefit from this approach, but
I have not investigated fully.


Hand-worke example:

Here is the start of the PostScript image code produced by the
first plot in "image.dem".  I have added one line that inserts
a transformation matrix.  Try it yourself.

 %%%%BeginImage
InterpretLevel1 { ...
} {
  gsave
  1149 3738 translate
  5490 -3219 scale
  [1 -.05 0.1 0.7 0.05 -0.15] concat %%% general transformation matrix %%%
  128 128 8
  [ 128 0 0 128 0 0 ]
  currentfile /ASCII85Decode filter
  false 3
  colorimage
} ifelse





-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742