input Linear RGB specifiy output RGB or sRGB

[TedBaker]

I am working with liner RGB tiffs, with ImageMagick 6.8.9-9 Q16, I am trying to get my head around how IM works.

My conversions follow 1 or 2 scenarios

1. linear RGB input, output should remain linear RGB

for example:

convert infile.tif -set colorspace RGB -rotate 90 outfile.tif

I understand -set colorspace RGB will tell IM the input file is linear and not sRGB, but what will the output be?

2. linear RGB input, output should should be sRGB

how do I tell IM to do this?

[fmw42]

Look at identify -verbose yourimage and see what gamma you have after conversion. If gamma=1, it is linear. If gamma=0.4545, it is non-linear.

If you have linear RGB input and want non-linear output, you can do

Code: Select all

convert infile.tif -set colorspace RGB -rotate 90 -colorspace sRGB outfile.tif

[TedBaker]

Look at identify -verbose yourimage and see what gamma you have after conversion. If gamma=1, it is linear. If gamma=0.4545, it is non-linear.

Thanks that's most helpfull, except I am not sure my input which I thought was linear is actually linear, as it reports gamma=0.4545

Also I tried the following to see if I could create a linear RGB file for test purposes

convert earth_lights_4800.tif -resize 500 -colorspace RGB test_LRGB.tif

but the output still shows as gamma=0.4545 ?

What I am really struggling with is what is the difference between -set colorspace XXX and colorspace XXX, it's made even more confusing as I believe some of the old versions handles this differently.

Is there a good explanation that covers ImageMagick 6.8.9-9 Q16, examples etc?

[fmw42]

I do not think TiFF supports linear RGB. See https://www.awaresystems.be/imaging/tif ... ation.html.

convert logo: -colorspace RGB logo.tif
identify -verbose logo.tif
Colorspace: sRGB
Gamma: 0.454545

Using -set colorspace, just sets a colorspace flag to tell IM what the colorspace is, but does not change the pixel data. Using -colorspace changes the pixel data to conform to the desired colorspace as well as sets the colorspace flag.

[TedBaker]

Will have to think about that a bit more, but I thought the fact that ifa tiff reports sRGB it didn't actually mean it was encoded non-linear.

i.e. what's to stop a program writing an image stored in memory as linear straight to the tiff file without any gamma encoding. This is what I thought the two scanner programs I am using Vuescan/Silverfast do when you ask to create a linear scan file.

So maybe the gamma meta is also not correct, in this instance.

[fmw42]

That is possible. IM assumes that it is non-linear, I believe, since gamma does not seem to be stored in the TIFF meta data.

You can see this by comparing the output from:

convert logo: logo.tif

and

convert logo: -colorspace RGB logo.tif

The latter will be darker since the data is actually linear. But if you look at the gamma value via identify -verbose, it will still say sRGB, because TIFF does not store gamma or have a colorspace flag for linear RGB. But IM will assume it is non-linear and assign a gamma of 0.4545. It does not know better and assumes the most logical and most frequent use case.

If you start with true linear data and want to keep it linear, you should tell IM that it is linear via -set colorspace RGB, so

Code: Select all

convert image.tif -set colorspace RGB <processing> output.tif

will report non-linear gamma 0.4545 from identify -verbose, but actually be linear.

If you want to convert to sRGB and start with linear, then

Code: Select all

convert image.tif -set colorspace RGB <processing> -colorspace sRGB output.tif

should properly convert it back to non-linear.

[TedBaker]

Thanks,

If you start with true linear data and want to keep it linear, you should tell IM that it is linear via -set colorspace RGB, so

Code: Select all

convert image.tif -set colorspace RGB <processing> output.tif

This is what I thought too: which is why I thought

Code: Select all

convert image.tif -set colorspace RGB <processing> -colorspace RGB output.tif

would also be linear in and linear out, but I get some confusing results when I do essentially the same processing on an image except I -seperate and -clone before -combine, and there seems to be some colorspace conversion that I can't pin down.

if I -set colorspace RGB shouldn't IM when performing all read and write operations assume no conversion is required, and in addition -colorspace RGB
should not have any further effect as everything stored in memory is in the RGB already?

[fmw42]

If you separate and then combine, you need to tell IM what the colorspace is before combining and change it to what you want afterwards or it will assume sRGB.

Code: Select all

convert image1 image2 image3 -set colorspace <whatever it is> -combine -colorspace <whatever you want> result

see http://www.imagemagick.org/Usage/color_ ... nnel_other

convert image.tif -set colorspace RGB <processing> -colorspace RGB output.tif

In your case, I am not sure that -colorspace RGB on output is needed unless you are combining as processing. Then see above. In simple cases, it probably does not hurt, e.g.

Code: Select all

convert logo: -colorspace RGB logo.tif

convert logo.tif -rotate 90 logo_rot_1.tif
convert logo.tif -set colorspace RGB -rotate 90 logo_rot_2.tif
convert logo.tif -set colorspace RGB -rotate 90 -colorspace RGB logo_rot_3.tif
convert logo.tif -set colorspace RGB -rotate 90 -set colorspace RGB logo_rot_4.tif

All 4 rotated versions are the same - all linear. Since the input data is linear even though tiff does not know it, by using -set colorspace RGB, IM knows it is now linear as input. It will not change it for most processing. Combine is another story.

[TedBaker]

Thanks combine is a real Gotcha! I spent hours trying to figure out a behaviour that just wouldn't make any sense. Until I pined it down to something to do with -sepearate, -clone, -combine.

Code: Select all

convert logo: -colorspace RGB logo.tif

convert logo.tif -rotate 90 logo_rot_1.tif
convert logo.tif -set colorspace RGB -rotate 90 logo_rot_2.tif
convert logo.tif -set colorspace RGB -rotate 90 -colorspace RGB logo_rot_3.tif
convert logo.tif -set colorspace RGB -rotate 90 -set colorspace RGB logo_rot_4.tif

All 4 rotated versions are the same - all linear. Since the input data is linear even though tiff does not know it, by using -set colorspace RGB, IM knows it is now linear as input. It will not change it for most processing. Combine is another story.

But this 5th example does not behave as you would expect:

Code: Select all

convert logo.tif -set colorspace RGB -separate \
( -clone 0 -rotate 0 \) -swap 0,3 -delete 3 \
 -combine -colorspace RGB not_what_you_expect.tif
\ 

Any idea why -combine works like that?

Thanks again for your help!

[TedBaker]

Actually I think there is more to it.

-seperate seems to do the same thing.

Code: Select all

convert logo: -channel b -separate -colorspace RGB logo.tif

convert logo.gif -rotate 90 -colorspace RGB linear_in_lin_out.tif
convert logo.tif -set colorspace RGB -channel b -separate -rotate 90 -colorspace RGB not_what_you_expect.tif

what is the rule or reasoning?
Is it every time a new image is created it defaults to sRGB?

[fmw42]

Where does logo.gif come from?

These all work for me.

Code: Select all

convert logo: -channel b -separate -colorspace RGB logo.tif
convert logo.tif -channel b -separate -set colorspace RGB -rotate 90 test1a.tif
or
convert logo.tif -channel b -separate -set colorspace RGB -rotate 90 -colorspace RGB test1b.tif
or
convert logo.tif -set colorspace RGB -channel b -separate -rotate 90 test1c.tif
or
convert logo.tif -set colorspace RGB -channel b -separate -rotate 90 -set colorspace RGB test1d.tif

This does not give the correct result. To get the correct results, I think you need to -set colorspace after -separate, if you are going to add -colorspace RGB later. Otherwise, it applies a second change of pixels to linear.

Code: Select all

convert logo.tif -set colorspace RGB -channel b -separate -rotate 90 -colorspace RGB test1e.tif

This works again by adding -set colorspace RGB after -separate.

Code: Select all

convert logo.tif -set colorspace RGB -channel b -separate -set colorspace RGB -rotate 90 -colorspace RGB test1f.tif

As I mentioned before, -separate and -combine need to know what colorspace you are actually using.

Note that in c and d, I did not specify -set colorspace right after -separate, but then I did not add -colorspace RGB after the rotate. So it is not trying to convert pixels to linear a second time.

[TedBaker]

Thanks for your help, I studied your post, and I went thoroughly through the examples here https://legacy.imagemagick.org/script/c ... gement.php

I thought I had it all figured out, but some of the examples don't work as expected, is this a bug with my version of IM?, I am using ImageMagick 6.8.9-9 Q16 x86_64 (I went through the release notes for later versions of 6 and could not see anything obvious)

Specifically I followed this exactly

Code: Select all

convert myimage.png -separate myimage_channels_%d.png
convert myimage_channels_*.png -combine myimage2.png

In the above example, the result is darker than the original, because the channels were separate as linear gray and subsequently combined as linear color. In order to return the channels back to sRGB, one must change the colorspace from RGB back to sRGB after the -combine step

I did:

Code: Select all

convert logo: myimage.png
convert myimage.png -separate myimage_channels_%d.png
convert myimage_channels_*.png -combine myimage2.png

myimage2.png looks exactly the same myimage.png which according to the documentation it shouldn't

In addition the page states

Normally, the conversion to separate each channel of an sRGB color image produces separate linear grayscale images

an identify -verbose myimage_channels_0.png reports a gamma of 0.45455

So a bit confused now...

What should I get?

[fmw42]

Where are you reading your quote about linear grayscale. That was during a time from about 6.7 - 6.8.5. It could be still a remnant in 6.8.9, but I thought that version was past it.

This works fine for me on IM 6.9.9.20 Q16 Mac OSX, since IM assumes non-linear grayscale and -separate and -combine assume sRGB.

Code: Select all

convert logo: myimage.png
convert myimage.png -separate myimage_channels_%d.png
convert myimage_channels_*.png -combine myimage2.png

If that does not work for you on one of your image, then the image was likely linear. In that case, you must do

Code: Select all

convert myimage.png -separate myimage_channels_%d.png
convert myimage_channels_*.png -set colorspace RGB -combine myimage2.png

If you want to keep it linear.

If you want to convert from linear to non-linear

Code: Select all

convert myimage.png -separate myimage_channels_%d.png
convert myimage_channels_*.png -set colorspace RGB -combine -colorspace sRGB myimage2.png

It is always best to use -set colorspace to tell IM what you have after -separate and before -combine. Then use -colorspace after -combine to change colorspaces.

See
http://www.imagemagick.org/Usage/color_ ... nnel_other
viewtopic.php?f=4&t=21269

If you myimage.png does not work the way you think, then post it so I can review it and your command.

[TedBaker]

Where are you reading your quote about linear grayscale.

Here https://legacy.imagemagick.org/script/c ... gement.php its also on the page for latest version IM here https://imagemagick.org/script/color-management.php

Normally, the conversion to separate each channel of an sRGB color image produces separate linear grayscale images

Its definitely not working as explained in the documentation

here is the code again I executed several times to ensure no mistakes.

Code: Select all

convert logo: myimage.png
convert myimage.png -separate myimage_channels_%d.png
convert myimage_channels_*.png -combine myimage2.png

this is myimage.png https://ibb.co/k6AT1R and this myimage2.png https://ibb.co/fSUhT6 and they are same, when the documentation states the later should be darker.

in addition the gamma of myimage_channels_%d.png is reported as 0.45455, when it should be 1 according to the documentation.

At this point I would like to confirm that my version is "Wrong" and upgrade if necessary, as I think a workaround is counterproductive.

And just to confirm on IM 6.9.9.20 Q16 Mac OSX, myimage2.png was darker than myimage.png ?

[fmw42]

Normally, the conversion to separate each channel of an sRGB color image produces separate linear grayscale images. However the same concept can be applied, if it is desired to keep the separate channels as non-linear grayscale. For example, the following produces non-linear grayscale channels.

convert myimage.png -set colorspace RGB -separate myimage_channels_%d.png

To me this documentation is unclear as to what is being discussed and demonstrated. It does not read correctly if one is trying to convert non-linear image and separate into linear channels. So it could be a remnant from the time that grayscale images were linear and RGB and SRGB were swapped.

I will report the issue.

It should read:

Normally, the conversion to separate each channel of an sRGB color image produces separate non-linear grayscale images. However the same concept can be applied, if it is desired to keep the separate channels as linear grayscale. For example, the following produces linear grayscale channels.

convert myimage.png -colorspace RGB -separate myimage_channels_%d.png

In current versions of ImageMagick if myimage.png is non-linear, then

convert myimage.png -separate myimage_channels_%d.png[/quote]

will produce non-linear channels for myimage_channels_%d.png

This should be the case at least as of IM 6.8.6.0 as per viewtopic.php?f=4&t=21269#p104277