Ben Goren wrote: Hi, > That's what the RAW software already does, but Argyll is unaware that it's > happened and > basically attempts to re-apply that same process. Furthermore, RAW software > is designed The processes are in the wrong order. Convert to color managed space, then select white point. Anything else is fairly crazy (how can you evaluate the image in an unknown device specific space ?). The RAW converters need some re-jigging to be color managed. Clipping colors above the white point in a chromatically consistent manner is something that should be done right at the point the white point is set, not some time afterwards. [ie. it seems to me that you are trying to patch up some fundamental issues with the workflow, and this is not a good long term strategy. Better to fix the workflow, if possible.] In any case, I don't want to do anything unexpected - the absolute colorimetric response is meant to faithfully represent the device behaviour, not be perceptually processed in anticipation of one particular workflow. You can in principle take the profile from Argyll and re-process it (or use it) in a manner that does what you want, but you can't do the reverse - you can't take a profile that clips above the white and undo the clipping, since the information is gone. > to align the channels such that everything that's spectrally flat should when > it's done > already have equal RGB values, at least for whatever's lit by the > (impossible-to-guess-after-RAW-development) illuminant the RAW software used > for the > scene. I'm not sure I follow this. Why is a spectrally flat sample of much importance ? The viewer won't adapt to a spectrally flat white unless it's present in the image. They will adapt instead to whatever appears to be white, something that is impossible to accurately quantify (being a complicated visual and cognitive process). It can be approximated by various algorithms (which is good for mass processing of images and a first cut), but for the best results really needs to be done manually. Setting a white point for an image on capture is done for two reasons, both driven by the output referred nature of most reproductions: 1) To maximise the quality of subsequent media renderings. You get the best brightness and color vividness if the white of the image is close to the white of subsequent media. 2) Because often the media color is visible in subsequent renderings, forcing the viewer to adapt to it (ie. on displays there will be other white elements, in print there is often surrounding non-printed media color.) > However, I can state with great confidence from empirical testing that adding > the > synthetic black and white points to the .ti3 and handing it off to the latest > official > release of colprof with no processing options results in a profile that's > both as close > to colorimetrically correct as I think it's possible to get and visually most > pleasing > as well. For the proof, see my previous post with the four images, and do a > blink > comparison. The appearances of the synthetic charts and the photographed > version with > the D50 white and black patches are almost indistinguishable. Remove the D50 > lines from > the .ti3 and the charts are instantly discernible even in side-by-side > comparisons. I'm sure it helps your workflow. The problem is that it's just one workflow, and I think it will severely compromise the usefulness of the profiles to cater for just that workflow. Now, maybe it could be added as an option, but I'm very dubious about mapping 1,1,1 to D50 in the raw data - it would make more sense in your workflow to map any colors over the media white point to D50 (assuming the media white point is the white point you want). > So...on the one hand, the ``right'' answer would be for Argyll to do its > magic on the > RAW camera data, but that would mean you'd have to get into the business of > Bayer > demosaicing and all the rest -- not something I think you're interested in. > (But if you > are, I'll *really* get excited!) It's on my list of things I'd like to look into (especially if it seems that many of the RAW converters aren't properly color managed), but I can't see that happening any time soon :-( :-( > That's why I still think the least-worst answer would to be to add a switch > to colprof > that says, ``the input is from a typical modern DSLR that's been through RAW > processing > and thus is already white balanced and clipped, so assume that the endpoints > of the > gray axis are already where they should be.'' I'll look into a "clip to white point" option. It may do what you want. Cheers, Graeme Gill.