I was playing with the indigo bunting and soon realised much of my image was out of sRGB gamut, so I thought I’d try perceptual intent. I haven’t used the intents in dt previously and soon realised I need littleCMS on, so did that and re-launched dt for good measure. I output 2 jpegs, one perceptual, one relative colorimetric, but I couldn’t see any difference flicking between them. There was loads of cyan on pressing the gamut button. Then I tried different display intents by right-clicking that button, but again no change. Any ideas please?
If a profile won’t support a rendering intent, LittleCMS will fall back to a supported rendering intent when the transform is attempted. The programmer has to check the profile beforehand to determine if a rendering intent is supported.
I have such checks in rawproc; my experience is that matrix profiles only support relative_ and absolute_colorimetric; you need a LUT profile to support perceptual.
Thanks guys.
Looking through my build log, I have these lines -
– Found LCMS2: /usr/lib/x86_64-linux-gnu/liblcms2.so
– The following REQUIRED packages have been found:
…
* LCMS2
…
so perhaps that means LittleCMS is present and correct, what do you think?
@paperdigits or anyone, following @ggbutcher’s comment, have you seen perceptual output working in a fairly recent dt using the “standard” output profile “sRGB (web-safe)”. Surely if any profile was going to be perceptual-capable it would be this one?
I’ve tried RT’s RTv4_sRGB.icc profile and Elle’s sRGB-elle-V2-g10 profile in dt and neither produce jpegs showing any difference across the rendering intents. Nor the display setting.
AND RT5.8 is also failing on my system (Ubuntu 18.04) to deliver rendering intents.
I’m using “Image Viewer” which I think comes with Ubuntu, icon is a magnifying glass over a daisy. It is colour managed.
But in fact, I don’t think that matters here, because each pair of jpegs I’m comparing both have the same profile, but should contain some differing pixel values because of the differing intents used when they were created. So I reckon I should see some differences whether colour managed or not.
In case it helps get to the bottom of this, here are 2 jpegs from the Indigo Bunting raw, both made with dt’s built-in sRGB profile. Very over-saturated. One perceptual, the other absolute colorimetric. No visible difference to me. To make them I just changed the intent in the output module - the profile and intent in the “export selected” tool were both set at “image settings”.
Here’s something else to consider. Each colorspace transform, camera->working, working-display, and working->output, compresses the gamut. If the camera->working lost the tone gradations of concern, there’s no rendering intent that’s going to help you in the working->output transform.
@ggbutcher, thanks Glenn, I do indeed think this could turn out to be an embarrassing misunderstanding on my part! So any ideas like you’ve posted are good.
Am I misunderstanding here… I think that if the gamut indicator is showing lots of picture out of bounds, then it can’t matter what went before - the s/ware now has to convert it to sRGB for writing to a jpeg, and for perceptual that means drawing in the out-of-gamut colors.
It would be nice if someone with Ubuntu and a reasonably recent dt could do a quick experiment and check if they can see any difference between the rendering intents using “sRGB (web-safe)” and some clown sick!
Also does anyone have a profile they could share - sRGB, adobeRGB-ish, nothing to esoteric - that definitely has a LUT in it, in case the problem is that none of the ones I’ve used have it.
Yep, the more I think about it, I believe you’re experiencing the default behavior of LIttleCMS with regard to applying rendering intents to a transform. I’ve done just this, I took a matrix sRGB profile and applied it with first relative_colorimetric, then with perceptual, to an exported TIFF, and they both came out looking the same. Later, when I put in rendering intent checking prior to the actual transform in my code, I got a “unsupported rendering intent” for the matrix sRGB/perceptual combination. And, the LittleCMS docs explicitly say that, if an unsupported rendering intent is provided to a transform, the transform will default to a rendering intent supported by the profile.
Brilliant @ggbutcher, the color.org sRGB_v4_ICC_preference profile makes the rendering intent work. Here are perceptual and abs. col. outputs. These make sense to me.
I haven’t properly read the Elle link yet, but oddly the color.org perceptual jpeg is the same as the abs. col. one made by “sRGB (web-safe)”. All the web-safe renderings are the same I reckon, and perceptual. I’ll think about that tomorrow maybe.
@paperdigits, I think there is a website/browser issue. My post above starting “I’m using image viewer” has the same jpeg twice. I assumed I’d messed up. So I just tried to correct it. So I deleted the second jpeg and uploaded the correct one. Whist it’s uploading, all looks okay, it’s the file name I expect. But when it gets to 100%, the file name changes to the same as the previous one, i.e. indigo-bunting-test-sRGB-abs-col !!! I did this twice, once dragging/dropping, and once using the upload button. aaaagh!
