-colorspace no longer working

[phrosty]

I'm trying to resize images in a linear colorspace. This command was working in 6.7.0-10 and prior versions as far back (years) as I've been using IM:

Code: Select all

convert -colorspace sRGB earth_lights_4800.tif -resize 500x out.png

I've updated to 6.7.1 and now "-colorspace sRGB" no longer works. With or without it the image gets resampled in gamma-compressed sRGB, which results in incorrect blending.

I've been testing with NASA's "Earth's City Lights", because it presents a worst-case to bring out these blending errors:


Without linear processing the lights along the African and Australian coastlines are almost completely gone, while many other areas (like Western USA) are considerably faded:

[fmw42]

try this:

convert earth_lights_4800.tif -set colorspace sRGB -colorspace RGB -resize 500x earth_lights_4800_srgb.png

Is that what you want?

[anthony]

NOTE colorspace is a bit is an unusual command.

Most images being read in are already in sRGB colorspace. however IM stores them in memory as 'RGB' colorspace.
The -colorspace sRGB command does not actually convert to sRGB but from sRGB to linear RGB!
That is it makes the image linear for image processing. Yes that is the opposite of what you would expect!

See Draw and Colorspace - which are the examples that I used to 'discover' this weirdness!
http://www.imagemagick.org/Usage/draw/#colorspace

This is a hold over from older versions, and something that should be fixed in IMv7 which should correctly declare input images as sRGB by default, unless told otherwise. It should also be able to draw colors in the appropriate colorspace!

[phrosty]

try this:

convert earth_lights_4800.tif -set colorspace sRGB -colorspace RGB -resize 500x earth_lights_4800_srgb.png

Is that what you want?

Definitely not. My old command line performed a resize in linear RGB. This one seems to be doing something entirely different, brightening up the entire image:

[phrosty]

NOTE colorspace is a bit is an unusual command.

Most images being read in are already in sRGB colorspace. however IM stores them in memory as 'RGB' colorspace.
The -colorspace sRGB command does not actually convert to sRGB but from sRGB to linear RGB!
That is it makes the image linear for image processing.

This is how I was using it before.

Yes that is the opposite of what you would expect!

I've always interpreted it as telling IM "this image is sRGB, so blend correctly knowing that". It could definitely use a better description, though.

[anthony]

Yes that is the opposite of what you would expect!

I've always interpreted it as telling IM "this image is sRGB, so blend correctly knowing that". It could definitely use a better description, though.

Except that it only does this for sRGB. for other colorspaces, it goes 'to' the given colorspace.

For your resize you would use...

Code: Select all

   convert earth_lights_4800.tif -colorspace sRGB -resize 500x -colorspace RGB earth_lights_4800_srgb.png

The final -colorspace RGB is not needed as IM will auto-convert to that color space when saving to most image file formats.

Basically I regard sRGB and RGB swapped. This should be fixed properly in IM v7, when it is released.

IMv7 which should also allow correct use of colornames. Colornames are actually declared using sRGB colorspace values, but the draw operator draws in linear RGB colorspace, making colors (when you convert images back for save) wrong.

[phrosty]

That still has no effect for me. Does it work for you?

[anthony]

For your resize you would use...

Code: Select all

   convert earth_lights_4800.tif -colorspace sRGB -resize 500x -colorspace RGB earth_lights_4800_srgb.png

The final -colorspace RGB is not needed as IM will auto-convert to that color space when saving to most image file formats

That still has no effect for me. Does it work for you?

You are right it doesn't seem to have any effect at all. That seems to be a little strange to me.

Maybe it is some type of profile effect?

[phrosty]

You are right it doesn't seem to have any effect at all. That seems to be a little strange to me.

Maybe it is some type of profile effect?

I thought the same thing and tried with +profile *. Still nothing. I think it's just a bug.

I'm looking at the source and there were some small modifications to colorspace.c. I'm going to fiddle around and see if I can get it working.

[magick]

We can reproduce the problem you posted and have a patch in ImageMagick 6.7.1-5 Beta available by sometime tomorrow. Thanks.

[anthony]

I have now verified that my version of the command does not work and does produce 'brighter' results.

Resize without colorspace correction...

Code: Select all

convert earth_lights_4800.tif -resize 500 earth_lights_4800_direct.png

Resize with colorspace correction

Code: Select all

convert earth_lights_4800.tif -colorspace sRGB -resize 500x -colorspace RGB earth_lights_4800_srgb.png

I really should add this to the image resizing page!

DONE.. Resizing with Colorspace Correction (should appear in an hour or two)
http://www.imagemagick.org/Usage/resize ... colorspace

[henrywho]

There still seems to be some problem with gray images (no matter stored in a 8bit gray or 24bit color manner) in version 6.7.1 (Q16).

Take the famous 1000x1000 Ring1.gif as example:

Code: Select all

convert.exe Rings1.gif -depth 16 -colorspace sRGB -distort resize 100x -colorspace RGB -depth 8 rings1_small_direct.png

convert.exe Rings1.gif -depth 16 -colorspace sRGB -distort resize 100x rings1_small.miff
convert.exe rings1_small.miff -colorspace RGB -depth 8 rings1_small_miff.png

"rings1_small_direct.png" looks alright while "rings1_small_miff.png" looks very dark, as if it is still in linear scale. Even if I transcoded the GIF into a 24bit TIF or PNG, I got the same result.

I didn't notice this problem in the older versions (one or two months ago).

[henrywho]

I do expect the intermediate MIFF to stay as 16bit linear (I thought it always does).

What amazed me is that there is no error for 24bit color images (producing the final PNG in non-linear sRGB values). Yet 24bit gray images have the final PNG produced in linear RGB values (in 8bit depth).

[anthony]

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

[henrywho]

Perhaps I did not made myself clear enough. I have put the test files in http://www.mediafire.com/?qa0xmdc79e0zubr