File saving questions

<p>Friends, I am trying to determine how to best save a file all the while keeping the file size to a minimum for storage economy.<br>

My workflow takes me from LR to PS. I work in 16bit and the file sizes in that format are in the range of 200-250mb. Typically, I will save the file as a tiff but reduce it to 8bit to save space. I will print from that smaller file.<br>

So my first question is whether I can resurrect the 16bit file from the 8bit file if I decide to rework the image, or have I lost the advantage once it is converted to the smaller format. I do this by just changing the format in the "image" command. But I do not know if is truly 16bit - the same as the original file.<br>

Is there any discernible difference in printing from an 8bit vs 16bit file.<br>

Am I better of keeping the 16bit file and compressing it in the course of the save process vs converting to 8 bit as saving it uncompressed, as I currently do. If I open the compressed 16bit file, does it return to its original state?<br>

By the way, I am printing mostly in the 20"x 30" range.<br>

David</p>

<blockquote>

<p>So my first question is whether I can resurrect the 16bit file from the 8bit file if I decide to rework the image, or have I lost the advantage once it is converted to the smaller format.</p>

</blockquote>

<p>No!</p>

<blockquote>

<p>Is there any discernible difference in printing from an 8bit vs 16bit file.</p>

</blockquote>

<p>For printing, there should be no difference. Most printers are sending 8-bits per color through the driver anyway. One rare exception are some Epson printers on Mac where the driver has the ability to send all "<em>16-bits</em>" (I prefer <em>high bit</em> data) to the driver. I see zero difference. Even under a good loupe. <br /> IF you're done with all editing, you could reduce to 8-bits per color but I still wouldn't; storage is cheap, output technology improves and the time <em>could</em> come where the high bit data would produce a superior output. <br /> This might clear up some confusion about high bit data:<br /> http://digitaldog.net/files/TheHighBitdepthDebate.pdf</p>

<p>Andrew, based on you comments, when scanning film, would it be pointless to scan at 16 bits rather than 8 bits?</p>

<blockquote>

<p>Andrew, based on you comments, when scanning film, would it be pointless to scan at 16 bits rather than 8 bits?</p>

</blockquote>

<p>It's <em>only</em> pointless if you do 100% of the global editing IN the scanner driver. High bit data is about editing overhead. </p>

<p>It is true that we write plates with a 8bit color depth. - OTOH: If we adjust the contrast in an 8bit file we ditch some of the imaginable 256 nuances of grey. - Also: it can make sense to print with multiple inks per color, duotones or all that "light cyan" etc. stuff inkjets are using these days. That way the prints should go beyond 8 bit.<br>

Also: 16 bit color doesn't pop under a loupe; it makes the difference in weird nuances, like "Kawasaki green", which is close to impossible to 4c print with plain Europa Scala. - There are different 4c mixtures that do a significantly better job on it and of course some folks figured out how to do 6c etc on offset presses.<br>

Look at monitors: the 10bit ones simply promise to display more different colors than their 8bit counterparts. <br>

I would not dare to ditch the extra bits before I am sure that I have the perfect monitor to judge my results.</p>

Buy more disk drive space.

 

An external drive with 20 terabytes of space (that's 20,000 gigabytes) can store 80,000 of your 250 MB files and can be had for under

$2,000. The storage cost per image would be 2.5 cents per image. Of course, a backup strategy will require additional disk, which might

triple the cost per image to about 7.5 cents.

<p>I think there may be some confusion here about bit depth. It's simply math used to divide up <em>device values</em>**. It has nothing to do per se with color gamut. It has nothing to do per se with dynamic range. More bits doesn't produce a wider or narrower color gamut or DR! Think of a 9 inch apple pie that weights 2lbs. You can slice it into 8 pieces or 16 pieces. It is still a 9 inch pie that weights 2lbs. We desire high bit data because when we edit the device values, rounding errors occur. At some point, if the editing is excessive, the result can be banding that appears on the output device. You can take an 8-bit per color gradient which looks smooth and will output smoothly, apply the Posterize command in Photoshop and enter a smaller value and boom; banding. That command simple takes the value you ask for and reduces the original number of device values to that number.</p>

<blockquote>

<p>Also: 16 bit color doesn't pop under a loupe; it makes the difference in weird nuances, like "Kawasaki green", which is close to impossible to 4c print with plain Europa Scala</p>

</blockquote>

<p>That has absolutely <strong>nothing</strong> to do with the encoding; the bit depth of the data! I have no idea what <em>Kawasaki green</em> is <em>supposed</em> to mean or what color space you're referring to. This is an issue of color gamut; <strong>the range of colors</strong> and has <strong>nothing</strong> to do with bit depth.</p>

<blockquote>

<p>Look at monitors: the 10bit ones simply promise to display more different colors than their 8bit counterparts.</p>

</blockquote>

<p>No, it doesn't. You're confusing colors with <em>device values</em>! We can produce device values that are not colors. For example, G255/R0/B0 in ProPhoto RGB is not a color. It <strong>is</strong> a device values! And it doesn't matter if you use this as an 8-bit per color or 16-bit per color division of device values, it's not and never will be a color. The same is true of G254/R0/G0, or G254.87/R0.00/B0.10, it's still not a color. Further, two device values can be the same color! In sRGB, 2/255/240 and 1/255/240 have the same Lab values (90/-54/-8). Two sets of RGB device values, numbers that <strong>define one color.</strong> As such, we can’t count that example as defining two colors, we can’t see any difference between them.<br /> The <strong>ONLY</strong> useful attribute of high bit data is editing overhead such you can send the best 24-bits of color to an output device. More bits doesn't provide anything further! <br /> The reason why it's prudent to use high bit data with wide gamut color spaces is this editing can take a higher toll on the reduction of <em>device values</em>. The distance between any two color values in a wider gamut color space are colorimetrically farther apart. Consider sRGB as a half inflated balloon with 16.7 dots painted on it***. Those dots <strong>are</strong> device values that can be produced simply by virtue of math alone! Just like the division of the pie above. Consider ProPhoto RGB as the same balloon inflated twice the size of sRGB; the distance between the 16.7 million dots are spread farther apart. Editing on that data can produce banding faster and more likely than the smaller color gamut sRGB color space. That's it! Overhead for editing. <br /> ** Some need to read this carefully:<br /> http://digitaldog.net/files/ColorNumbersColorGamut.pdf<br /> *** we can define 16.7 million device values. We human's can't see anything close to 16.7 million colors. Don't confuse a device value for a color! When the display manufacturers tell you their displays can produce billions of colors, it's a marketing lie! You can't see anything close to that number of colors. They can produce billions of device values; huge difference.</p>

Andrew, when i scan, i rough adjust the Level range

only. All other adjustments are done in LR to the

scanned image file. So in this case, it's it better to

scan with 16 bits rather than 8?

<blockquote>

<p>All other adjustments are done in LR to the scanned image file. So in this case, it's it better to scan with 16 bits rather than 8?</p>

</blockquote>

<p>Yes. While LR does all processing in high bit, linear color space who's gamut matches ProPhoto RGB, you would ideally do all processing in the scanner driver <strong>or</strong>, pass high bit to LR. </p>