David Thompson:
|There is one other problem I've found with ReadImage colors. If you
|read in a 24 bit tiff, the colors become Byte colors [3]. Software
|rendering can handle these with no problem, but hardware rendering
|will barf on them. You have to convert them before sending them to
|Image for Hardware rendering. Guess its time to start getting some of
|these bugs posted to the bug database and update the bug database.
Probably so. To add more fun to the mix, I've noticed that if you define a
color map with byte[3] colors, software rendering generates garbage colors.
Didn't dig into it at the time, but I suspect there's a float * cast in
there without a type check.
Because of this, the ReadImage Magick mod I submitted generates a float[3]
colormap for colormapped images. This microscopy volume format converter
I'm working on has to do the same thing, even though it defines a ubyte[3]
palette).
As a reference when making future mods, can we assume that this list
defines all of the valid renderable color combinations?:
"colors" component "color map" component
------------------ ---------------------
UBYTE[3] <None>
FLOAT[3] <None>
INT or UBYTE UBYTE[3]
INT or UBYTE FLOAT[3]
"front colors" and "back colors" also apply to "colors" of course.
And for consistency, "opacities" and "opacity map":
"opacities" component "opacity map" component
--------------------- -----------------------
UBYTE <None>
FLOAT <None>
INT or UBYTE UBYTE
INT or UBYTE FLOAT
Would this be reasonable?
Randy
--
Randall Hopper
[EMAIL PROTECTED]
