It looks like MIFF does not get automatically converted to RGB color space on save (like PNG), which does not suprise me. BUT to compound matters it does not read the internal to IM sRGB colorspace of the MIFF image when it is read back in.
Basically it is a bug, but one that comes from the wierd internal handling of colorspaces in IMv6
That is RGB is regarded as he default colorspace, it may be non-linear sRGB or it may be RGB.
but sRGB means that the image was converted from sRGB to linear RGB form, and should be converted back, when needed.
The above shows MIFF is 'loosing' the images sRGB status.
The use of the rings image during resize, is a good idea, though really all it is doing is showing the difference between 50% gray in visual sRGB colorspace, verses the results of a mathematical 50% gray in linear space.
You can get the same results resizing 'hash' pattern...
Code: Select all
convert -size 100x100 pattern:gray50 gray_hash.gif
convert -size 1000x1000 pattern:gray50 -colorspace sRGB -resize 100 -colorspace RGB gray50_sRGB.gif
convert -size 1000x1000 pattern:gray50 -resize 100 gray50_RGB.gif
convert -size 100x100 xc:gray50 gray50_math.gif
montage gray_hash.gif gray50_sRGB.gif gray50_RGB.gif gray50_math.gif \
-tile x1 -geometry +5+5 -set label %f -frame 6 grays_montage.gif
What image would you say most accurately visual representation of a pure mid-tone grey generated from a pure black and white hash pattern (the first one) . Step back or unfocus your eyes so that the 'hash pattern' blurs into a single color for comparison.
Actually on my monitor, I would say none of them. But then my monitor is not properly calibrated, and probably not even set to a 2.2 gamma correction. To me the color resulting from the hash pattern looks a little darker and a bit blue to my eyes. But the sRGB image is still a fair closer and more correct result.
NOTE the last image is just the pure mathematical 50% gray color, which shows that resize really is just a linear operation generating a mathematical 50% blending.
Side Notes...
NOTE: internally to IMv6, grayscale images are stored a RGB images. As such the above should not matter if the image is grayscale or not.
IMv7 will be introducing the concept of true one channel grayscale images, in memory.
Also note that the use of
-depth in the above is INCORRECT and only has an effect on the final image file format format. It is 8 bit by default (image input depth) due to use of GIF file format by definition!)
Depth is a setting controlling the integer size for raw input data (which do not provide depth information), or for output image file formats that can have different depths. It has absolutely no bearing on the computational size of the data in memory which is fixed by the compile time quality of Q setting.
see IM Examples, Basics, Quality vs Depth
http://www.imagemagick.org/Usage/basics/#depth
