I've had some similar problems with gamma when savings images with
Save Image... as you did, and also with some other dataflows
(e.g. ReadImage/Overlay/WriteImage).
Up-front, I'll tell you I don't fully understand how/where/when DX
applies gamma. Hopefully someone that knows will speak up. But...
This may be related to what you're seeing:
./dx-4.2.0/src/exec/libdx/displayfb.c: _dxfinit_convert(1.5);
/* gamma=1.5 is suitable for frame buffer */
Could be that a 1.5 gamma is always applied for display, but not for
saving images via Magick, which would explain your results.
I suspect there's more too it as I've had to anti-gamma-correct read
images to get them to save with the correct intensities using
Overlay->WriteImage flows. This 1.5 gamma may be used for any float->ubyte
color conversion, as the comment of _dxf_initconvert suggests.
_dxf_initconvert looks to be called in only one place, so it appears
this mechanism is hard-wired for gamma 1.5. I'm not clear as to if/how
this ties in with $DXGAMMA, $DXGAMMA_*BIT, and $DXHWGAMMA.
Randy
J.P.Hagon:
|I'm trying to save some images using the ImageMagick interface
|but finding them much darker than they appear in dx. I thought
|this may be due to gamma correction problems. However, trying
|different values of gamma correction in the save image window
|menu had no effect when saving via ImageMagick (saving via the
|standard dx supported types such as MIFF, TIFF etc is fine).
|Since 4.2.0 no longer supports GIF directly, I guess this is
|also why my JavaDX images are also very dark - presumably
|JavaDX now produces its GIfs via ImageMagick. Any help much
|appreciated.
--
Randall Hopper (mailto:[EMAIL PROTECTED])
Lockheed Martin Operation Support
EPA Scientific Visualization Center
US EPA N127-01; RTP, NC 27711
