Legacy ImageMagick Discussions Archive

It seems that "-colorspace RGB" and "-colorspace sRGB" don't work anymore in the current binaries..?
Using IM v6.7.5-1 Q16, on Windows XP.

That means that operations can't be done in linear RGB space. But of course the 'regular to RGB' conversions aren't possible either with that version.

Examples:
convert logo: -colorspace CMYK -colorspace RGB logo2.jpg

convert logo: -colorspace YCbCr -colorspace RGB logo3.jpg

"-colorspace RGB" (and "-colorspace sRGB") change only the colorspace flag right now, but don't convert the pixel values (so they behave sorta like "-set colorspace RGB"/"-set colorspace sRGB").

Is this already known? I saw that Anthony wrote something about these new problems.

Besides, in the changelog for v6.7.5-1, I don't understand that line "Correct sRGB colorspace conversion equations.". (I don't have any problem in v6.7.5-0.)

IM 6.7.5.1 Q16 Mac OSX Snow Leopard

For me -colorspace seems to change the image data.

convert rose: -colorspace cmyk rose_cmyk.jpg

The image is very dark but the colors have changed. I cannot say that it is correct or not. But I don't recall such change being so dark.

However, -set colorspace errors out.

convert rose: -set colorspace cmyk rose_cmyk.jpg
Segmentation fault

"-colorspace CMYK" is alright. But try to convert it back with "-colorspace RGB"...

"-set colorspace" is also alright for me. Of course, you chose an extreme example by setting a 4-channel colorspace when you have only 3 channels.

(Sure, crashes of the encoder or 0 byte output files without a warning message should be avoided.)

Drarakel wrote:"-colorspace CMYK" is alright. But try to convert it back with "-colorspace RGB"...

"-set colorspace" is also alright for me. Of course, you chose an extreme example by setting a 4-channel colorspace when you have only 3 channels. (Sure, crashes of the encoder or 0 byte output files without a warning message should be avoided.)

Yes, you are probably right about -set colorspace cmyk. I was not thinking about that. But I think it should exit more gracefully without a segfault.

You are also correct and I can confirm rgb->cmyk->rgb colorspace conversion does not work correctly:

convert rose: -colorspace cmyk rose_cmyk.jpg

which looks too dark to me.

And
convert rose_cmyk.jpg -colorspace RGB rose_cmyk_rgb.jpg

which looks more like what I would have expected for the correct result from just doing -colorspace cmyk on the original rose: image

I also reported this problem, though more directly.

Previously the conversion to sRGB (actually to linear RGB in IMv6) works but the conversion back using -colorspace RGB (actually sRGB) either by the option or automatically for GIF/PNG saves, fails.

That is the example of Resizing with colorspace correction is now failing...
http://www.imagemagick.org/Usage/resize ... colorspace

Code: Select all

  convert earth_lights_4800.tif -colorspace sRGB \
          -resize 500  -colorspace RGB  earth_lights_srgb.png

The result was very dark...

UPDATE! As of IM version 6.7.5-1 suddenly -colorspace sRGB also does NOTHING except a flag change. That is the above example how produces the same result as is NO colorspace correction is being done.

NOTE the reason that colorspace fixes was postponed to IMv7 was that it would introduce changes that are different to any IMv6 script that uses colorspace correction. Making thes changes now is not in my thinking a good idea (their will not greater changes in IMv7 colorspaces, than just fixing the RGB/sRGB colorspace naming)

See discussion, Colorspace handling and the future of ImageMagick
viewtopic.php?f=22&t=20270

anthony wrote:NOTE the reason that colorspace fixes was postponed to IMv7 was that it would introduce changes that are different to any IMv6 script that uses colorspace correction. Making thes changes now is not in my thinking a good idea (their will not greater changes in IMv7 colorspaces, than just fixing the RGB/sRGB colorspace naming)

I have no problem with that. (And I'm already excited about IMv7.

)

anthony wrote:Previously the conversion to sRGB (actually to linear RGB in IMv6) works but the conversion back using -colorspace RGB (actually sRGB) either by the option or automatically for GIF/PNG saves, fails.

But that puzzles me. Which version showed that problem? The automatic conversions back to 'RGB' weren't done anymore, sure (though that change was made many versions ago, I guess). But personally, I always did that manually - and "-colorspace sRGB" AND "-colorspace RGB" always worked for me in the last months. That includes version 6.7.5-0.

Side note:
As we said, there are no automatic conversions anymore since some versions, so IM's internal 'sRGB' is allowed to be outputted directly (without the "-colorspace sRGB -set colorspace RGB" trick). But that has also the effect that - with output format PNG - the PNG coder apparently gets that 'sRGB' string and now tries to write a sRGB chunk! With the earth_lights example:

Code: Select all

convert earth_lights_4800.tif -colorspace sRGB -resize 500 test.png

convert.exe: Invalid sRGB rendering intent specified `test.png' @ warning/png.c/MagickPNGWarningHandler/1754.
That's just wrong. Not only because there's no valid rendering intent (value 255=unknown), but mainly because it's no sRGB!

The example doesn't always work that way with pictures that already have a sRGB profile - like the logo: image. As the PNG coder writes a normal sRGB chunk there (be it with "colorspace RGB" or with "colorspace sRGB"). And of course, I had to use version 6.7.5-0.

However - perhaps that's a thing for IMv7 - if the "colorspace sRGB" (and I mean linear RGB here) should be allowed for direct output, IM could change its internal gamma setting to 1.0 here, and the PNG coder could write a gAMA chunk with that value (and no sRGB chunk). Not every software uses that information - but the Windows picture viewer or Firefox for example honor the gAMA chunk and apply a gamma correction to 2.2 (usually good enough for quick display).

I thought that was because -colorspace RGB was broken.

That was what first broke, also relativity recently (probably 6.7.4-7 or so as a guess) then the -colorspace sRGB broke shortly after.

We can reproduce the -colorspace option problem you reported. Grab ImageMagick 6.7.5-2 later this evening and let us know if the problem is resolved.

After the latest update, SVN and v6.7.5-2 release, the rose and logo examples above are now working again.
That is to say conversion to a CMYK or YCbCr and back to RGB is working.

However the example of conversion to linear RGB for resize operation, as per...
http://www.imagemagick.org/Usage/resize ... colorspace

Code: Select all

  convert earth_lights_4800.tif -colorspace sRGB \
          -resize 500  -colorspace RGB  earth_lights_srgb.png

Is still coming out as if no colorspace correction was applied... That is...

Looks like for IMv6 both RGB and sRGB are now classed as the same thing!

For comparison... using gamma is a ganerally acceptable alternative way of handling sRGB - and seems to be the preferred method. It comes out as expected.

Code: Select all

convert earth_lights_4800.tif -gamma .454545  -resize 500  -gamma 2.2 earth_lights_gamma.png

As such gamma correction does work as expected.

ImageMagick assumes linear RGB as generally recommended or required for many of the image processing algorithms. A round-trip from linear RGB to sRGB and back to linear RGB should produce identical results to the original image. The sRGB colorspace conversions appears to work. Try convert earth_lights_4800.tif -colorspace sRGB -resize 500 x:'. Our reference for sRGB is http://www.w3.org/Graphics/Color/sRGB.

magick wrote:ImageMagick assumes linear RGB as generally recommended or required for many of the image processing algorithms.

That is understood.

A round-trip from linear RGB to sRGB and back to linear RGB should produce identical results to the original image.

Of course that would be the case, and is not a problem.

The sRGB colorspace conversions appears to work. Try convert earth_lights_4800.tif -colorspace sRGB -resize 500 x:'.

That is what is debatable!!!! It is not doing what it should be doing!

What should happen in IMv6 (and up to recently did)

The image read in sRGB it is not linear, though IM has marks it as being in 'RGB' colorspace it is really 'sRGB'.
Now -colorspace sRGB converts the image from sRGB to linear-RGB.
The image is resized in linear-RGB, and it is then convered back (internally) to 'sRGB' (IM marked RGB) for saving.

A few weeks ago the above command produces the equivalent result to doing the 'gamma correction example'.

The Gamma correction of 2.2 should produce almost identical conversions between sRGB input/output and linear-RGB.
As you can see you get a strong brightening of the 'lights' while the background remains the same.

The sRGB colorspace correction (such as the command you have given) does not do this. In fact it produces the same result as if no sRGB->linearRGB conversion are done. That is resize is being directly to non-linear sRGB data.

This is the complaint!!!! Something has changes and colorspace changes do not appear to be working as it has in the past!
Changes to this is for IMv7

See... IMv7 colorspace discussion, specific post....
viewtopic.php?f=22&t=20270&p=80690

Our reference for sRGB is http://www.w3.org/Graphics/Color/sRGB.

Understood. It basically says: images should be thought of as being sRGB, unless otherwise stated (by color profiles).
It said nothing about operations being applied to linear RGB data though that is a 'given'.

anthony wrote:I thought that was because -colorspace RGB was broken.

That was what first broke, also relativity recently (probably 6.7.4-7 or so as a guess) then the -colorspace sRGB broke shortly after.

I again tried every subversion of 6.7.4 (well, the Windows binaries). I didn't find a single version where "-colorspace sRGB" or "-colorspace RGB" failed. That change came only in v6.7.5-1 here. Strange.

magick wrote:We can reproduce the -colorspace option problem you reported. Grab ImageMagick 6.7.5-2 later this evening and let us know if the problem is resolved.

Thanks! It's of course.. better now. But the behaviour of "-colorspace sRGB" and back to 'RGB' has been reversed. Was this intended?

I mean, the names of the colorspace conversions were deceiving, yes. I said that, too. But I thought that all these colorspace changes should come only with ImageMagick v7? As Anthony wrote.

As things are now (v6.7.5-3), the names of the operations seem to be better. But the actual conversions have become even more difficult. The name of the default IM colorspace is still 'RGB', after all.
Operations in linear RGB have to be done like that now:

Code: Select all

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

magick wrote:The sRGB colorspace conversions appears to work. Try convert earth_lights_4800.tif -colorspace sRGB -resize 500 x:'.

But earth_lights_4800.tif is already sRGB. (Well, it's sort of an unusual picture, and there's also no color profile. But we still have to assume sRGB.) So, one makes a gamma correction 'on top' with that command.

anthony wrote:The sRGB colorspace correction (such as the command you have given) does not do this. In fact it produces the same result as if no sRGB->linearRGB conversion are done.

No - it does not produce the same result (at least not with my Windows version of IM). "-colorspace sRGB" now does a gamma correction from linear to non-linear. It has been reversed.
So, with that command:

Code: Select all

convert earth_lights_4800.tif -colorspace sRGB -resize 500 -colorspace RGB earth_lights.png

I'm getting this:

It's even darker than a 'direct' resize! That is, because this resize operation is not done in linear (s)RGB, not in sRGB with an average gamma of 2.2, but with a gamma of about 5 (2.2*2.2).
In order to do it in linear space, as I said, one apparently has to use "-set colorspace sRGB -colorspace RGB". (But I rather downgrade before I try to adapt my scripts. As I'm not sure if this was intended.)

The last answer has disappeared?! Anyway, here's my reply (to magick):

I didn't want to sound negative. After all, I'm very grateful for ImageMagick - and for the possiblity to do operations in linear space (with sRGB files). With many programs, that's not possible at all.

I didn't say that some operation returns incorrect results now. But the operations have been reversed. It now seems that it was intended that way (still a bit unsure).

magick wrote:Now lets convert the assumed linear RGB earth light image to sRGB:

convert earth_lights_4800.tif -colorspace srgb earth_sRGB.tif

Even if it were linear RGB - the command does nothing, as there is again the automatic conversion back to 'RGB' at the end (at least in my Win32 6.7.5-3 version). If one wants to save that 'sRGB' result, one has to use "-colorspace srgb -set colorspace rgb" here.

In my opinion, the earth lights image is already sRGB. I could try to prove that - but that's not the point.
Let's just assume that we have a sRGB image (with a sRGB color profile - though the metadata doesn't help here).

When one wanted to do operations in linear RGB with such an image, it was possible like that:
convert srgb_input -colorspace sRGB operations -colorspace RGB srgb_output
That was valid at least from october 2010 up to recently (with the exception of some 6.7.1 subversions). Sometimes, one could even omit the final "-colorspace RGB".

Now, with v6.7.5-2 or 6.7.5-3, it has to be (for the same effect):
convert srgb_input -set colorspace sRGB -colorspace RGB operations -colorspace sRGB -set colorspace RGB srgb_output
That's "all".

By the way, the "-colorspace sRGB" definition in the documentation still shows the old equations (the equations for converting values from non-linear sRGB to linear sRGB):

if Rs ≤ .04045 then Rs=R/12.92 else Rs=((R+.055)/1.055)^2.4
if Gs ≤ .04045 then Gs=B/12.92 else Gs=((G+.055)/1.055)^2.4
if Bs ≤ .04045 then Bs=B/12.92 else Bs=((B+.055)/1.055)^2.4

(And there is a small typo. It probably should have read "if R ≤ .04045", not "Rs ≤ .04045". The same for the other lines. Otherwise, one would have to know the result before one can compute the result.

)

Drarakel wrote:The last answer has disappeared?! Anyway, here's my reply (to magick):

I didn't want to sound negative. After all, I'm very grateful for ImageMagick - and for the possibility to do operations in linear space (with sRGB files). With many programs, that's not possible at all.

I didn't say that some operation returns incorrect results now. But the operations have been reversed. It now seems that it was intended that way (still a bit unsure).

Ditto. However I feel the operators should have been left as is. (except for 'conversion corrections).
IMv6 is very well settled with this technique. It is not new, and was first published on mailing lists and forums many years ago, in the early days of IMv6. At this late stage, I do not think it should change in IMv6.

It is only its inclusion in IM Examples late last year, and talk about making IMv7 handle sRGB colors in some of the most common formats, that sparked the current flurry of activity.

Legacy ImageMagick Discussions Archive

"-colorspace RGB" broken

"-colorspace RGB" broken

Re: "-colorspace RGB" broken

Re: "-colorspace RGB" broken

Re: "-colorspace RGB" broken

Re: "-colorspace RGB" broken

Re: "-colorspace RGB" broken

Re: "-colorspace RGB" broken

Re: "-colorspace RGB" broken

Re: "-colorspace RGB" broken

Re: "-colorspace RGB" broken

Re: "-colorspace RGB" broken

Re: "-colorspace RGB" broken

Re: "-colorspace RGB" broken

Re: "-colorspace RGB" broken

Re: "-colorspace RGB" broken