Converting profiles based on actual image content,rather than profile difference

[darlingm]

(Correct me if I'm wrong, but my understanding is that) Converting to a profile is done by the differences between the profiles and the rendering intent.  This sometimes leads to color conversions that wouldn't be necessary in a particular image.  For example, if you happened to have a ProPhoto RGB image that was entirely within your printer profile gamut, it's my understanding that conversion will still shift colors using the selected rendering intent based on the differences in the color gamut mapping.

Is there any software (perhaps RIP software) that analyzes an image's actual content when converting to another profile, to make a better conversion?  I know this could take considerably more processing power.

[Mark D Segal]

If your image is in ProPhoto colour space and the image colour values are all within the gamut of your printer profile and you are printing with that printer profile, I'm not clear what the problem set-up is in this example. My understanding and observations are that unless there are OOG colours, the choice between Perceptual and RelCol RI won't affect image appearance, if that is what you are trying to get at. But you can experiment with these variables and see what happens.

[darlingm]

I haven't done my own testing.  I remember reading a few things along the understanding I said in my original post, however I could have totally misunderstood what I was reading, and perhaps the source was wrong.  I'll do some of my own testing, see if I can find the locations I read from way back, and post back.

[pfigen]

If all the colors in your image (no matter what the color space is) are within the output gamut, then all you really have to do is convert to the output space using Relative Colorimetric. That will maintain all the colors as well as the profile is capable of doing. Even when there are colors in your image outside of the printer gamut, unless they're significantly outside or a large part of the image, you're usually better off when printing to inkjets, to still use Relative. It all comes down to the difference between theory and practice, and while a lot of people freak at out of gamut colors, in the real world, it's usually not visible, at least in a detrimental way.

[jbrembat]

Converting to a profile is done by the differences between the profiles and the rendering intent.  This sometimes leads to color conversions that wouldn't be necessary in a particular image.  For example, if you happened to have a ProPhoto RGB image that was entirely within your printer profile gamut, it's my understanding that conversion will still shift colors using the selected rendering intent based on the differences in the color gamut mapping

I don't understand what you mean by "is done by the differences between the profiles and the rendering intent".

- relative: in-gamut colors are untouched, out-of-gamut colors are clipped to the nearest printer gamut border

- perceptual: colors are scaled depending on profile specific gamut mapping algorithm

A note on relative: as blackpoint compensation is not required in ICC_v2 specification, you can find profiles that not incorporate it (in this case ,CMM can do blackpoint scaling, if requested, and you can get a different rendition)

Is there any software (perhaps RIP software) that analyzes an image's actual content when converting to another profile, to make a better conversion?  I know this could take considerably more processing power.

This feature, and an out-of-gamut evidence, will be included in a future realease of PhotoResampling.
But the goal is to get image colors that are in printer gamut.

Argyll can generate a custom profile starting from a specific image.

Jacopo

[digitaldog]

(Correct me if I'm wrong, but my understanding is that) Converting to a profile is done by the differences between the profiles and the rendering intent. 

Sort of (in a simplistic fashion of explanation). By the time the output profile ‘gets’ it’s data, it is in Lab, from the PCS and there is no recollection of ProPhoto at this stage of the game. How ProPhoto gets to Lab is one somewhat ambiguous part of this version 2 process of ICC profile conversion. Next, the shape of ProPhoto is quite simple and it is huge. This is often radically different than an output image, providing us a process of fitting round holes in square pegs or vise versa. Depending on the rendering intent, some in gamut colors may be affected as well as OOG colors. And all color values will be altered to the new color space, OOG or not. Lastly the ‘best way’ to decide on all this is to soft proof, look at the image and the effect of the rendering intent and pick the one you visually prefer. ICC profiles are not smart enough by a long shot to understand color in context. They see everything as a huge grid of solid colors.

[madmanchan]

Ideally the color transform to the printer space would be based on image content (i.e., image adaptive), but in most current ICC workflows they are not.  If you use soft proofing (and soft proof-based, output-specific adjustments) then in a sense you are controlling part of the color transform process in an image-adaptive manner.

[Ernst Dinkla]

Would it not be another rendering intent added in that case; Content Adaptive?  A high-key image fitting the gamut and dynamic range of a wide gamut printer is not desired either. I once argued that another CM rendering for B&W printing on a color printer could be added if there was more data stored in the profile to get better neutrals without paying attention to color accuracy further away from the neutral spine. Similar case.


--
Met vriendelijke groet, Ernst

340+ paper white spectral plots:
http://www.pigment-print.com/spectralplots/spectrumviz_1.htm
update april 2012: Harman by Hahnemühle, Innova IFA45 and more

[jbrembat]

Ideally the color transform to the printer space would be based on image content (i.e., image adaptive), but in most current ICC workflows they are not

In all ICC workflows they are not, as profile is generated without any knowledge of the image, ...but this is the ICC way.

Jacopo