AuthorTopic: What defines the limits of gamut when profiling ? (Read 11988 times)

Rhossyd, ignoring instrument error and noise for the moment, in general the gamut limits (as shown in a gamut plot) are largely defined by the hardware setup and the number of samples measured. For example, when you see a gamut plot for a printer profile, what you're really seeing is a collection of measurements (at some sampling, e.g., 12 x 12 x 12 = 1728 samples, uniformly spaced in the device coordinate system) taken for a specific printer, paper, and ink, with a specific set of driver settings (and driver version). All of these have an impact on the results. The boundary in the gamut plot is the surface that contains the set of measurements ...

... in general the gamut limits (as shown in a gamut plot) are largely defined by the hardware setup and the number of samples measured.

The number of samples is surely more likely to effect the profile's accuracy, not the extent of gamut. Unless the sampling points have been very poorly chosen and don't test enough colours close to the gamut's limit.

Quote

For example, when you see a gamut plot for a printer profile, what you're really seeing is a collection of measurements (at some sampling, e.g., 12 x 12 x 12 = 1728 samples, uniformly spaced in the device coordinate system)

My understanding is that X-Rite (GMB) targets don't use a uniformly distributed range of sampling colours, but have a higher density of sampling points closer to the neutral axis. The uniform points are only within the profile, many of which may be created by interpolating the measurement data anyway.

Quote

The boundary in the gamut plot is the surface that contains the set of measurements ...

? Not sure that makes sense to me. Surely the majority of sampling points are within the gamut volume, not on the boundary.

The number of samples is surely more likely to effect the profile's accuracy, not the extent of gamut. Unless the sampling points have been very poorly chosen and don't test enough colours close to the gamut's limit.

Yes, but in general if you want to understand the shape of the gamut boundary, you need to have enough samples along the boundaries of the device coordinate space. For example, 8-bit samples along the boundary of a RGB device coordinate space might look like (0, 0, 0), (0, 0, 5), (0, 0, 10), ... (0, 0, 255).

What determines the gamut, as indicated earlier, is the printing system as a whole: printer, paper, ink, and driver settings. One thing I forgot to mention earlier is measurement geometry and assumed lighting conditions. Most colorimetry is based on 45/90 measurement and a D50 reference. If you view your prints under very non-D50-like light sources, the actual gamut would be very different.

Quote

My understanding is that X-Rite (GMB) targets don't use a uniformly distributed range of sampling colours, but have a higher density of sampling points closer to the neutral axis. The uniform points are only within the profile, many of which may be created by interpolating the measurement data anyway.

That depends on the target. For smaller targets, that is true. Some of the larger targets are uniformly spaced.

Quote

Not sure that makes sense to me. Surely the majority of sampling points are within the gamut volume, not on the boundary.

They are, but as indicated above, if you want an accurate plot of the boundary (e.g., when looking at a cross section at L* = 50), you need enough points on the boundary ...

What determines the gamut, as indicated earlier, is the printing system as a whole: printer, paper, ink, and driver settings. One thing I forgot to mention earlier is measurement geometry and assumed lighting conditions. Most colorimetry is based on 45/90 measurement and a D50 reference. If you view your prints under very non-D50-like light sources, the actual gamut would be very different.

My question is primarily about comparisons of profile gamuts and their boundary accuracy.

Quote

... if you want an accurate plot of the boundary ..... you need enough points on the boundary ...

This suggests that the number of samples used to build a profile and their range might be more important in defining gamut than any other issue.

This leads to other questions;Is there a minimum number of samples needed to build an ICC profile ? Is that number specified within the specification for ICC profiles ? If not, why not ?How are we to trust the claimed gamuts promoted on manufacturer's data if the quality of the profiling isn't declared ?

Er, yes. I did say that already and added some other possible factors. I'm starting to wonder of anyone here actually knows the answer.It seems an interesting issue to me when so much is concluded from gamut visualisations.

Actually I think you may be overcomplicating the concept.

If I'm profiling a printer, I'm going to send a series of colors and print them ... many of those are going to exceed the gamut of the printer. So whatever color results is the maximum that printer is capable of. I can't get a redder red or a bluer blue, etc

I measure that result so I now have an actual number of the devices maximum capability, and using that data can create a profile to defined that boundary and map all of the colors into the printers space.

How accurate? sure there are things that can affect that accuracy, and some devices are better than others. So you might see a profile built with a colorMunki as having a slightly smaller gamut volume than one built with an i1 Pro, but all the devices are very capable.

In the end, you have a gamut volume defined by testing the printer's capability, and your color management system is going to remap the image colors into that color space, so everything that gets sent to the printer is within it's capabilities. The overall gamut isn't a guess, but empirically measured to a highly accurate degree.

In fact I would be extremely surprised if most people can tell the difference between a print made with a profile from a colorMunki and one made using better devices. While perhaps the better device more accurately measures the colors, those measurements are at a level far beyond our ability to see them. (I just did this test, and out of about 20 people so far, they results are split ... and everyone of them admitted to just guessing because they really couldn't see a difference). the color munki profile is built by sampling only 100 colors, the i1 profile 1728.

My question is primarily about comparisons of profile gamuts and their boundary accuracy.

Understood. Just keep in mind that most plots are done with a D50 reference illuminant, so the "accuracy" of such a plot may not be meaningful to you. For example, comparisons between two gamut plots under D50 does not tell you how the gamuts of those two printing systems compare under a different lighting (e.g., an office fluorescent bulb under which prints may actually be hung).

Quote

This suggests that the number of samples used to build a profile and their range might be more important in defining gamut than any other issue.

No, in practice there are sufficient samples in most profiling systems to get a reasonable description of the gamut boundary. The primary factors that actually determine the gamut in practice are the main variables in the printing system, as indicated earlier: printer, paper, ink, and driver.

Quote

This leads to other questions;Is there a minimum number of samples needed to build an ICC profile ?

No. Technically, you can build an ICC profile without any samples.

Quote

Is that number specified within the specification for ICC profiles ? If not, why not ?

The ICC specification itself is not concerned with the quality of a profile. The specification is concerned with the format of the profile (i.e., how the description of a device can be interpreted in a portable, platform-independent way) and workflows. It is up to the creator (designer) of a profile to provide details about the quality of a profile and the methods used to build it, if he or she wishes.

No, in practice there are sufficient samples in most profiling systems to get a reasonable description of the gamut boundary. The primary factors that actually determine the gamut in practice are the main variables in the printing system, as indicated earlier: printer, paper, ink, and driver.

You're still assuming I'm talking just about printer profiles, but most of my concerns are with comparing printer profiles with monitor profiles.There seem to be potential differences between the accuracy of each type of profile, eg are reflective measurements more or less accurate than emisive measurements ? Screen profiling systems usually use far fewer samples for measurement than printer profiles, so are they likely to be less accurate ?

Quote

Technically, you can build an ICC profile without any samples

Which of course would be useless for characterising a device's output in the real world.

You're still assuming I'm talking just about printer profiles, but most of my concerns are with comparing printer profiles with monitor profiles.There seem to be potential differences between the accuracy of each type of profile, eg are reflective measurements more or less accurate than emisive measurements ? Screen profiling systems usually use far fewer samples for measurement than printer profiles, so are they likely to be less accurate ?Which of course would be useless for characterising a device's output in the real world.

Printer profiles need more samples than monitor profiles because they are typically more non-linear than monitors.

THe number of patches used to create the profile is based on the number needed to create a good profile. A lot of really smart people have put a lot of effort into figuring this stuff out, and most CM stuff works as advertised if you know how to use it properly. You're overanalyzing this stuff.

2) True, but manufacturers are promoting products on the basis of percentages of standard colourspaces. If errors in measurement are greater than the implied accuracy, those figures become rather futile.

The other issue is that gamut comparisons are often made via visualisation tools where DeltaE isn't used. I wonder if it's better to consider the gamut volume of devices more as soft edged 'clouds' rather than the tightly defined wireframes. If that makes sense, what would be useful to know is how fluffy the clouds are.

Trying to make it clearer: the statements for volume of gamut are plenty accurate enough, since you are not going to notice the difference unless it is large (like a 10% or more increase in maximum saturation). The only real problem with these comparisons is that they are often done as a percentage of the NTSC television standard area on a CIE 1931 chart, which doesn't do the best job of telling you how much perceivable volume you have lost or gained, or whether it's in important areas of the chart. So don't worry about how fluffy the clouds are.

On the other hand, you need to be concerned with precision if you are trying to determine if the primary colors of a display exactly match sRGB (or whatever standard you are after). Mismatching the primaries does make a difference in the displayed colors.

Another thing that gets left out of these discussions is the variability of color vision from viewer to viewer. The most accurate possible display only matches for the "standard observer." People with normal color discrimination can vary in the extreme by as much as +/- 20% in the ratio of red and green primaries to match a given yellow wavelength - and the wider the gamut of the display, the larger the variation. So, chasing the last decimal place is a hobby or a research project. A truly accurate color reproduction system would need a camera tuned to your personal cone sensitivities (color matching functions) running a display visually matched by you to your desired white point.

We frequently see comparisons of gamut, by volume or area, using various tools such as Color Think Pro, Gamutvision, Colorsync etc.Can someone explain if there’s a standard deviation factor(eg + or - 1.2 DeltaE ) that defines where the gamut boundaries are ? Is this enshrined in the ICC standards ?

Thanks

Paul

I'll take a shot at answering this. So regarding the accuracy of the 3d gamut projections, I can say that there is a bit of wiggle room for displaying gamut boundaries. First there is really no standardized way to do this. A simple method for drawing the boundary is to round trip color data e.g (lab > rgb > lab) and then plot the most saturated colors at different luminance steps. Now depending on the rendering intent used and the quality of the profile the accuracy of this projected gamut can certainly vary. There is also going to be a bit of a tolerance between the ICC profile's numerical representation of the printer's gamut, and what the actual printed result will be. Conversion "noise" when round tripping in gamut color can easily be about 2∆e, and you can expect another few ∆e between the expected results and the actual results. So the 3d boundary may be a fairly precise map of the ICC gamut but should be considered an approximation of the printer's gamut. The ICC profile is essentially a translation table and it's good at answering questions in the format of Given A what is B. For example trying to do something simple like determining if a single color is out of gamut is not an exact process.

So yes, when you are comparing two profiles, especially a printer and monitor profiles you can expect a bit of wiggle room regarding the actual boundaries of the profiles. Trying to come up with a general percentage as to how much this varies would be difficult since the linearity of the printer, quality and precision of the profile are going to vary widely. It's also going to vary by location in the color gamut. Also comparing gamut volumes is a poor tool for comparing two profiles as the difference in volume might be all in one area of could be spread throughout the profile and two different software packages could create profiles with two different gamut volumes from the same set of measurements.

To respond to a few other things:

There is not a direct correlation between sample patches and profile accuracy or precision. When building a profile most advanced software packages give you the ability to specify the internal bit depth of the profile and the size of the grid used in the LUT. You could measure a target with 3K patches and make a profile with fewer grid points, than a profile made with 50 patches. Also there is not a direct correlation between the measurement patches and the points in the LUT.

There is no standard regarding the number of patches needed for building a profile. Most software gives you an option. With RGB profiles I've found diminished return after 729 patches on most modern printers. When building CMYK profiles I generally use the 1617 patch IT87.4 target.

Determining the outer boundaries of a printer with reasonable accuracy does not take that many patches. If a device is fairly linear we can easily draw a line between two colors to extrapolate the gamut of the printer(which is what all 3d plots are doing.)

For very non linear devices more patches can be better. For a very linear device more patches can actually cause problems, especially if it is used for photographic purposes. HP when building the profiling software for the Z series printers was able to use very few patches and get fairly good results because they hardwired certain characteristics of the printer into the profiling model, having only to account for different media types. With general profiling packages they have to be able to account for radically different devices from offset presses and laser printers to inkjet and dyesub printers.

There is little correlation between profile accuracy and measurement device accuracy. A decent device like the i1 are calibrated to a standard well under 1∆e. Using the same software I would not expect measurements from a Munki vs an i1 to produce a profile with any important differences. When trying to certify proofs, or measure color standards where your tolerances are under 1∆e then instrumental differences such as measurement interval (10 vs 20 nm) or light source (xenon vs led) can be important.

Also comparing gamut volumes is a poor tool for comparing two profiles the difference in volume might be all in one area of could be spread throughout the profile

I'm afraid there's room for some confusion here. You can either 'compare volumes' by the crude tool of percentages, as monitor manufacturers are prone to do, but you can also 'compare volumes' visually with a visualisation tool such as Color Think or Gamutvision which should reveal far more useful information with respect to gamut limitations between devices.

Quote

two different software packages could create profiles with two different gamut volumes from the same set of measurements.

That would surely imply that one package would be failing to deliver correct results, yes ?

I'm afraid there's room for some confusion here. You can either 'compare volumes' by the crude tool of percentages, as monitor manufacturers are prone to do, but you can also 'compare volumes' visually with a visualisation tool such as Color Think or Gamutvision which should reveal far more useful information with respect to gamut limitations between devices.

That would surely imply that one package would be failing to deliver correct results, yes ?

Agreed, generating a gamut volume "by the numbers" is certainly a valid metric, although one that has a margin of error, and a degree of interpretation. For example if you want to find out the gamut volume of the sRGB color space, depending the tool you use, you may see the volume listed as 821K (∆e3) to 909K or some other number, and this is for a simple synthetic RGB profile. The volume is somewhat open to interpretation, as far as I know there is no standardized way of generating gamut volume nor is this something encoded in the ICC profile. So just looking at numbers doesn't tell you much. Visualizations of gamut are a much better tool, but treat them as a model rather than as a perfectly exact representation of the actual gamut of a device.

Regarding the second question, two packages can(and do) produce different results, and that is the expected behavior. The ICC spec only says, "hey, this is how you build and ICC profile" It sets how information should be encoded and organized, and what has to be included. How those LUT's are generated are up to the profiling software. Lets say I measure eight patches consisting of primaries, overprints a black and a media sample, (white, black, red,green, blue,cyan, and magenta,yellow) From that info I could build a profile. Of course to I would have to interpolate a lot of information but I could get something very crude. Obviously there is a lot of room to use different algorithms to fill in the blanks, and as long as I build a profile according to the ICC spec all would be valid. Of course this gets exponentially more complex when you have to make decisions about how to generate a "neutral" gray on a very blue paper, or how to create the perceptual rendering intent table. There is no strict procedural process for creating the table in a profile so some very smart people have come up with very novel and different ways of creating profiles, this secret sauce is why we own copies of Profiler and ProfileMaker. The two packages produce different flavors of profiles, the same way that a camera loaded with two different types of film (hmm is this analogy going to be unusable in another decade) or two different digital cameras will render a scene slightly differently, and yet both are equally correct(or incorrect).