Ben Goren wrote: Hi Ben, that's quite a difficult data set to make a good profile out of. > I can't even imagine any photographic situation where you'd have all three > channels > saturated / clipped / maxed out in the original where you'd want those areas > to get > rendered other than as pure white. Indeed, one of the big problems with RAW > processing I understand, but this is basically a desire for reasonable gamut mapping/clipping behaviour. If this was a situation where a single processing stage has all the required information, and had the job of implementing the gamut mapping/clipping behaviour, then it would be easy to achieve this desire. But the situation is actually much more messy and real world. The clipping is happening inside the camera, and represents a loss of the necessary information to clip correctly, and therefore there may be no means of behaving reasonably in all circumstances. For instance, there is no way to know what the input light level is when the device (camera) returns a value of 1. Does it happen to be exactly 1, or is it actually clipping ? Even if we knew this, what assumptions should we make about the ratio between channel values where one or more channels are clipping ? Consider a situation where I have three bright light sources facing the camera. For the purposes of this experiment assume that they have a smooth drop off in intensity with visual radius away from the centre of the lights. One light is D50, one is D65 and the third is a (not completely saturated) green. Assume the camera RGB channels are color balanced for D50 and that the profile returns D50 for 1,1,1, and that all three light sources saturate all camera channels at their centre (brightest) points. What does the image look like (completely ignoring glare etc.) ? The D50 light will be the same hue throughout its disk, but its brightness will clip at some radius. The D65 light will look slightly blue until it reaches a radius where the blue channel clips. It will than progress to a different hue until the next channel clips, and then progress with a hue transition to D50 as all 3 channels get clipped. The green light will get progressively brighter until the green channel starts to clip, and then (assuming R & B have non equal values) it's hue will change as it gets closer to the next channel clipping, and then it's hue will head in a different direction until the last channel clips, when it will be D50. While the visual result will look fine for the D50 light, the results for the other two light sources will look distinctly artificial, with halo's of different hues, with an ultimately incorrect clipped hue. Short of an "intelligent" image analyser that can make real world assumptions about the likely image composition and infer what the values of the clipped pixels is, there's not much you can do about this. Processing on a pixel by pixel value, you have no idea what 1,1,1 should really map to (or 1,X,X, or X,1,X or X,X,1, or 1,X,1, etc.) The real world solution to this if you want to capture accurate highlights is to stop the camera down to avoid clipping ! ie. to get good gamut mapping/clipping, you really need to do it after the camera with unclipped values, so that you can clip with constant hue. So while it's reasonable to suggest that 1,1,1 shouldn't map to some wild colored value, why should it map to exactly D50 rather than the best estimate of the white balance based on the measured patches ? [ The other thing is that creating a profile that doesn't at least attempt to fill the gamut, is really asking for extrapolation issues. If you assume additivity in the camara sensor, then probably the most robust profile for use with RAW input is to carefully linearise each channel using a separate calibration step (if needed), then create a matrix with no curves from the test chart. Extrapolation is then (by defintion) going to be perfectly consistent. If you don't need the general 3D mapping provided by cLUT profiles because your device is additive, then you are much better off not using them. ] > For a scanner or for a camera operated on a carefully-controlled copy table, > I can > understand how you might want to be wary of extrapolating beyond the gamut of > the > target. But for a camera off the copy table, I really don't think there's any > valid > assumption other than that the maximum possible input value should map to the > profile's > white point. Whatever the absolute color of that object, the camera saw it as > pure > white, and I think the profile should see it that way, too. But there's no guarantee that camera 1,1,1 is D50. For one thing the white test patch on the test chart may not (probably does not) map to R=G=B device values. And even if it did, you've chosen a cLUT profile, indicating that you do not trust that the the device is additive, implying that you do not trust that the same ratio of RGB values to always have the same chromaticity. If the test patch data indicated that the hue was not consistent down the R=G=B axis, then it would be correct to extrapolate in the same direction as indicated by the test points for device values beyond the RGB levels exercised by the test chart. This seems to be partly what's happening with your test set. I don't think it's correct to assume that brightness should clip at the test chart white patch either, if the device values have more headroom. That's really what the extrapolation is all about. Your particular test case seems rather extreme though. So much of the device response is compressed into tiny device values, that (for instance) it's almost impossible to get any sort accuracy out of the B2A table. This in itself probably calls for calibration before profiling, or an approach that uses a matrix profile. On some further investigation into the input profile extrapolation issues, I notice three things. One is that I have introduced a serious bug into the operation of -u. It simply isn't doing what it should in V1.4.0. I also notice that the extrapolation code is probably useful even in the non -u case, and lastly I notice that I can probably implement -u in a slightly more useful way, by distinguishing -u absolute and relative colorimetric by having relative correct the hue of the white test patch correctly, while scaling the Y to prevent clipping. In this way -u becomes an automated way of setting -U scale. I've put a snapshot of what I've been working on here <http://www.argyllcms.com/colprof_osx_exe.tgz> <http://www.argyllcms.com/colprof_win32_exe.zip> Graeme Gill.