Ad
Ad
Ad
Pages: « 1 2 [3] 4 »   Bottom of Page
Print
Author Topic: Is the 16bit advantage a bit of a myth?  (Read 16684 times)
Peter_DL
Sr. Member
****
Offline Offline

Posts: 421


« Reply #40 on: February 10, 2008, 04:36:45 AM »
ReplyReply

Quote
However, I am putting together some teaching materials to show the deficiencies of editing in 8 bit mode... and I can't break the images. I took a few RAW files, processed them each into both 16 and 8 bit images and performed the same exact adjustments on each.
[a href=\"index.php?act=findpost&pid=173354\"][{POST_SNAPBACK}][/a]
It can be safely assumed that any reasonable Raw converter (whether external or in-camera) will not drop high bit precision from the A/D converter until the main processing steps and final gamma encoding are accomplished:

/>  12 or 14 bpc from the A/D converter
/>  high bit Raw processing
/>  output set to
a.)  16 bit or
b.)  8 bit

Hence, with any small output space such as sRGB it will be hard to impossible to show that options a.) vs b.) are different "as they are" – unless further editing steps are added outside the Raw converter e.g. in Photoshop:

b1.)  8 bit left at 8 bit
b2.)  8 bit left at 8 bit for adding adjustment layers*, but changed to 16 bit before flattening the layers.
b3.)  8 bit changed to 16 bit
/> followed by further image editing (* with b2)

Now with Levels and Curves, etc. it will be hard but it’s possible to show that b3, b2 have a competitive edge compared to b1.  However, very very drastic settings are needed.

But, big but, situation gets clearer once Noise Reduction plus some Re-sharpening are the first things to be done after b1 or b3. With option b3, this will fill the reservoir with 'real' 16 bit data which don’t have an integer 8 bit equivalent any more. Resulting files can tolerate further editing somewhat better before showing posterization. For example, take an image of a blue sky which fades towards overexposed white. Now, try some highlights recovery via the S/H tool. Under the provisions explained here, b3 will often enough outperform b1.

On this basis (!), the more challenging comparison might be between a.) an unbroken high bit pipe, and b3.) recovered high bit depth...

My 2ct.
Hope this is of help.
DPL

--
Logged
Jonathan Wienke
Sr. Member
****
Offline Offline

Posts: 5759



WWW
« Reply #41 on: February 10, 2008, 08:46:21 AM »
ReplyReply

Quote
No they won't if it's true that human resolution is only 7-bit (or even 8-bit)!. High bit rate is good for editing but will do nothing for viewing.

There are still a lot of 6-bit LCD panels out there, and even 8-bit displays displaying 8-bit images in a color-managed setting are still going to have posterization on-screen that doesn't exist in an 8-bit image due to the 8-bit to 8-bit color space conversion. If the display technology has visible posterization even with non-posterized images, a slightly posterized image isn't going to stand out as such because of the limits of the monitor--everything looks slightly posterized, whether the image itself is posterized or not. But once the display itself ceases to be a contributor to the problem, any issues with the file itself become much more obvious. Just like the difference between a 96Kb/s and 256Kb/s MP# might not me noticeable with $5 headphones, but with $200 headphones it's quite distinctive.
Logged

Guillermo Luijk
Sr. Member
****
Offline Offline

Posts: 1327



WWW
« Reply #42 on: February 10, 2008, 09:51:07 AM »
ReplyReply

Quote
But I guess the question is, what does it take to reduce 8-bits to 7- or 6-bits(one-quarter the levels)?  Obviously it can be done, but how likely is it in the normal way of things?
Hi Bernie, a simple S-shaped curve will make this in the shadows and in the highlights since it will compress into one single level what it was two or more differentiated levels in the original image. You just need to have a slope less or equal to 0.5 for this to happen (red lines are slope 0.5):



Red areas (slope of 0.5 or less) are affected by a compression of 2 to 1 levels or more. Yellow areas (slope between 0.5 and 1.0) are affected by a compression less than 2 to 1 levels. Only the green range (slope greater or equal to 1.0) is free of information loss but it's in it where posterization can become visible.
And I don't think this is a strange curve in real world.

This is specially important in B&W pictures which are much weaker against posterization issues since each pixel colour is defined by only one level value.


I think 8-bit images are more robust than what sometimes we think they are (or maybe human vision is worse than sometimes we think it is), but recalling digitaldog sentence with which I totally agree: "the point is, we want to send the best 8-bits to the printer. If we start with only 8-bits, that's not necessarily going to happen.", I would simply apply common sense: why assume the risk if 16-bit offers guarantees over 8-bit? as simple as that.
« Last Edit: February 10, 2008, 10:11:18 AM by GLuijk » Logged

Schewe
Sr. Member
****
Online Online

Posts: 5532


WWW
« Reply #43 on: February 10, 2008, 12:39:14 PM »
ReplyReply

Quote
So am I missing something basic here? Or is the 16 bit advantage only apparent on true edge-case images?
[a href=\"index.php?act=findpost&pid=173354\"][{POST_SNAPBACK}][/a]

Editing in 8 bit/channel is fine for many images and for many image corrections. What you've found is that for your examples, you not yet hit upon that set of adjustments on those images that will break them. Once you do, the images are ruined...

Understand that what we are talking about is the ability to maintain "EXTRA" precision for as long as possible while editing. At this point, if you are talking about merely looking at images on a display, then you aren't really stressing the images all that much. A real big stresser is final output. Have you actually gone out to prints to check for banding? That's often where editing 8 bit/channel images show their limitations...

Also, don't forget that editing in 8 vs 16 bit has additional factors...in 16 bit files, not only is your image pixel data in 16 bit, so are your channels and layer masks (note: selections in 16 bit are still only 8 bit selections–it's one of the reasons that layer masks and channels are so important). Doing gradated adjustments in 16 bit will produce finer and more subtle adjustments than 8 bit.

The bottom line is that if you work in 8 bit/channel you may never do adjustments that end up breaking the image. A lot of that depends on the quality of the original 8 bits. If you shoot in raw and convert to 8 bit from Camera Raw, you're getting an optimal 8 bit/channel output from 12-14 bit images processed in 20 bit/channel precision down sampled to the final 8 bits/channel. In the case, you are STILL getting the benefit of high bit depth in the original raw to 8 bit processing.

A better method of testing this would be to shoot in raw & JPEG, process the raw to 16 bit and take the 8 bit JPEG and do an equal series of adjustments-particularly gradated adjustments, then run the final images out to prints and look at the prints.

The problem with editing in 8 bit images is that it's really a question of when the images will break. Photoshop is not mathematically perfect. There are rounding errors and the very act of making adjustments will often throw away data. At what point will the gradations in the image then fail? I don't know...it's really hard to tell what last step will break an image. All i know is that once you break the image (introduce banding) there's really nothing that can be done to fix it.

What I HAVE found is since I started doing all my major tone and color correction in 16 bit–both global and local adjustments–I don't have the same problems with banding than I used to have when working in 8 bits. YMMV depending on YOUR images and YOUR adjustments. For my images, it's 16 bits for as long as I can.
Logged
bernie west
Full Member
***
Offline Offline

Posts: 132



« Reply #44 on: February 10, 2008, 04:08:14 PM »
ReplyReply

Quote
Only the green range (slope greater or equal to 1.0) is free of information loss but it's in it where posterization can become visible.
And I don't think this is a strange curve in real world.
[a href=\"index.php?act=findpost&pid=173719\"][{POST_SNAPBACK}][/a]
Hi Guillermo.  The green range isn't really free of information loss, as you have effectively strectched n levels to cover 2n levels.  In effect you have halved the information in the green section (by doubling the size of the green section), equivalent to dropping an 8-bit image to a 7-bit image.  As for the curve, I dunno, it looks pretty strong to me.  Later I will try it with some images and see how they look.

ps. By the way, what's the best way to send you that 5D uni white balance raw?
« Last Edit: February 10, 2008, 04:09:28 PM by bernie west » Logged
Guillermo Luijk
Sr. Member
****
Offline Offline

Posts: 1327



WWW
« Reply #45 on: February 10, 2008, 04:44:39 PM »
ReplyReply

Quote
Hi Guillermo.  The green range isn't really free of information loss, as you have effectively strectched n levels to cover 2n levels.  In effect you have halved the information in the green section (by doubling the size of the green section), equivalent to dropping an 8-bit image to a 7-bit image.  As for the curve, I dunno, it looks pretty strong to me.  Later I will try it with some images and see how they look.

ps. By the way, what's the best way to send you that 5D uni white balance raw?
[{POST_SNAPBACK}][/a]

Well I think it's all about semantics: in the green range I meant "no information loss" since the previous information doesn't get aggregated because of the curve and remains differentiated, so there is no loss of THAT initial information.
Yes, if we compare the situation of that levels range with what we would find in when applying the same curve in 16-bit, we have half the information. That's why I pointed this would be the area in danger of posterization.

Please send the 5D UniWB through [a href=\"http://yousendit.com]http://yousendit.com[/url] to gluijk(at)hotmail.com
What accuracy did you achieve?

Regards.
« Last Edit: February 10, 2008, 04:46:22 PM by GLuijk » Logged

bernie west
Full Member
***
Offline Offline

Posts: 132



« Reply #46 on: February 10, 2008, 07:01:16 PM »
ReplyReply

Quote
Well I think it's all about semantics: in the green range I meant "no information loss" since the previous information doesn't get aggregated because of the curve and remains differentiated, so there is no loss of THAT initial information.

Aggregation won't be the problem (in the context of this discussion), but histogram expansion is.  If you threw out half the levels in an image and then expanded the histogram to fill from 0-255, the resulting histogram will look like the histogram in your green section.  It will effectively now be a 7 bit image.  Aggregrating data won't change the bit level of the image as all levels in the aggregated level will remain occupied (if indeed they were in the first place).

Quote
Please send the 5D UniWB through http://yousendit.com to gluijk(at)hotmail.com
What accuracy did you achieve?
[a href=\"index.php?act=findpost&pid=173824\"][{POST_SNAPBACK}][/a]

I can't remember the accuracy but it was whatever I posted in the other forum about it.  From memory I think they were about 1.01
Logged
Ray
Sr. Member
****
Offline Offline

Posts: 8939


« Reply #47 on: February 10, 2008, 07:32:03 PM »
ReplyReply

Quote
A better method of testing this would be to shoot in raw & JPEG, process the raw to 16 bit and take the 8 bit JPEG and do an equal series of adjustments-particularly gradated adjustments, then run the final images out to prints and look at the prints.
[a href=\"index.php?act=findpost&pid=173766\"][{POST_SNAPBACK}][/a]

Jeff,
Aren't you adding another factor involving some degradation here? Jpeg is not a lossless compression and the image will have already been processed to some extent in-camera.

A fairer comparison would be, after processing the RAW in Lightroom or ACR, to convert the image twice, once in 16 bit and again in 8 bit. Do whatever further tweaking is necessary in Photoshop, applying the same changes equally to both images, then print both images the same size on the same paper. Get the borders the same width and generally avoid all tell-tale signs that might distinguish one print from the other. Mix the prints up, then see if you can tell which is from the 16 bit file without resorting to the use of a loupe.

I think most people are too busy to take the trouble. It's much easier, if there's any doubt, to just always use 16 bit. If the resources are available and memory is cheap, why not?

Nevertheless, it's an interesting issue as to just how much extreme processing is required before the 8 bit image 'breaks' as you describe it. There are certain processes in CS3E that require a lot of computing power for 16 bit images. My laptop has 2Gb of RAM and a 60GB hard drive partition which is available for the PS scratch disc (but not exclusively. It's probably about half full most of the time.)

I was surprised to find that my laptop doesn't have the resources to stack a number of 16 bit images. I've tried several times, even clearing most of the stuff from the 60Gb partition and defragmenting the drive first, but stacking 9 or so 16 bit images is just impossible. The images have to be in 8 bit.
Logged
Guillermo Luijk
Sr. Member
****
Offline Offline

Posts: 1327



WWW
« Reply #48 on: February 10, 2008, 08:08:27 PM »
ReplyReply

Quote
Aggregation won't be the problem (in the context of this discussion), but histogram expansion is.  If you threw out half the levels in an image and then expanded the histogram to fill from 0-255, the resulting histogram will look like the histogram in your green section.  It will effectively now be a 7 bit image.  Aggregrating data won't change the bit level of the image as all levels in the aggregated level will remain occupied (if indeed they were in the first place).
Well aggregation won't be the problem as long as that curve is your last edition process. But if more are coming that could expand again the low/high end of the histogram (for instance a desaturation or a partial de-contrast curve applied just in some area of the image), then you will suffer the effects of the aggregation you provoqued with your previous curve.

In the same way, those holes that were produced in the middle range could again be occupied thanks to the following edition stage, that's why I claimed there is no loss of information in that range, simply a reallocation of data.

But I understand your point.


OK thank you, I would appreciate a lot if you send me the RAW for the 5D so that I can offer it in the original article for download, of course giving credit to you.
« Last Edit: February 11, 2008, 03:15:27 AM by GLuijk » Logged

kramer11x
Newbie
*
Offline Offline

Posts: 7


« Reply #49 on: February 11, 2008, 09:08:40 AM »
ReplyReply

So, is the oft quoted recommendation still correct?

Shoot in hi bit RAW.

Use RAW converter in 16 bit for all tonality/color corrections.

Switch to 8 bit if/when required for specific filters or compositing needs and output to external devices.

This seems to be a consensus of many photoshop books.

I currently shoot with camera set to 14 bit RAW.  Download to Capture NX for all tonality and color adjustments.  Save as 16bit tiff for photoshop elements.  Do everything I want to and can in 16 bit.  Then switch to 8 bit for any layers/compositing and printing.  This seems to be working very well for me.  However I still wonder if spending considerably more for the full photoshop and lightroom combo where I could do more in 16 bit is worth the several hundred dollars.  If money weren't an issue wouldn't everyone use 16 bit for everything?

Jack
Logged
Panopeeper
Sr. Member
****
Offline Offline

Posts: 1805


« Reply #50 on: February 11, 2008, 09:28:29 AM »
ReplyReply

Gullermo,

I made a WB template for my Canon 20D too. If you don't have any yet, I send it to you.
Logged

Gabor
mistybreeze
Full Member
***
Offline Offline

Posts: 177


« Reply #51 on: February 11, 2008, 09:51:21 AM »
ReplyReply

Quote
If money weren't an issue wouldn't everyone use 16 bit for everything?
Here's the million dollar question no one asked until now and the answer is yes.

16-bit processing from CR to output is very expensive, which is why the subject has elitist cache. If your typical workflow includes files with many layers and tonal adjustments you better be prepared for 16-bit's demands. It's no fun to work in 16-bit if your equipment can't handle the grind. Ask any fashion retoucher who works on clothing all day or any retoucher who tackles a L'Oreal ad. Their 16-bit files often jump to 2 gigs faster than you can apply mascara to your model. You need a powerhouse CPU, you need a separate (fast) drive for scratch, you need a ton of memory, and you need to make serious hard drive choices as you consider immediate access needs as well as archival. If your brain can't handle making these decisions and you're not up to performing your own configurations, you'll need to hire a tech-geek and pay the hourly to make sure everything works and stays working.

Nobody drives a Chevy Aveo because they want to.
Logged
Panopeeper
Sr. Member
****
Offline Offline

Posts: 1805


« Reply #52 on: February 11, 2008, 10:26:33 AM »
ReplyReply

Quote
Ask any fashion retoucher who works on clothing all day or any retoucher who tackles a L'Oreal ad. Their 16-bit files often jump to 2 gigs faster than you can apply mascara to your model

I really wonder how this happens with CS3. My files often get in the many hundred MB range, but those are panoramas in 16bit.

The greatest advantage of CS3 (compared to CS1) for me is the ability to make adjustments without replicating the layers, through adjustment layers.
Logged

Gabor
Gordon Buck
Sr. Member
****
Offline Offline

Posts: 409



WWW
« Reply #53 on: February 11, 2008, 10:51:18 AM »
ReplyReply

Anyone doing 8 bit HDR?
Logged

mistybreeze
Full Member
***
Offline Offline

Posts: 177


« Reply #54 on: February 11, 2008, 11:08:32 AM »
ReplyReply

Quote
I really wonder how this happens with CS3. My files often get in the many hundred MB range, but those are panoramas in 16bit.
I wonder if Annie Leibovitz's three-page cover spreads, composited for Vanity Fair, could be considered panoramas? How about two-page spreads in Vogue from Gucci, Vuitton, and Burberry? The latest two-page Burberry ad features 13 models. When budgets are these costly and where every detail matters, one doesn't skimp on Photoshop layers.

OK, I admit, 2 gigs may have been a slight exaggeration (in some cases). All this talk about big-is-better stirs the juice. The truth is, retouching expensive fabric, a designer fabric with grain, texture, pattern and color nuance, and retouching in the context of the fabric on a model who is moving, requires a precision not required in other types of photography.

A multi-million-dollar cosmetic ad requires a different kind of detail. Layers are typically broken down into numerous areas of the image, such as:
1. Clothing
2. Neck skin
3. Jaw line
4. Ears
5. Cheeks
6. Forehead
7. Nose
8. Left eye
9. Left brow
10. Right eye
11. Right brow
12. Slow eye
13. Hair left
14. Hair right
15. Hair on clothing
16. Teeth
17. Lips

None of these seventeen layers includes any color adjustment layers which often need to be specific to numerous areas of the image. Combining any layers to reduce file size is not preferred. You may not hit 2 gigs on a face shot but, with 20+ layers in 16-bit, you better be prepared.
Logged
Jonathan Wienke
Sr. Member
****
Offline Offline

Posts: 5759



WWW
« Reply #55 on: February 11, 2008, 11:09:39 AM »
ReplyReply

Quote
Anyone doing 8 bit HDR?

Wouldn't that be sort of like putting a Yugo engine in a Ferrari???
Logged

Panopeeper
Sr. Member
****
Offline Offline

Posts: 1805


« Reply #56 on: February 11, 2008, 11:24:00 AM »
ReplyReply

Quote
I wonder if Annie Leibovitz's three-page cover spreads, composited for Vanity Fair, could be considered panoramas?
Hardly. The pixel count is relevant, not the print size. 40 Mpix is small among panos, but printed on 12x36 you can view the details with magnifier. A few hundred megapixel pano in 16bit does go in the gigabyte range.

When I am processing large panos in several layers, I delete the unused areas. For example the sky, water surface and the rest are often separated. I leave a margin for the tuning of separation and delete the rest, in order to make processing and especially writing faster.

Anyway, I do understand your point and don't want to belittle that task, only your 2gig statement baffled me.
Logged

Gabor
mistybreeze
Full Member
***
Offline Offline

Posts: 177


« Reply #57 on: February 11, 2008, 01:12:32 PM »
ReplyReply

Quote
Hardly. The pixel count is relevant, not the print size.
I wonder if pixel count is relative to a wall-size print at MOMA, or The Corcoran Gallery? Anyone who thinks Annie Leibovitz or Inez and Vinoodh are retouching in 16-bit simply for magazine-page publishing are living in a pretty small world. I mean no offense but I wish more Photoshop users could think outside their own little box.
Logged
JeffKohn
Sr. Member
****
Offline Offline

Posts: 1671



WWW
« Reply #58 on: February 11, 2008, 01:42:25 PM »
ReplyReply

Quote
I wonder if pixel count is relative to a wall-size print at MOMA, or The Corcoran Gallery? Anyone who thinks Annie Leibovitz or Inez and Vinoodh are retouching in 16-bit simply for magazine-page publishing are living in a pretty small world. I mean no offense but I wish more Photoshop users could think outside their own little box.
[a href=\"index.php?act=findpost&pid=173992\"][{POST_SNAPBACK}][/a]
I think Panopeeper's point was that the intended use of the image is not the deciding factor in file size (unless you're interpolating before you retouch, which doesn't seem very smart to me). The capture resolution determines the initial file size, with it going up from there based on layer usage.
« Last Edit: February 11, 2008, 01:53:07 PM by JeffKohn » Logged

JeffKohn
Sr. Member
****
Offline Offline

Posts: 1671



WWW
« Reply #59 on: February 11, 2008, 01:43:57 PM »
ReplyReply

Quote
When I am processing large panos in several layers, I delete the unused areas. For example the sky, water surface and the rest are often separated. I leave a margin for the tuning of separation and delete the rest, in order to make processing and especially writing faster.
[a href=\"index.php?act=findpost&pid=173971\"][{POST_SNAPBACK}][/a]
Thanks for that tip, it never even occurred to me that deleting image data instead of masking it would make a difference in file size (and more importantly write time), but that makes perfect sense.
Logged

Pages: « 1 2 [3] 4 »   Top of Page
Print
Jump to:  

Ad
Ad
Ad