Legacy ImageMagick Discussions Archive

This is perl, is it? I don't know perl, so don't know exactly what your code is doing.

However, I note that you need the equivalent of the command-line options "-colorspace RGB" and "-colorspace sRGB". These are very different to the options "-set colorspace RGB" and "-set colorspace sRGB", and perhaps your code is doing "set".

snibgo wrote:This is perl, is it? I don't know perl, so don't know exactly what your code is doing.

However, I note that you need the equivalent of the command-line options "-colorspace RGB" and "-colorspace sRGB". These are very different to the options "-set colorspace RGB" and "-set colorspace sRGB", and perhaps your code is doing "set".

Translated into command line, I'm doing this:

Code: Select all

convert input.jpg \
  -density 600 -depth 16 \
  -colorspace RGB \
  -filter Lanczos -resize XXXxYYY \
  -crop XXXxYYY \
  -some -more -operations \
  -colorspace sRGB \
  output.png

So IMHO I'm already doing what you suggest. But the printout gets way too dark.

If the images look fine on your monitor but print too dark that's most likely a hardware (monitor) calibration issue.

holden wrote:If the images look fine on your monitor but print too dark that's most likely a hardware (monitor) calibration issue.

It is much darker than the original photo on the monitor, too. So the problem must be somewhere in the processing.

IM v6.7.8 is an old version, so an upgrade might help.

If you put up your image and full command, someone can test on more recent versions.

If you can't put up the image, at least do a "identify -verbose" and paste the results here between [ code ] and [ /code ].

snibgo wrote:IM v6.7.8 is an old version, so an upgrade might help.

If you put up your image and full command, someone can test on more recent versions.

If you can't put up the image, at least do a "identify -verbose" and paste the results here between [ code ] and [ /code ].

The problem is neither an old version nor a broken image. Here's one recipe to get the colorspace handling wrong:

Code: Select all

convert Fotos/DSC_0304.JPG \
  -density 600 -depth 16 \
  -colorspace RGB \
  -filter Lanczos -resize 600x400 \
  \( -size 640x440 xc:grey \) \
  +swap \
  -gravity center \
  -compose Over -composite \
  -colorspace sRGB \
  output.png

display output.png

The problem here is that the colorspace information of the image gets lost during the composite operation. Composite will use the colorspace information from the freshly generated grey background, which is probably sRGB. This renders the final "-colorspace sRGB" to a no-op, since the setting already _is_ sRGB.

The fix is here would be:

Code: Select all

convert Fotos/DSC_0304.JPG \
  -density 600 -depth 16 \
  -colorspace RGB \
  -filter Lanczos -resize 600x400 \
  \( -size 640x440 xc:grey \) \
  -gravity center \
  -compose DstOver -composite \
  -colorspace sRGB \
  output.png

display output.png

this will preserve the colorspace information from the image, but will loose the meta data (dimensions!) from the background color. So we loose the border.

To finally get it right, we need this:

Code: Select all

convert Fotos/DSC_0304.JPG \
  -density 600 -depth 16 \
  -colorspace RGB \
  -filter Lanczos -resize 600x400 \
  \( -size 640x440 xc:grey -colorspace RGB \) \
  +swap \
  -gravity center \
  -compose Over -composite \
  -colorspace sRGB \
  output.png

display output.png

So colorspace handling is not at all that easy as suggested in the posts above. It is not always entirely clear how the meta information is propagated through the sequence of the commands and it is easy to loose them somewhere on the way. Especially if you do heavy manipulations. Or maybe you call external scripts, which by themself might loose the vital information somewhere.

That's it; you've got it. (Beware that default colorspaces for gray images changed in 6.7.9, then again in 6.8.5.)

"-composite" makes one image from two, and the metadata is taken from the first. But I don't know how it handles the situation of the images being in different colorspaces. I think it's best to explicitly make them the same.

snibgo wrote:That's it; you've got it.

Not really. There are still lots of unanswered questions. All this is very confusing, and very badly documented AFAICS.

What is when the original image has an attached profile? In this case the -colorspace settings seem to be ignored sometimes, but are still attached to the metadata. And how is one supposed to force linear RGB colorspace when a profile is attached? You need linear colorspace to do manipulations, don't you?

An other example: Please take a look at your great example of the chrome effect you posted a couple of days ago. In what colorspace is the result? How to force it to RGB if you want to combine it with an image? Simply using the -colorspace setting will shift colors and most probably destroy the chrome effect.

(Beware that default colorspaces for gray images changed in 6.7.9, then again in 6.8.5.)

Can you give some more details on that?

Can you give some more details on that?

see viewtopic.php?f=4&t=21269

joew wrote:You need linear colorspace to do manipulations, don't you?

It depends. I do most of my work, including resizeing, in sRGB. I do colour-balancing (of raw photos) in linear RGB. I do some processing in CIELab.

When I have an image that has been converted to a profile, I generally convert it to sRGB.

Most manipulations will work in RGB or sRGB, with or without profiles. But when working with multiple images, it's best that they are are all the same. For my purposes, sRGB generally works best.

Most of the IM Usage pages use cartoon graphics. Perhaps, for those, manipulations work best in RGB (though I'm not convinced). For photos, I think sRGB is better. However, there is rarely much difference.

My metallic/chrome script uses the default colorspace which is sRGB in modern IM versions, so the result is sRGB. If you want to combine it with another image in RGB, just "-colorspace RGB" for both images before the manipulation, and "-colorspace sRGB" afterwards. (This advice is for current IM versions, and might be wrong for your v6.7.8.)

Between roughly 6.7.9 and 6.8.5, IM treated images without colour differently to images with colour, with the unfortunate habit of silently converting grey images from sRGB to RGB. This defeated my rule of thumb that everything should be in the same colourspace, and confused many users. Happily it no longer does this.

snibgo wrote:
joew wrote:You need linear colorspace to do manipulations, don't you?
It depends. I do most of my work, including resizeing, in sRGB. I do colour-balancing (of raw photos) in linear RGB. I do some processing in CIELab.

http://www.imagemagick.org/Usage/resize ... colorspace says resizing should be done in linear RGB.

When I have an image that has been converted to a profile, I generally convert it to sRGB.

This removes the profile and stores in sRGB? I thought having a profile attached would be the better (thus preferable) method?

Most manipulations will work in RGB or sRGB, with or without profiles But when working with multiple images, it's best that they are are all the same. For my purposes, sRGB generally works best.

Every FAQ and HOWTO I could find on the net states that manipulations should be done in linear color space. Maybe IM does internal conversions if it finds that the image is not yet in linear colorspace, so that manipulations in sRGB work fine because of that invisible conversion? But then, this should be documented clearly.

Can I be confident that all three of the following commands:

Code: Select all

 convert -size 100x100 xc:somecolor -colorspace sRGB t1.png
 convert -colorspace RGB -size 100x100 xc:somecolor -colorspace sRGB t2.png
 convert -colorspace sRGB -size 100x100 xc:somecolor -colorspace sRGB t3.png

will give me exact the same image? In viewtopic.php?f=4&t=21269, magic talks about "declaring" a color space for an image. I think the distinction between "declaring" (this modifies only the metadata) and actually converting from one colorspace to an other is a very important distinction. But I can't find anything in the IM documentation that would explain this distinction.

Most of the IM Usage pages use cartoon graphics. Perhaps, for those, manipulations work best in RGB (though I'm not convinced). For photos, I think sRGB is better. However, there is rarely much difference.

As stated at the beginning of the thread, I have seen huge differences.

My metallic/chrome script uses the default colorspace which is sRGB in modern IM versions, so the result is sRGB.

Yeah. But you use the -gamma option, which brings us back to the very first post in this thread:

Code: Select all

display: Ignoring incorrect gAMA value .20661 when sRGB is also present `t.png' @ warning/png.c/MagickPNGWarningHandler/1777.

IM seems to remember that gamma was used somewhere in the workflow. And some combinations of colorspace and gamma usage seem to be illegal. And I still don't understand what this warning tries to say to me. After all, in this original example, "-gamma 2.2" is the opposite of 0.454545, so the image should be back again from where it started. Why this warning?

When I say "I do something", it doesn't mean everyone else should.

joew wrote:http://www.imagemagick.org/Usage/resize ... colorspace says resizing should be done in linear RGB.

Yes, I'm aware of that. I'm not convinced by the earthspace demonstration. I agree the non-converted image is too dark, but the converted image looks too light (to me). But what matters is what looks right to you (or your client), and these matters are rather subjective. See the Digital Image Processing forum for discussions.

And don't forget that what looks best also depends on the quality of the monitor, printer, whatever.

joew wrote:This removes the profile and stores in sRGB?

Yes.

joew wrote:I thought having a profile attached would be the better (thus preferable) method?

Why? Profiles are normally used to specify the colour characteristics of the input device, or to prepare for an output device. I don't want to retain the input profile during processing -- it's of no importance. An output profile is only important after the processing is done.

And don't forget that an attached profile means either (a) assigned metadata that has no effect on processing or (b) pixel values have been converted to this other colorspace. If (b), then processing will work differently on the same image that has been converted to different colorspaces. I would find this confusing.

joew wrote:Every FAQ and HOWTO I could find on the net states that manipulations should be done in linear color space.

They are often blindly repeated from each other. But if it works for them (or you), that's fine.

joew wrote:Maybe IM does internal conversions if it finds that the image is not yet in linear colorspace, so that manipulations in sRGB work fine because of that invisible conversion?

Current versions of IM do not (thankfully) do any colorspace conversions without being told to do so. As far as I know.

joew wrote:Can I be confident that all three of the following commands: ... will give me exact the same image?

In current versions, yes. However, note that "-colorspace something" converts an image already in memory; if there is no image (because this is the first operation) it should do nothing. In your examples, "-colorspace sRGB" at the end will also do nothing because the image is already sRGB.

joew wrote:I think the distinction between "declaring" (this modifies only the metadata) and actually converting from one colorspace to an other is a very important distinction.

Agreed.

joew wrote:But I can't find anything in the IM documentation that would explain this distinction.

Perhaps not, explicitly. Colour concepts are described quite well in http://www.imagemagick.org/Usage/color_basics/, http://www.imagemagick.org/script/color-management.php, etc, but beware that these are somewhat out of date, and greyscale now processes exactly like colour.

joew wrote:As stated at the beginning of the thread, I have seen huge differences.

In that case, use whatever works for you.

joew wrote:Yeah. But you use the -gamma option, which brings us back to the very first post in this thread: ...

I agree the warning is weird, but you can ignore it. I think gamma is stored in PNG files for historical reasons, as a hint to display software that the image should undergo further gamma correction before being displayed. Most software ignores the setting. If it troubles you, you can eliminate the warning by "-set colorspace sRGB" immediately before the output filename. This resets the gamma setting as appropriate for sRGB, 0.454545.

snibgo wrote:When I say "I do something", it doesn't mean everyone else should.

As long I don't have a clue by myself, I tend to look what other people do

joew wrote:http://www.imagemagick.org/Usage/resize ... colorspace says resizing should be done in linear RGB.
Yes, I'm aware of that. I'm not convinced by the earthspace demonstration.

I find this explanation very imressive and also easy to understand.

But what matters is what looks right to you (or your client), and these matters are rather subjective.

Ugh. I don't like subjective results at all. If the result looks different to different people, then I can just as well use a deterministic and correct algorithm.

And don't forget that what looks best also depends on the quality of the monitor, printer, whatever.

That's why I don't want to rely on what looks good to me. I want to use the correct methods in the first place. I think this way the result will look good if it is output onto a proper device (maybe with profiles used).

joew wrote:This removes the profile and stores in sRGB?
Yes.
joew wrote:I thought having a profile attached would be the better (thus preferable) method?
Why? Profiles are normally used to specify the colour characteristics of the input device, or to prepare for an output device. I don't want to retain the input profile during processing -- it's of no importance. An output profile is only important after the processing is done.

And don't forget that an attached profile means either (a) assigned metadata that has no effect on processing or (b) pixel values have been converted to this other colorspace. If (b), then processing will work differently on the same image that has been converted to different colorspaces. I would find this confusing.

This point has a merit. Is using "-colorspace RGB" enough to get rid of the profiles?

joew wrote:Can I be confident that all three of the following commands: ... will give me exact the same image?

Code: Select all

convert -set colorspace RGB  -colorspace RGB  -size 100x100 xc:#bebebe -colorspace sRGB 1.png
convert -set colorspace RGB  -colorspace sRGB -size 100x100 xc:#bebebe -colorspace sRGB 2.png
convert -set colorspace sRGB -colorspace RGB  -size 100x100 xc:#bebebe -colorspace sRGB 3.png
convert -set colorspace sRGB -colorspace sRGB -size 100x100 xc:#bebebe -colorspace sRGB 4.png

1.png and 2.png result in #e0e0e0
3.png and 4.png result in #bebebe

I'd have expected that 1.png is identical to 3.png while 2.png is identical to 4.png.

Since I explicitly set the colorspace before creating any drawings, changes in defaults should not have any influence...

Whatever the defaults are in this version of IM, 1 and 3 should be in RGB at the time when the color is drawn. 2 and 4 should be in sRGB for the same reason. Why do I get the opposite of the expected result? Since my expectation don't match the results, there must still be some important points that I am missing

I'd have expected that 1.png is identical to 3.png while 2.png is identical to 4.png.

It depends upon what version of IM you are using. I don't recall you ever specified. See snibgo's comment earlier about changes in IM colorspace handling or see viewtopic.php?f=4&t=21269. That affects whether you need to use -set colorspace RGB to avoid converting to linear RGB or not.

Thanks for the link. I'll read it.

joew wrote:Ugh. I don't like subjective results at all. If the result looks different to different people, then I can just as well use a deterministic and correct algorithm.

That's fair enough. I mostly make images for people, not machines, so what they look like is (for me) of prime importance.

Just for fun, let's be objective. Take the earthlights image (http://eoimages.gsfc.nasa.gov/ve//1438/ ... s_4800.tif). Find the mean intensity. Resize with different colorspace conversions, and find the mean intensity of each. This is an objective test of lightness.

Code: Select all

D:\web\im>c:\im\ImageMagick-6.8.6-Q16fix\convert earth_lights_4800.tif -colorspace Gray -format "%[fx:mean]" info:
0.0507808

D:\web\im>c:\im\ImageMagick-6.8.6-Q16fix\convert earth_lights_4800.tif -colorspace Gray -resize 500 -format "%[fx:mean]" info:
0.050977

D:\web\im>c:\im\ImageMagick-6.8.6-Q16fix\convert earth_lights_4800.tif -colorspace Gray -colorspace sRGB -resize 500 -colorspace sRGB -format "%[fx:mean]" info:
0.050977

D:\web\im>c:\im\ImageMagick-6.8.6-Q16fix\convert earth_lights_4800.tif -colorspace Gray -colorspace RGB -resize 500 -colorspace sRGB -format "%[fx:mean]" info:
0.064399

D:\web\im>c:\im\ImageMagick-6.8.6-Q16fix\convert earth_lights_4800.tif -colorspace Gray -colorspace Lab -resize 500 -colorspace sRGB -format "%[fx:mean]" info:
0.0504707

As expected, the second and third are the same (they both stay in sRGB).

Which resize is objectively "best"?

joew wrote:Is using "-colorspace RGB" enough to get rid of the profiles?

No. It has no effect at all on profiles. If a file has an embedded profile, I think the best action is

Code: Select all

-profile sRGB.icc +profile "*"

This converts it to a sRGB profile, then removes the profile. I should say that opinions differ, but this works for me.

1,2,3,4.png: I get the same results as you, using IM 6.8.6-0. This seems to show that "-set colorspace RGB" has an effect even when placed before the image. But I don't think it's advisable. And putting "-colorspace anything" before any image is both syntactically wrong and does weird things. I'd prefer that IM threw an error.

Two correct syntaxes are:

Code: Select all

convert -size 100x100 xc:#bebebe -set colorspace RGB  -colorspace sRGB 5.png
convert -size 100x100 xc:#bebebe -set colorspace sRGB -colorspace sRGB 6.png

Legacy ImageMagick Discussions Archive

From sRGB to CMYK and gamma?

Re: From sRGB to CMYK and gamma?

Re: From sRGB to CMYK and gamma?

Re: From sRGB to CMYK and gamma?

Re: From sRGB to CMYK and gamma?

Re: From sRGB to CMYK and gamma?

Re: From sRGB to CMYK and gamma?

Re: From sRGB to CMYK and gamma?

Re: From sRGB to CMYK and gamma?

Re: From sRGB to CMYK and gamma?

Re: From sRGB to CMYK and gamma?

Re: From sRGB to CMYK and gamma?

Re: From sRGB to CMYK and gamma?

Re: From sRGB to CMYK and gamma?

Re: From sRGB to CMYK and gamma?

Re: From sRGB to CMYK and gamma?