16bit printing...your thoughts?

[Scott Martin]

Even if you did create such a target, I'm not sure our spectro's are accurate enough to register such minute differences reliably.

Oh sure they do. ColorPort saves measurements down to the thousandth of a integer (like 127.583 instead of just 127). Working at this level of accuracy is what Bill Atkinson's targets were all about right?

Trying to measure so many closely-spaced data points could actually hurt profile smoothness. I've seen this when creating monochrome profiles using QuadToneRIP's  QTR-Create-ICC. I got smoother results by averaging multiple 21-step charts than I did by 1 (or mulitple averaged) 51-step charts.

I prefer the QTR 21 step chart as well. But we're not really talking about increasing the *number* of data points are we? We're talking about the *accuracy* of the data points we've got - even if it's just 21 patches. Rounding the data up or down for each patch (via 8 bit values) could potentially be harmful. Your 21 patch results are even better when they (target and measurements) are at high bit depth.

To take your idea a bit further, I'm really excited that i1Profiler produces excellent results with a relatively small number of patches. And I'll suggest that the results are a little better when those small number of patches are at high bit depth. I'll suggest that a high bit depth 800 patch chart yields better results than a 3000+ patch 8 bit target. Follow me on this? Checkout my RGB targets at http://www.on-sight.com/downloads/ if you like.

[hjulenissen]

Oh sure they do. ColorPort saves measurements down to the thousandth of a integer (like 127.583 instead of just 127). Working at this level of accuracy is what Bill Atkinson's targets were all about right?

But does it contain useful information in those decimals?

If you take any 8-bit number (e.g. "42") and add 1/3, it will need lots of bits to be represented (at least using decimal representation): 42.3333333333... but does it contain any more information than "42"?

-h

[Scott Martin]

It is more information and it is useful. How much exactly is up for debate. The returns are super minor if any. Still, it's fun to strive for perfection.

[Mark D Segal]

I think the whole chain of inkjet printing has reached a level of maturity such that henceforward, save for any absolutely unanticipated quantum leap forward in materials technology or software, gains of visible quality are likely to be bit-by-bit. But over time, these little bits accumulate, such that after a few years, looking back, one would see improvement. In this regard, it's good to stay on top of the little bits as they accrue, even though they seem "little" at the time.

[JeffKohn]

Oh sure they do. ColorPort saves measurements down to the thousandth of a integer (like 127.583 instead of just 127). Working at this level of accuracy is what Bill Atkinson's targets were all about right?

But read a chart multiple times and you won't get exactly the same values for each patch. My argument is that you would actually be better off duplicating an 8-bit value and averaging the readings, rather than having patch values of 127.583 and 127.852 and assuming the difference you measure is precise enough to be useful data.

I prefer the QTR 21 step chart as well. But we're not really talking about increasing the *number* of data points are we? We're talking about the *accuracy* of the data points we've got - even if it's just 21 patches. Rounding the data up or down for each patch (via 8 bit values) could potentially be harmful. Your 21 patch results are even better when they (target and measurements) are at high bit depth.

No, we're talking about synthetic charts here, not real-world photos where a 16-bit capture loses data when converted to 8-bit. As long as the 127,127,127 patch really is 127.000, 127.000, 127.000, it's perfectly accurately represented in 8-bit color. It's just as accurate as a 16-bit patch with a value of 127.333, 127.333, 127.333. There's no data loss from 8-bit here because the chart values are exact 8-bit values to start with. That's what I mean with my original statement about chart size. If you're going to measure 3000 patches out of billions of potential values, there's no reason not to choose the values that happen to be exact 8-bit values.

[digitaldog]

I’m not sure there is much to gain between a true 16-bit produced target and one that’s 8-bits per color. None the less, the engines that build these targets can (and I would suggest should) feed us 16-bit TIFFs as we can convert to 8-bit per color but going the other way, not so sure. I can’t believe its big engineering for X-Rite to spit out a 16-bit TIFF. I don’t see any downsides.

Could take Bill’s 16-bit target, print, measure and compare to the same target converted to 8-bits per color. But in the end, the delta’s would probably be differences we expect to see with multiple measurements of the same target. And I’d agree, its probably a lot better to just sample a number of targets and build the profile, certainly for some devices (presses).

[hjulenissen]

It is more information and it is useful. How much exactly is up for debate. The returns are super minor if any. Still, it's fun to strive for perfection.

Adding 1/3 to a number does not add information. If you think that the number of stored bits indicate more information, then you are simply wrong.

Now, if you think that those bits does add information, you need to present some other argument than the number of bits stored.

-k

[Mark D Segal]

If I understand this correctly, I believe at the very least it adds precision to the calculations. And if you have more distinguishable finite levels, is this not "adding information"?

[JeffKohn]

If I understand this correctly, I believe at the very least it adds precision to the calculations.

What calculations? We're talking about a test-chart, not the measurements or actual profile profile generation.

And if you have more distinguishable finite levels, is this not "adding information"?

No. If you are printing a target with 3,000 patches, whether you take those samples out of 16 million possible values or several billion doesn't determine the accuracy of the values selected.

You guys don't seem to understand precision versus accuracy. You're arguing that a 16-bit value is more accurate than an 8-bit value for all color values. That's true for 16-bit color values that fall in-between the possible 8-bit values; but for the 16million colors that can be exactly represented as 8-bit values, that just isn't true.

[Scott Martin]

But read a chart multiple times and you won't get exactly the same values for each patch.

Sure, this is an issue of *tolerance* isn't it? At what digit do we see variations? If we always saw variations at the first digit ofter the decimal then I'd agree the additional digits aren't helpful. However, I'm finding that the measurement variations occur (with my instruments) at the second and third digits after the decimal. From this I'd conclude that the additional information, particularly the first digit after the decimal, is valuable extra precision/information. Your results may vary especially if you're using a device with looser tolerances, like an EyeOne Pro.

My argument is that you would actually be better off.....

Have you tested your argument or is it just theory? Have you compared repeated 16bit measurements from true 16bit targets?

No, we're talking about synthetic charts here, not real-world photos where a 16-bit capture loses data when converted to 8-bit.

When we ask i1Profiler to render profiling target patches it can either render them at 16 bits with greater precision or round the numbers to an 8 bit scale. In a manner of speaking, one might say that prior to rendering the targets, the reference colors *are* at a high bit depth. So your analogy to a 16 bit capture workflow is intact with this comparison along with the potential benefits.

There's no data loss from 8-bit here because the chart values are exact 8-bit values to start with.

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.

I think it's fair to say true 16bit targets and measurements and reference files offer greater precision. What's harder to quantify is how much benefit there is to using them. When I compared Canon's 16bit output with 8 and 16 bit profiling in Monaco Profiler I actually saw slightly smoother results with the 16 bit profiles. I need to repeat this test in i1Profiler - with their smoothing the benefits could be negligible if any. Either way I'm starting to think I'm the only person with a true 16 bit profiling workflow that's capable of showing any potential benefits...

I’d agree, its probably a lot better to just sample a number of targets and build the profile.

Probably? Don't assume - test it! I've tested and seen benefits in the past, allbeit small. My demanding clients that have used lots of other profiling services say they are crazy happy with these 16 bit profiles. Let's talk real world results - not theory.

[Alan Goldhammer]

I’m not sure there is much to gain between a true 16-bit produced target and one that’s 8-bits per color. None the less, the engines that build these targets can (and I would suggest should) feed us 16-bit TIFFs as we can convert to 8-bit per color but going the other way, not so sure. I can’t believe its big engineering for X-Rite to spit out a 16-bit TIFF. I don’t see any downsides.

Could take Bill’s 16-bit target, print, measure and compare to the same target converted to 8-bits per color. But in the end, the delta’s would probably be differences we expect to see with multiple measurements of the same target. And I’d agree, its probably a lot better to just sample a number of targets and build the profile, certainly for some devices (presses).

The one way to do the experiment is to use ArgyllCMS where you do have the choice between 8 and 16 bit targets (along with a lot of other options).

[Scott Martin]

The one way to do the experiment is to use ArgyllCMS where you do have the choice between 8 and 16 bit targets (along with a lot of other options).

Do you mean to say that's 'one way of doing the experiment', or that's 'the one and only way of doing it'?

[Alan Goldhammer]

Do you mean to say that's 'one way of doing the experiment', or that's 'the one and only way of doing it'?

Former and not the latter.  I only have access to Argyll as it is free to use; other tools may prove useful as well but cost money.   I'm waiting on an i1 to arrive so I can really start building some Argyll profiles (been using a ColorMunki to date which works but I've been concerned that it's a UV cut spectro (and also not built to the same tolerance as an i1 - I hope) and I'm going to miss something in papers that might have mild OBAs such as Ilford GFS and Hahnmuhle Photo Rag Ultra Smooth).  To date the CM Argyll profiles are quite good.

[Passnga]

Without reading through the entire thread, and rereading your first question regarding printing, I believe, and Farmer or Jeff Shewe may correct me here, Epson printers are still only working in 8bit. Not that that means you should work in 16bit but rather that the printers themselves are only 8bit.
I would work in 16bit as far processing and working on images but that doesn't mean the printer prints in 16bit. I could be wrong though...

[Mark D Segal]

What calculations? We're talking about a test-chart, not the measurements or actual profile profile generation.
No. If you are printing a target with 3,000 patches, whether you take those samples out of 16 million possible values or several billion doesn't determine the accuracy of the values selected.

You guys don't seem to understand precision versus accuracy. You're arguing that a 16-bit value is more accurate than an 8-bit value for all color values. That's true for 16-bit color values that fall in-between the possible 8-bit values; but for the 16million colors that can be exactly represented as 8-bit values, that just isn't true.

Yes I know we are talking about a chart. The chart is a printed image file. Each patch represents file numbers. Those numbers will be read by a spectro and the differences between the readings and the file numbers determine the translations the CMS will need to make for colour managing the printer. So it would seem logical to me that the precision/accuracy of the target print would influence the calculations of the profile generated with it and from there the calculations in the CMS. I agree with your last sentence; it makes sense, but are we sure that all the patches in a target represent true 8-bit values?

[alain]

...
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.
...

This seems and an explanation and a rather stupid error inside i1P.  The software knows it's generating 8-bit data, but stores them as a different RGB number inside the patch set file.  So when generating the patch set file it's already wrong.

When the software knows that the generated value is for example 70,120,130  (8-bit max) and stores it with reference 70.5,120.3,130.4 ...  I hope that they do the other calculations a bit more correct. 

[hjulenissen]

Yes I know we are talking about a chart. The chart is a printed image file. Each patch represents file numbers. Those numbers will be read by a spectro and the differences between the readings and the file numbers determine the translations the CMS will need to make for colour managing the printer. So it would seem logical to me that the precision/accuracy of the target print would influence the calculations of the profile generated with it and from there the calculations in the CMS. I agree with your last sentence; it makes sense, but are we sure that all the patches in a target represent true 8-bit values?

I think that it is difficult to say anything conclusive without detailed knowledge of each component in the pipeline.

My objection was with claims ala "16 bits must give more precision than 8 bits". Clearly, that is not a valid claim. If the spectrometer or anything else along the chain is limited by analog noise, A/D or D/A conversion, digital processing precision or elsewhere to a precision similar to 8 bits or below, the benefit from doing 16 bits anywhere may be small or none.

This can most easily be seen by doing a digital conversion from 8 bit representation to 16 bit representation. The latter will consume twice the amount of storage/bandwidth, but will add no information.

-h

[hjulenissen]

Sure, this is an issue of *tolerance* isn't it? At what digit do we see variations? If we always saw variations at the first digit ofter the decimal then I'd agree the additional digits aren't helpful. However, I'm finding that the measurement variations occur (with my instruments) at the second and third digits after the decimal. From this I'd conclude that the additional information, particularly the first digit after the decimal, is valuable extra precision/information. Your results may vary especially if you're using a device with looser tolerances, like an EyeOne Pro.

Then you seem to assume that errors have to be random (noise). A systematic error (like adding a constant, or quantizing to 8 bits) may give series of measurements that have (near) identical values without this variance being a good indicator of the absolute precision.

-h

[Alan Goldhammer]

It's little bit like arguing how many angels can dance on the head of a pin.  Once can pick the simplest of test charts to print out so that reading is easy.  You can read the patches and see if there is a measurable difference, but we need to know where the weak link is in the chain.  I suspect it will be the spectro in regards to its precision and it's differential repeatability.  If you have a value of 200.0007 but the instrument is capable of only reading to 1/100 of a unit the extra data you have is meaningless.  Similarly if your relative difference in readings is .05, you can be assured that your value of 200 is reasonably certain.  Now I can create an ArgyllCMS profile and run the profcheck utility and get a direct read on every one of the 980 patches that I've read, with the relative error, the RGB value, and LAB values and the difference in the LAB values and what they should be.  When I examine the data in Excel I see readouts of 7 significant figures; I doubt that my ColorMunki has this kind of precision (I know from some early testing that its variance between duplicate readings is roughly 0.25% which is probably pretty good for an instrument in this price range).  So we are left with the question of 8 or 16 bits for targets (and I run an Epson on Win7 so my prints are in 8 bits).

[digitaldog]

What calculations? We're talking about a test-chart, not the measurements or actual profile profile generation.

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.