From sRGB to CMYK and gamma?

[snibgo]

Thanks for the link. See the very old (and now inaccurate for current IM) discussion at viewtopic.php?f=2&t=15955 . The author has created images that exploit a problem that (surprise, surprise) his software cures. Well, good for him.

I suspect images could be created that showed the opposite problem: that turn into grey mush when resized in RGB but are legible when resized in sRGB.

Most of my images (photographs or video frames) resize slightly better in sRGB than RGB.

[GreenKoopa]

Linear RGB is 'correct'. But our eyes are not. Now what? It would be easier if there were one correct answer. Sigh.

I have far less experience than snibgo, but here is what I've seen so far. When the change is small (a 2/3 resize or 10% increase in brightness), there is nearly no difference in nearly all images. When the change is large (1/10 resize to a thumbnail, doubling the brightness in the shadows) the difference can be significant. But neither sRGB, RGB, nor Lab are always better. High contrast images can result in differences too. Fireworks was a recent one for me.

The examples in that explanation say that the scaling was "huge" and that it still only made a significant difference for some areas of some images. The Dalai Lama image looks different to me on different monitors and at different angels. It is a trick interlaced image that won't occur in real life. It says that most or all software is wrong, but this software has been good enough for professionals for years.

That said, I share your instinct. We do work better when we understand things at a more fundamental level. This is why colleges teach abstract concepts. Subjective is best for the photo in front of you, but it doesn't always generalize well. It also isn't always realistic. With dozens of variables to modify, we need some education when guessing which permutations are worth trying. The end product will be 100% subjective, and people will disagree.

How do you print?

Mpix or Costco when needed, but most photos are shared digitally.

[fmw42]

See Nicolas Robidoux's discussion on resizing, for example of one kind of processing and what colorspaces work best. It all depends upon the type of artifact you are willing to put up with. There is no one size fits all. It even depends upon the type of image (high contrast, cartoon, real-world, etc)

http://www.imagemagick.org/Usage/filter/nicolas/

[joew]

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.

I tend to disagree. The thread you are pointing to only talks about changed defaults. Since I set the colorspace metadata explicitly before creating any drawings, the defaults should be overwritten and should not have any effect.

For example: in 2.png and in 4.png, at the time when the drawing is done, the colorspace is already in sRGB for both commands. Thus the drawing should create identical pixel values.

A similar reasoning goes for 1.png/3.png.

Since the settings are done explicitly, the changes of the defaults should not have any effect.

[joew]

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.

OTOH, you said they look different for different people. Who do you optimize for? If you optimize for yourself, you might create a bad picture for your client. Thus the outcome is somewhat random. You can use a mathematical correct mechanism as well

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.

OK

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.

Why would this be illegal? The semantics would be pretty clear: "convert any images on the stack into the given colorspace". If no images exist at this time, none is converted, but only the colospace declared.

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

This seems wired to me. The drawings are done with undefined colorspace. With such a syntax, IM would rightfully do different things for different versions

[joew]

Thanks for the link. See the very old (and now inaccurate for current IM) discussion at viewtopic.php?f=2&t=15955 . The author has created images that exploit a problem that (surprise, surprise) his software cures. Well, good for him.

I can't find anything in this thread that would suggest operations in nonlinear colorspaces. All the thread seems to be about how to know which colorspace is used when reading and which operations should do automatic conversion.

[anthony]

For non-linear colorspace (even DIY variations) with resizing see
IM examples, Resizing, Resizing Techniques
http://www.imagemagick.org/Usage/resize/#techniques

Esecially...
http://www.imagemagick.org/Usage/resize ... ce_summary

But is resizing in a perceptual colorspace really a bad thing? Really that is a debatable point.

[snibgo]

OTOH, you said they look different for different people.

You said that, not me. I just said that preferences were subjective. We optimise for the client, of course.

Thus the outcome is somewhat random. You can use a mathematical correct mechanism as well

And I showed you that the "mathematical best mechanism" for the earthlights image was to resize in sRGB space, despite some sources that claim resizing should always be in linear RGB.

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

This seems wired to me. The drawings are done with undefined colorspace. With such a syntax, IM would rightfully do different things for different versions

No. IM writes the pixel values. For that operation, the colorspace is irrelevant. In fact, few operations do different things according to the colorspace. Setting pixels, blurring, sharpening, resizing -- these operate on pixel values, and are mathematical, and don't care what the pixel values represent.

When we talk about doing an operation in a particular colorspace, this simply means, in IM terms, if necessary converting the pixel values to that colorspace, doing the operation, and converting back. The operation remains the same.

[joew]

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

This seems wired to me. The drawings are done with undefined colorspace. With such a syntax, IM would rightfully do different things for different versions

No. IM writes the pixel values. For that operation, the colorspace is irrelevant.

It is not irrelevant. Writing arbitrary values without having any idea of how they would be interpreted is undefined behavior. This is not IM specific, this is common sense in information technology, btw. A given value in ascii has a totally different meaning from the same value in ebcdic. #bebebe in RGB is totally different from #bebebe in sRGB. You can't simply write some values somewhere without knowing how those values would be interpreted further down in the queue of operations.

Therefore there need to be a way to declare the colorspace before the pixels are created with "-size 100x100 xc:bebebe". This is the only way to properly and reliably know whether and which conversion would be needed when -colorspace commands follow further down the command queue.

In fact, few operations do different things according to the colorspace.

But those that do, need a proper way to find out the colorspace. And they need to find out the old colorspace in order to know whether and how a conversion is to be done. Thus this information needs to be in place and properly passed from the very beginning.

Setting pixels, blurring, sharpening, resizing -- these operate on pixel values, and are mathematical, and don't care what the pixel values represent.

While those operations by themself don't care for the colorspace, the values written by those operations have a totally different meaning depending on the colorspace setting at the time when those operations are executed. executing those operations with undefined colorspace setting will lead to undefined results.

[GreenKoopa]

joew, you are of course correct that some knowledge of data is needed to process it properly. But not all knowledge is needed for most operations.

Let's take your ascii example. Knowing that a file is encoded as ascii is enough to count the occurrences of 'a', but is not enough knowledge to count the verbs or translate the document. For that we would need to know what language humans understand it to be. Many text processing applications allow you to specify the language, but many don't force you to.

Same with IM and colorspaces. Most operations don't care about the colorspace. Take averaging (as in resampling or blurring) as an example. A 20% gray and 60% gray average to 40% gray, independent of colorspace. IM allows you to set the colorspace before or after this averaging, and the result would be the same. Colorspace only changes what humans understand the numerical color levels to mean. So a program that displays these grays should be colorspace aware.

There are a few IM operations that need to be colorspace aware, but many users don't use these. IM therefore allows flexibility in specifying colorspace. This is like a word processor allowing you to work with an incorrect or unspecified language. Typing and formatting work fine. You could set the language when the document is created, or you could set it later when you realize you need an operator that cares, such as spell check.

[snibgo]

The default colorspace is sRGB. The action of writing #bebebe in a pixel is the same, irrespective of colorspace.

"-set colorspace something" is used to change metadata of images already in the list. If it also changes images not yet created, I don't know if that behaviour will continue in future versions.

[magick]

#bebebe is sRGB. To convert it to linear RGB use -colorspace RGB. To interpret #bebebe as already in the linear RGB colorspace, use -set colorspace RGB.

[joew]

Many text processing applications allow you to specify the language, but many don't force you to.

I'm not about forcing people to do the specification. I'm about the ability to be able to do so. As snibgo states, the obvious and straightforward way to do the specification is illegal syntax.

The default colorspace is sRGB. The action of writing #bebebe in a pixel is the same, irrespective of colorspace.

Then explain please why your examples

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

give different results.

#bebebe is sRGB. To convert it to linear RGB use -colorspace RGB. To interpret #bebebe as already in the linear RGB colorspace, use -set colorspace RGB.

If that would be true, why do the two commands above give different results?

[snibgo]

"-set colorspace RGB -colorspace sRGB"
The first declares the colorspace to be RGB. The second means "If not already sRGB, convert the pixel values to sRGB." Thus the conversion will occur.

"-set colorspace sRGB -colorspace sRGB"
The first declares the colorspace to be sRGB*. The second means "If not already sRGB, convert the pixel values to sRGB." It is already sRGB, so no conversion will occur.

*EDIT: corrected from RGB.

[GreenKoopa]

Exactly as snibgo and magick said. Additionally, the command line is read from left to right. -set colorspace and -colorspace operate on all images currently in the list. An operation that occurs when the list is empty does nothing. Settings may occur before the first image. It's not clear to me if -set is a setting or an operation, if this is always handled consistently, or if it is even well defined.