16 bit files

[shoreboy]

Is it standard practice to work on 16 bit files?

[skoobey]

Re: 16 bit files

If that's your standard, yes. 8,16,32 are all widely used.

16 is the most common for published work, yes.

It's about knowing what you need, and not wasting time on 16 when noone is going to know the difference, or knowing that you need that 32bit on some composite work in order no to clip things etc.

[shoreboy]

Re: 16 bit files

Thanks for the informative answer.

[redcrown]

Re: 16 bit files

Lot's of info and debate out there. Here are 3 from my bookmarks:

http://www.digitaloutput.net/content/ContentCT.asp?P=350

http://staging.digitalphotopro.com/gear/imaging-tech/the-bit-depth-decision.html

http://www.creativepro.com/article/out-of-gamut-the-high-bit-advantage

[Repairman]

Re: 16 bit files

If you are working on an industrial strength Mac I would work 16bit as the larger file size won't make too much difference to your speed. 50% of the images I work on come from Maya as 32 bit RGB files; they invariably go out the door as 8bit CMYK. The differences in quality are easy to spot but that is only by comparing two images side by side - not something the end viewer will be able to do or care about. Looking at 16 and 8 side by side will show up differences in tonal integrity but it is very much case dependent. I would archive as 16bit basically to futureproof the file - could be that those subtle but significant differences will be easier to appreciate in print or digitally further down the line.

[skoobey]

Re: 16 bit files

Lemme put it this way:

You're working a 20$ an image quick catalog/web retouch, you're doing it at 8bit and forgetting about it. Same for the model test, portrait for print that is quater of the page or smaller...

You're doing a campaign with plenty of DNB, you want those extra bits.

[klev]

Re: 16 bit files

If you are working on an industrial strength Mac I would work 16bit as the larger file size won't make too much difference to your speed. 50% of the images I work on come from Maya as 32 bit RGB files; they invariably go out the door as 8bit CMYK. The differences in quality are easy to spot but that is only by comparing two images side by side - not something the end viewer will be able to do or care about. Looking at 16 and 8 side by side will show up differences in tonal integrity but it is very much case dependent. I would archive as 16bit basically to futureproof the file - could be that those subtle but significant differences will be easier to appreciate in print or digitally further down the line.

I want to point out that those 32 bit files are fundamentally different in their encoding. A conversion in photoshop from 8 to 16 bits can be done with a simple zero extension. Other than that it's organized in the same way. Maya outputs 32 bit files in a floating point encoding and gamma 1.0 space. To use ICC profiles, you are restricted to v4 types for this kind of encoding. It also handles a much wider range with the typical 0-255 converted to 0.0 to 1.0 with an actual range of plus or minus a very large number. Depending on the color engine, you have to be careful when converting between color spaces there, as some of them will clamp at unexpected stages.

I've expected to see more raw converters go that way for years. I mean you do have some rounding as floating point math is different in the sense that not every number in its range is a part of its domain, but it's viable with a stable math library and 32 bit encoding. We just need more packages to support a full set of tools in that encoding, which unfortunately means a much more significant rewrite than what it took to go from 8 bits to 16.

[Repairman]

Re: 16 bit files

Can you put that in layman's terms Klev!

[klev]

Re: 16 bit files

There are probably two major differences that would be of interest to you.

The first is that each time the value doubles, the brightness doubles. The second is that you have a much much wider range of values that can be stored. Instead of 0-255, the equivalent range is 0.0 to 1.0, but it can store values in excess of 10.0 or -10.0 assuming you don't make any changes that force it to clip anything outside of the 0 to 1.0 range. I don't have a full list of actions that force that. For example you have to test profile conversions, as different color engines deal with these things differently.

When I mentioned ICC v2 vs v4, they're both ICC profile types. v2 are the older ones, which cannot be used in photoshop's 32 bit mode. Maya uses something that they refer to as linear sRGB, and I see the name come up quite a bit. I haven't been able to find a standardized representation of it. Anyway just like with other profiles, these things are converted to a form suitable for viewing on screen.

I guess the thing that's really interesting is you should have some ability to bring back blown highlights and things if you receive a 32 bit file that wasn't set to clamp anything that fell a couple stops out of range. Some color correction tools also offer a lot more flexibility, and they could design dodge/burn tools that would also offer greater flexibility. By the way clamp = clip for all practical purposes.

Some software has also started to implement or implemented linear tools for painting. There's sillouette fx, and I think Krita has some on the open source end. The OSX version is still basically alpha software, but I want to contribute to it if I get the time. I've said for years that Adobe should go this route.

Regarding raw files you could basically dump the full range of that file from lightroom into photoshop still in Adobe's linear prophoto space (prophoto isn't ideal, but it's what they use) without converting to a narrower gamut and clipping anything out of range. If you combined that with some of the newer edge finding algorithms that have surfaced in the past five years or so (ironically microsoft research has contributed to this), you could get a really nice balance of contrast and details. I don't really care for the typical cartoony HDR thing, but you just gain so much more control with such a workflow.

[skoobey]

Re: 16 bit files

Or even simpler...

It's all number of combinations 8bit has 256 different lightness values for R, G and B.

16 bit has 65536.

32bit has 16777216.

Just an example, I know it's not real thing that you can see, and that it depends on the actual color profile blah blah.

But, what does this mean? Well, in reality, it means smoother transitions when you start pushing pixels.

So, a curve applied to something smooth like a sunny sky in 8 bit might leave you with a posterized looking result.

16 bit bit file, when affected by the same curve will be much smoother.

And 32 bit? Well, it won't even clip where the 16 bit clips, meaning if you blow something out, and than do an opposite adjustment, it might just bring it back. Why? Because there is more tonal differences.

[klev]

Re: 16 bit files

Or even simpler...

It's all number of combinations 8bit has 256 different lightness values for R, G and B.

16 bit has 65536.

32bit has 16777216.

Just an example, I know it's not real thing that you can see, and that it depends on the actual color profile blah blah.

That's not exactly it. One is stored as integer values. The other is stored in a linear floating point encoding, so no they are not comparable. In photoshop 16 bits stores the same range with more steps. 32 bits stores a wider range. They're stored in gamma 1.0, which is independent of their being floating point values.

[Repairman]

Re: 16 bit files

Sometimes the conversion from 32 to 16 does zap the image creating the blown out effect. PS HDR Toning set to Exposure and Gamma (at default setting) seems to restore the image to normal - is that the best way to resolve the issue (in real world scenario rather than theoretically).

[klev]

Re: 16 bit files

PS HDR Toning set to Exposure and Gamma (at default setting) seems to restore the image to normal - is that the best way to resolve the issue (in real world scenario rather than theoretically).

Well that is basically what it shows you on screen when you're working in 32 bit mode. It doesn't display a linear file on screen. The display response is highly non-linear. Exposure/gamma is what I would use. It's just that if you have any totally blown areas prior to that point, you can use masking while in 32 bit mode to bring them back as long as the renderer wasn't set to clamp too tightly. 32 bpc does give you some incredible latitude. Try some of the color adjustment tools at that bit depth, especially channel mixer. You'll see what I mean.

[skoobey]

Re: 16 bit files

Oh, they are very much comparable when you're trying to explaining why we do something. Just like pen and paper are comparable with phtoshop.

Anyway, it's a bout what 32bit can do for us, nothing more or less.

[shoreboy]

Re: 16 bit files

My brain hurts....but thanks for all the highly detailed discussion. Think I'll stick to 8 bit which should be fine for my purposes.