Hi Gerhard, >the location of the media white point for input profiles >is also a topic I already wanted to discuss with you anyway >some time. Maybe it's the right opportunity now.
Yep. That stuff got me worried for a long time, and still. IMO, set proper white point is sorta crucial for a pleasant perceptual intent. > Basically, for a reflective medium, the media white > point is defined as the color if the unprinted paper, > so for scanning photos (printed on the same type of > paper as the IT8 target) the white point should be Dmin. This has proven to be quite true on scanners. But as you already noted, the media plays a very important role. There is a serious study done using the lcms profiler (not by me, by the way) that compares differences between targets on same media and different medias. The dE on same media is very good, below 1 in most cases, however, when media changes, it rises to 5 or even more. But this is not only for lcms profiler, other commercial profilers does exhibit same behavior. >- For a camera this is rather undesirable (you say the same). > The WP would depend on the exposure used for shooting the > target, and any profile generated from an unclipped IT8 > photo would always clip highlights, if WP==Dmax is chosen, > which is undesirable. Right. But here begins the troubles. How the profiler should infer which the white point is? Actually, lcms profiler does a extrapolation using gray patches in the target. Then, using regression, does a wild guess on what XYZ would be for an hypothetical 255, 255, 255. That works... sometimes. If the target grays results in a broad dynamic range, then all is fine since the profiler "knows" most part of gray axis. But, if the target is taking only a small part or camera's range, usually low part, then the profiler only knows about dark zones, and nothing about highlight, so the extrapolation is not likely to be very accurate. >- People also want to scan media, which are different > from the IT8 target, and which have a different WP. So, here perceptual intent comes in play. A chromatic adaptation to DMin, eliminates all tint the media has, and yield "nice" images. That is not going to be accurate in terms of dE, but most people doesn't care about that at all. >- For scanners, I also think that "perceptual" should scale > the black point, while the relcol intent must not. Agreed. Also, v4 ICC spec does clarify that. >- For cameras, where the actual medium is the "captured > natural scene" with a nearly unlimited dynamic range, > a black point is IMO rather meaningless and should > probalby placed a zero (and NOT at the IT8 Dmax point). That is not so clear :-) I agree DMax patch is, generally speaking, far above the true black point, but taking a BP of zero means all shadows in the image would be mapped to something above black, and often that results in washed out images. I've done some experimentation, and seems the best option is to choose a perceptual black point below DMax, and then doing a black point compensation to such black point. This increases the apparent contrast of image as well. >For flexibility, I think I would appreciate, if I the profiler >would offer me to choose between different algorithms for >determining and/or placing the media white point: Great. I'm very open to this kind of suggestions, so, let's try to see if the next release could have some of them :-) >1. "User Defined" > The user can freely specify the white point's XYZ manually. > This gives most flexibilty, even for unusual use cases. :-) This is already implemented! If you take a look on the presets, there are a couple of fields to force any WP/BP. In beta these are commented out, but at least white point should work. Be careful when changing that! improper white point could result in messed out profiles. >2. "Scanner" > Media white point = Dmin. That is the behavior for perceptual intent. >3. "Scanner (extended)" > Media white point assumes the same chromaticity as Dmin, but the > user can manually specify a white point luminance != Y(Dmin). > I guess this somehow corresponds to "push endpoints", does it? Good point. So, you could be able to increase the contrast of relative colorimetric intent without lowering dE. I will try to add this feature, seems very reasonable! No, not same than push endpoints, since that latter only increases the dynamic range for perceptual intent. DMin/DMax has only special meaning in perceptual. For relative colorimetric, they are just two patches more. >4. "Camera" > Media white point assumes the chromaticity of Dmin, but the > white point luminance is chosen in a way, such that even > R=G=B=255 (which is not necesssarily perfectly achromatic!) > is just *not yet* clipped by the resulting profile, and maps > to L* <= 100 in the PCS. This is how white point detection works in relative colorimetric. Even in scanners. Is quite easy to get DMin values below 255 in a scanner, and is also quite possible to get color over DMin. Fluorescence, for example. But I choose to map R=G=B=255 to L*=100 for safety reasons. Please note that this is a gamut boundary! >5. "Camera (extended)" > The user can manually specify the white point x,y chromaticity, > and the white point luminance is chosen in the same way as > above in (4). This is the difficult case. As said, the profiler can guess the x, y chromacity just exploring the gray patches, but regression knows nothing on the upper side of gamut, so all colors outside target's gamut are obtained by extrapolation. And extrapolation can get crazy sometimes. Regards, Marti Maria The little cms project http://www.littlecms.com [EMAIL PROTECTED] ----- Original Message ----- From: "Gerhard Fuernkranz" <[EMAIL PROTECTED]> To: "Marti Maria" <[EMAIL PROTECTED]> Sent: Wednesday, February 18, 2004 11:53 PM Subject: Re: [Lcms-user] Do DMin/DMax limit the scanner's dynamic range? Marti Maria schrieb: >This is up to profile builder and the intent. For example, >in the lcms profiler, perceptual intent does rescale dynamic >range to DMin/Dmax. Relative colorimetric does not. > >In scanners such rescaling would be desirable, but not >in digital cameras. > Hi Marti, the location of the media white point for input profiles is also a topic I already wanted to discuss with you anyway some time. Maybe it's the right opportunity now. IMO there are several considerations, and some of them are contradictory: - Basically, for a reflective medium, the media white point is defined as the color if the unprinted paper, so for scanning photos (printed on the same type of paper as the IT8 target) the white point should be Dmin. - For a camera this is rather undesirable (you say the same). The WP would depend on the exposure used for shooting the target, and any profile generated from an unclipped IT8 photo would always clip highlights, if WP==Dmax is chosen, which is undesirable. - People also want to scan media, which are different from the IT8 target, and which have a different WP. - For scanners, I also think that "perceptual" should scale the black point, while the relcol intent must not. - For cameras, where the actual medium is the "captured natural scene" with a nearly unlimited dynamic range, a black point is IMO rather meaningless and should probalby placed a zero (and NOT at the IT8 Dmax point). For flexibility, I think I would appreciate, if I the profiler would offer me to choose between different algorithms for determining and/or placing the media white point: 1. "User Defined" The user can freely specify the white point's XYZ manually. This gives most flexibilty, even for unusual use cases. 2. "Scanner" Media white point = Dmin. IMO the typical setting for scanning a reflective medium, where the media white point is defined as the color of the unprinted substrate. 3. "Scanner (extended)" Media white point assumes the same chromaticity as Dmin, but the user can manually specify a white point luminance != Y(Dmin). I guess this somehow corresponds to "push endpoints", does it? However, what I don't like with "push endpoints" is that I can only spefify a rather unspecific "percentage" and I don't know at which XYZ the profiler will actually place the WP. And I guess, it affects both, the WP and the BP, does it? 4. "Camera" Media white point assumes the chromaticity of Dmin, but the white point luminance is chosen in a way, such that even R=G=B=255 (which is not necesssarily perfectly achromatic!) is just *not yet* clipped by the resulting profile, and maps to L* <= 100 in the PCS. IMO this is what one would subjectively expect from digicam profiles. 5. "Camera (extended)" The user can manually specify the white point x,y chromaticity, and the white point luminance is chosen in the same way as above in (4). IMO this is useful, if the camera is not exactly white balanced to Dmin, but to a different chromaticity. Basically, in practice it is nearly impossible to white balance a digicam to the Dmin patch, neither with automatic nor with manual white balancing, since the patch is soooooo small. What's the consequence? I still must use a sheet of paper to perform the camera white balancing before I take a photo of the IT8 target. Or I need to use a white sheet of paper as backgound for the target (with automatic white balancing), in order that the camera achieves a reasonable white balance. However, since the cam is now basically white balanced to color of my paper sheet (which has a different chromaticity than Dmin), it would be wrong to use the Dmin chromaticity as media white point chromaticity, but the paper chromaticity needs to be used instead. (My experience is that bleached office/copier paper is pretty blue - I measured 7dE off neutral. Of course it also depends heavily on the brand) In the GUI I could imagine a dialog like this: +- Whitepoint location ------- | | XYZ: <XXXX> <YYYY> <ZZZZ> | x,y: <xxxx> <yyyy> | | {Dmin} {Camera} | +----------------------------- <...> are numeric input fields {Dmin} and {Camera} are buttons Initially, <XXXX> <YYYY> <ZZZZ> and <xxxx> <yyyy> are initialized with the color and chromaticity of Dmin. If the user changes any of the five fields, then the other fields are updated accordingly. Changing either <xxxx> or <yyyy> will update <XXXX> and <ZZZZ> (keeping <YYYY> constant), and changing <XXXX>, <YYYY> or <ZZZZ> will also update <xxxx> and <yyyy>. If the {Dmin} button is pressed, then the values for Dmin are again filled into all five input fields. Pressing the {Camera} button computes a white point luminance, such that RGB=255 is just not yet clipped by the resulting profile, and updates <XXXX> <YYYY> <ZZZZ> accordingly, keeping the WP chromaticity <xxxx> and <yyyy> unchanged. Desirable black point choices: 1. "Manual" The user can manually specify XYZ 2. "Dmax" For scanners 3. "Zero" For cameras Any objections? Kind Regards, Gerhard ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Lcms-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/lcms-user
