Hi Jack,
I'm forwarding this to the mailing list, seems a very interesting subject and I would love! to know other opinions about this stuff. > I have some experience working with other color engines, as well. And I > have a general impression that virtually all cms engines think in terms of > transforms based on a single point, rather than a neighborhood. But, I > admit I haven't taken the time to digest the ICC spec. Quick glances at it > have given me the impression that it actually does define (the capability > of) transforms based on area (as well as single point). To my understanding, most major commercial CMM engines does use the one pixel approach. I'm unsure about KCMS, but at least Adobe ACE and ColorSync does operate in such way. Why this? It seems that a color engine could be "smart" enough to take advantage of neighborhood to better overall image appearance. And certainly, this would be possible, despite terribly complex, but in the way ICC profiles does work, this is ... well, hard to do, to say best. The profile does not contain measurement of devices, but also all tonal corrections, tweaks and gamut mapping to accomplish intents. So, all "smartness" is embedded into profiles, and not in the CMM. In this way, perceptual intents are done by simply passing the Lab or XYZ obtained by input profile to output one. Of course, a savvy CMM could "undo" all these corrections and then operate on raw colorimetric data, then it theoretically could do, for example, image-dependent gamut remapping, and this would be a nice feature for definitively better perceptual intents. Pity, there is anything in the profile that give any clues on what to undo... these corrections are a sort of "secret sauce" applied by each profile vendor. ICC has released a new spec 4.0, that intends to address some of these problems, but currently there are not any 4.0 compliant profiles, nor any CMM that does support them. Right now, any output profile does map the near infinite gamut of PCS to the finite one of device. And of course this way ahead from optimal. In the other hand, embedding all corrections into profile does give several benefits: Any CMM will use the technology embedded into profile, so, a gamut remapping implemented today, can run in a old PhotoShop 5.5 or ColorSync, and this is good. Also, this is the fastest way to do the translation. A image dependent process could take hours, even in a today machine. Probably to only give a slightly better result, so, overall, the one pixel approach is still valid and desirable. > I'm working on an app that need performance as well as image conversion to a > color space from a unique input profile. I'm tempted to build a massive 3D > LUT. So, I wanted to get your impression of the viability of making the > transforms so static. Oh, well, this is a device link profile, so, if you are planing to use same transform between same profiles over and over, you could build the device link and then reuse it. This will speed the transform creation time, but not the transform itself. lams, as most CMM, does compute a device link profile when creating transform. > Or, if necessary, do you have any suggestions on how to inspect the input > profile to insure it is strictly single point? All profiles does convert only one point at time, as said. Best regards, Mart� Maria The little cms project http://www.littlecms.com [EMAIL PROTECTED] _______________________________________________ Lcms-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/lcms-user
