16bit printing...your thoughts?

[hjulenissen]

Similarly if your relative difference in readings is .05, you can be assured that your value of 200 is reasonably certain.

Except if the spectrometer (or the patches) have a constant error.  Knowing the tolerances compared to a golden reference tells us more than simply observing the sample-variance.

If the "true" value is 200.42, then one instrument may measure [200 201 200 200 201], another may measure [200.99 200.98 200.99 200.98]. Which is most accurate?

-h

[Shane Webster]

Well there is a reference file that defines the expected values. So its not really fair to say that its just a test chart. One would assume the reference of the chart has the same degree of precision as the measurement data.

How precise is it when the pxf file generated by i1P truncates values.  Does this represent 8-bit information that i1P relies on when creating its profile.  If the same patch set is exported as a CGATs file for use with MT, the values are carried to the hundreth decimal place.  Would this then be 16-bit information that PMP relies on when creating its profile.  Having different values for the same item does not seem overly precise (regardless of its real world perceptibility).

In ColorThink, I compared testcharts created from i1P to testcharts created from MT based on non-truncated values and the values were the same for each.  It appears then that both MT and i1P create 8-bit TIFFs.  The is also seen in ColorLab.  I can take the patch set (shows decimals), convert to an image and then back to spot colors and the values are truncated.  Comparing this roundtrip to the original patch set generates an average Delta E of .46, maximum of 1.6, best 90% of .4 and worst 10% of 1.01.  If I've done my comparisons correctly (which may be a big if), it appears both MT and i1P generate testcharts with truncated values and, since the XML files generated by i1P contain truncated information, i1P compares measurement files of those truncated testcharts to truncated patch set information.  This may perhaps then lead to differences within MT because it is reading a chart based on truncated values to a patch set containing decimal values, but, as a property professor of mine long ago stated to our class, I may be meandering through the enchanted forest.   

[digitaldog]

How precise is it when the pxf file generated by i1P truncates values.  Does this represent 8-bit information that i1P relies on when creating its profile. 

Since the TIFF is 8-bits per color, I’d assume the reference is as well. And its kind of moot based on the data the TIFF is composed of.

It appears then that both MT and i1P create 8-bit TIFFs.

They do indeed.

[Shane Webster]

Since the TIFF is 8-bits per color, I’d assume the reference is as well

But it's not.  Opening the reference file in MT of the TIFF it created yields a first patch value of 109.3, 221.0, and 17.0.  Opening the TIFF yields values of 109.0, 221.0 and 17.0.

[Mark D Segal]

But it's not.  Opening the reference file in MT of the TIFF it created yields a first patch value of 109.3, 221.0, and 17.0.  Opening the TIFF yields values of 109.0, 221.0 and 17.0.

Does anyone reading this thread have an operational insight into the practical difference it makes to outcomes whether the first patch reads 109.0 or 109.3? This is a serious question, not a critique of the observation or of the fact that it was measured.

[digitaldog]

But it's not.  Opening the reference file in MT of the TIFF it created yields a first patch value of 109.3, 221.0, and 17.0.  Opening the TIFF yields values of 109.0, 221.0 and 17.0.

I wouldn’t assume that just because you have data after that decimal point its defining 16-bit data of what is obviously an 8-bit per color TIFF. Only X-Rite could tell us and I’d wonder why then they do not save out a high bit TIFF.

[Shane Webster]

Does anyone reading this thread have an operational insight into the practical difference it makes to outcomes whether the first patch reads 109.0 or 109.3?

I agree and it's is a question I've been curious about for the last week or so when I first noticed it.  The only thing I can tell you is when I compare the truncated TIFF values in ColorLab with the original values, the maximum Delta E is 1.6, with the worst 10% having a Delta E of 1.01, which means the differences would be perceptible to some (though probably only if they were looking).  I brought it up on this thread because the discussion became one of precision and having different values in different files when those files may or may not be used when creating a profile doesn't seem to be overly "precise" to me, regardless of its practical difference (though, ultimately, I realize it's the practical difference the matters). 

Only X-Rite could tell us and I’d wonder why then they do not save out a high bit TIFF.

Somehow I don't think that's going to happen anytime soon, but it would be nice if we were surprised.  Since I looked at the TIFF, I don't think it does make a difference in i1P.  Its XML data is truncated and the TIFF is 8-bit.  The difference could be in MT and PMP where if it's using the data exported from i1P, the reference would be 16-bit but the TIFF would be 8-bit, which would seem to lead to some erroneous colors, though, as Mark asks, I don't know the practical application of it or even if MT uses the 16-bit numbers or whether it truncates the values when creating a profile.

[JeffKohn]

That's incorrect. Make a set of patches in i1P and save them as a patch set file. Open the txt file at look at the RGB sample numbers - they *are* recorded at a high bit depth with multiple digits after the decimal! 8 bit targets are rounded and bastardized versions of these colors.

Well, this just further confirms my low opinion of the XRite/GMB programmers. But it doesn't prove that 16-bit TIFF's are needed for optimal profile quality, it just proves that the reference files are wrong. There's no reason that makes any sense for writing values in the reference file that don't exactly match the corresponding TIFF file, this can only be considered a bug.

So while I remain convinced that 16-bit profile targets are unnecessary, I'm glad this issue came up. Now I know that I need to correct my reference files before I do my next profile.

[Alan Goldhammer]

Does anyone reading this thread have an operational insight into the practical difference it makes to outcomes whether the first patch reads 109.0 or 109.3? This is a serious question, not a critique of the observation or of the fact that it was measured.

This is the $64 (US) question that begs an answer.  Many years ago when I was still a bench biochemist I had a project that involved a lot of spectroscopy and we highly concerned about the precision of the instruments that we were using.  One had service contracts on every single one of them since going out of spec would have grave consequences for the experimental results.  I'm pretty sure that the same type of QA/QC is not built into i1 (much less ColorMunkis) that X-Rite sells.  Now you can get the specification for the i1 here.  What you don't know is whether the deviation is constant throughout the spectral range of interest.  The short term repeatability appears to be quite good but it was only measured against white.  It might be useful to have information on 10 different patches across the spectrum.  I know from the little bit of work that I've done using ArgyllCMS and my ColorMunki that there is variability throughout the readings of the patch set.  What I don't know is how much of this is because of the paper I am profiling, how much is from the instrument, and finally how much might be from the printer driver's interpretation of the color that is being sent to it.

If one wanted to look at the ArgyllCMS algorithm the code is available for downloading.  The difficulty in all of this is that we are probably too worried about the precision of an instrument that probably cannot read to as many significant figures as our computers and software can handle.  It's very difficult to judge between the scientific precision of the instrument/profile making process and the outcome regarding the standard errors of the readings and the subsequent visual proof.  There are tools out there that can give one an insight into specific patch color and reliability of reading but the bottom line in all of this is to insure that there are no major gaps in the profile, that the gamut volume appears to be reasonable for the printer in question and finally that a well known test print (either one that is commonly used or one that you as a photographer have taken and know what is pleasing about it) can be reliably printed.  I think in the end this is what we can hope for.

[Trey]

I would make two comments about using 16bit printer. One is that once teaching a class, I printed a 4' by 17" print consisting of two white to black transitions as a demonstration of the difference of bit depth vs resolution. And a four foot 256 step grad right next to a four foot 65000 step grad is quite visibly astounding. This may not transfer into a real world advantage though, I am not sure.

The other point is that I tend to do a lot of photoshop work before I print and editing in 16bit files hardly ever get bashed very badly, as do the 8bit files. The histograms are usually smooth with no holes or spikes.

16bit files are a huge resource hog though. Some operations the take a few seconds in 8bit might take a minute or even more in 16bit. Saving the files is a pain also, although I have heard Adobe released a registry change that helps the files save, I believe, in 1/20 the time.

But as far as sending 8 or 16 bits to the printer, I am not sure I have noticed too much difference.