Legacy ImageMagick Discussions Archive

Since 6.7.2-10, IM uses sRGB v4 http://www.color.org/srgbprofiles.xalter.
IM7 has a different syntax for colourspace management, so I imagine that there are internal changes as well.
What used to beis now Context
My student Adam Turcotte and I are producing a quantitative comparison of upsampling methods based on ImageMagick and VIPS (for the image metrics).
For better or worse, we have decided that 16-bit sRGB TIFF is our "reference" space. As it turns out, there is more than one sRGB, so our standard needs to be standardized.
This probably could be fixed by blindly using ImageMagick to produce the reference images, but we'd rather not be blind.
Because we want to factor out errors that come from colourspace mismatch, we need to make sure that there is no discrepancy between the sRGB/intent used for the input images and the re-enlargements.
In addition, in the "linear light" toolchain, we need to make sure that the sRGB we convert from is the same as the sRGB we convert to. That is: Every downsampler and upsampler is tested with a colorspace blind version (taking sRGB literally) and one that converts into and out of linear RGB.
Questions
What would you suggest we use as "standardized" sRGB format when we are in sRGB (we're pretty committed to TIFF, and I'm partial to Absolute because Relative seems to give the same result as Perceptual in photivo, and I don't like Perceptual much)?
P.S. We're going to use sRGB v4 (not IM's default, although IM7 understands it) with Perceptual rendering intent (which is IM's default). v4 because the inverse conversions are higher quality than with v2 (good for our linear toolchain), Perceptual because this is the most commonly used, and it minimizes clipping without major ill effects as far as a quantitative test suite goes: we actually do not really care what things look like.

Does IM7 read the rendering intent from the loaded image and propagates it, or do we have to set it manually at read (and write) with -intent?
P.S. We'll use Perceptual, which takes care of this issue (actual = default). This being said, it would be nice if IM could somehow (does it already?) pick up the rendering intent when loading with an embedded profile.

Is there any gotcha we should be aware of? Can we trust the IM6 documentation?

For example, I'd be willing to reconvert all my test image from RAW (using photivo) so as to create a stardard sRGB TIFF that works well with ImageMagick (and VIPS). But I'd like some guidance RE: what sRGB I should choose, and how to tell IM7 that I want it to be consistently using this particular sRGB.
Looks like I may have to learn to use import/export with a "user supplied" ICC profile.

Assuming nothing drastic has changed w.r.t. profile handling, I would guess that I can figure it out: http://www.imagemagick.org/Usage/formats/#profiles

Informative (as usual): http://www.cambridgeincolour.com/tutori ... ersion.htm
Maybe I should standardize to Perceptual so that when downsampling the side effects of clipping be minimized.

-colorspace sRGB uses sRGB v2 instead of sRGB v4 (probably a good default since not all apps understand v4, apparently), so if you want v4 you need to explicitly specify the profile.

You probably know more about it than just about everyone else here.

I myself have no idea about 'rendering intent' though I have heard of it.

sRGB basically follows the standards as given by W3C (web consortium), and shown on the wikipedia page for sRGB.

anthony wrote:...
sRGB basically follows the standards as given by W3C (web consortium), and shown on the wikipedia page for sRGB.

Roughly speaking rendering intent describes the general "logic" used to handle the fact that sRGB has a fairly limited gamut. The Cambridge in Colour link I posted above gives a pretty good explanation.
What I had not realized is that there is more than one sRGB standard, and that the v2 standard was vague enough that you can't even be sure that all "plain vanilla" v2 sRGBs are truly the same (slight "vendor dependence"). The v2 standard, apparently, is far from unambiguous w.r.t. to out of gamut handling when converting from other colour spaces, and inverse transforms are not particularly accurate.
If you want total control, you need to select one specific profile and stick to it throughout the toolchain. And I decided on the v4 profile straight from the ICC, used with Perceptual rendering.
By the way, John Cupitt, the main VIPS/NIP2 dev, advises against using Perceptual relative intent: For him, it's Relative all the way, because the standards (not only sRGB but CMYK etc) are less ambiguous w.r.t. what is done with this rendering intent. Consequently, as you move between colourspaces, things will be less messed up if you use Relative with all of them. I'm fine with Perceptual because I only use one specific version of sRGB. In addition, Perceptual is apparently the most commonly used, so if I want our test suite to be reasonably "real life", it's better. But I use v4 instead of the more common v2 because I want more accurate inverse transforms (easier to get with Perceptual than with the others because there is way less out of gamut clipping). Then again, apparently Perceptual rendering, compared between different ICCs, is all over the place. Beware if you navigate between many different colourspaces!
(I stand to be corrected: I understand things better than a week ago, but among other things I have not read the white papers from the ICC.)

Now that I realize that although IM7 understands v4 sRGB profiles but does not use them by default (I hope I got that right), here is how I believe I can get what I want:.
Input: A stripped (with exiftool -overwrite_original -all= or IM7's -strip) 16-bit TIFF produced with sRGB v4 Perceptual.
Output: Similar type of image.
sRGB toolchain: Linear light toolchain:Assuming I know what I'm doing, the latter version converts the input image to linear RGB using the v4 profile (which was used to create INPUT.tif), does the resize, converts back to v4 sRGB, strips the meta and profile, and saves. The former takes the colour values literally.
Adam and I will be double checking over the next few days.

Given that IM7 is changing the API, I would like to make a suggestion. (I don't feel strongly about this, so no explanation needed if it's "no".)

I think that it would be beneficial to have an explicit -import and an explicit -export command that deals with using ICC profiles. This is the way the VIPS library deals with this. There is then a separate command that deals with moving between colorspaces, again through an in ("tag as", in nip2) and out ("convert to") pair.

And then, there could be some sort of toggle that specifies whether to use the embedded profile if possible instead of the one specified by -import.

I have not given this a huge amount of thought. If this is something you'd like to consider, let me know and I'll look into it more carefully.

Otherwise: It was just an idea

NicolasRobidoux wrote:...Assuming I know what I'm doing...

I don't: The two toolchains give exactly the same result.

-verbose to the rescue. I think I need to use +profile.

NicolasRobidoux wrote:-verbose to the rescue. I think I need to use +profile.

That's not it.

I am not that experience with profiles. So perhaps advice from others will be better. However, why do you do -strip at the end before saving the result. With no profile, any display may not be able to show the image correctly. Also is there some initial profile imbedded in the original image? Is the input colorspace sRGB? If so, it may not match your first v4 sRGB profile. Just some thinking out loud for you to look into. Hope I don't lead you astray. Anthony will know much more here than I or perhaps someone else.

fmw42 wrote:... However, why do you do -strip at the end before saving the result. With no profile, any display may not be able to show the image correctly. Also is there some initial profile imbedded in the original image? Is the input colorspace sRGB? If so, it may not match your first v4 sRGB profile.

These are all good things to keep in mind.
Some info:
All the input images are produced with the v4 profile that I feed to -profile.
But the input images are stripped, so that the suite is "lighter".
What I want to do is produce output images with the same v4 profile (having resized in "linear light"), stripping them, again, to keep things "light".
If I view the images, I import them specfying the profile (in nip2).

Now: Maybe I should just forget being "light" and just embed every time. I imagine that the hoped for eventual users will have an easier time this way.
Also, maybe I should stick to v2. It seems to be a minor pain in the neck to get, say, rawtherapee to use v4. And there are still many browsers, for example, that can't read v4.

---

Thank you for the feedback, Fred.

Same result if I embed the v4 sRGB icc in the input image and use