A Great example of 48-Bit Editing vs. 24-Bit Editing

org

Introduction

 

48-bit editing (16-bits per-channel) is important, and many editors these days support it. Sagelight, for example, is called ‘Sagelight 48-bit Image Editor’ because it really is that important.

In creating the Bokeh, Lens Blur, and Fast Depth of Field functions for version 4.2 (just released.  You can find it here), I came across a great example of the difference between editing an image in 16-bits per-channel, as well as saving an image at the same depth level. 

An important note

Before I go too far, I do want to point out that it is only important at certain points.  If you’ve read much of the Sagelight Blog, you’ll know that I also talk quite a bit about how saving in Jpeg and then performing edits can certainly be fine as well.

 

Editing in 16-Bits per-channel vs. Saving at 8-bits per-channel

 

It’s important to note that when you load an image into Sagelight, even if it is 8-bits per-channel, it is immediately converted to 16-bits per-channel and, by far, most operations are actually performed at 32-bits (floating-point) per-channel, and sometimes at 64-bits per-channel.

This is important because it allows you save out at 8-bits per-channel (i.e. Jpeg, though I would recommend the highest quality settings (9 or 10)) with the option to edit the image again without too much degradation of the image as a whole.

Even though it is better to save out at 16-bits per-channel (and without lossy compression), this can be a little less easy than just saving out a jpeg.

 

Saving at 16-bits per-channel

 

As mentioned, this is technically the best option, but, for the record, I only do this with images I intend to keep working on creatively later on. 

If an image is fairly close to what I’m looking for, then I will probably save it as a Jpeg for convenience.  Minor edits after that, such as adding color, some sharpness (*see the examples below, however), a little light, contrast, shadows, etc. – aren’t going to hurt your picture.

It’s really only in the initial and medium-level stages of an image where 16-bits per-channel can be important, and only under certain circumstances.

The trouble is, of course, that you don’t know when those circumstances are going to come up, so it’s better to work in 16-bits from the start.

It’s also important to note that the need to work in 16-bits per-channel often comes from the editing process itself, so starting with 8-bits per-channel isn’t necessarily a bad thing, as long as the main part of the editing process is in 16-bits per-channel.

 

The Main Example

 

It’s Not the Current Edit, but the Next One Where You See the Difference

 

It’s always been a little hard to find a good example for why 16-bits is important. Banding in the sky is a good example, but that can come with 16-bit editing, too, under certain circumstances.

Plus, one of the main issues with editing in 16-bits per-channel is that yiou don’t see the quality difference until the next edit, or the one after that.  As you add color, sharpness, contrast, and use one of any number functions, this separates the color pixels from each other.  With only 256 colors (at 8-bits) per-channel, this can quickly cause the pixels of each channel to ‘clump’ together.

This pixel clumping also happens at 16-bits per-channel, but at 256 times the resolution of 8-bits per-channel, you rarely encounter problems with it.  However, this is why Sagelight works mostly at 32-bits internally to keep the quality at basically 16 million times the quality of 8-bits per-channel. 

Again, editing in 8-bits per-channel is “ok”, and in minor editing situations, you don’t have to worry about it much.  But, let’s look at the examples:

Blurring an Image

 

newOriginal Image Blurred with Sagelight Bokeh/Lens Blur

 

Let’s say we want to take the above example and add a blur to it by using the Bokeh/Lens Blur function in Sagelight.   In the above image, you can see that I added some blur and some highlights to the original image.

 

The Quality of Sagelight Bokeh (yep, a plug)

Sagelight Bokeh, Lens Blur, and Fast DOF works at a very high quality and in the testing phase multiple sharpens were performed to test the integrity of the blur.  To see how Sagelight was doing against the other Bokeh products out there, I ended up looking at other retail packages.  I came across one with an 8-bit per-channel output and realized I had a great example of 8-bit vs. 16-bit editing.

 

A Closeup

 

closeup

Closeup of the Bokeh Result Image

 

The above is a 100% closeup of the Bokeh Blur.   If I convert this image to 8-bits, here is what is hiding just beneath the surface:

 

noise2

8-Bit per-Channel Image (sharpened)

 

The above is the image sharpened at 8-bits per-channel.  Let’s look at it closer:

org-closeupBlurred Image, Untouched

 

The above image is the blurred image that has not been touched since the Bokeh Blur was applied.  In 8-bits or 16-bits per-channel, it looks fine.  But, as I mentioned, it’s the next edit where you start to see it.

Let’s say I decided to sharpen the entire image to bring out the center.  Here is what the image looks like if it is in 8-bits per-channel

 

noise1-closeup8-Bit Image, Sharpened

 

As you can see, just below the surface of the nice, clean looking image can be quite a mess. This was a medium-level sharpen.

Let’s look at what happens if I apply the same amount of sharpening in 16-bits per-channel

 

sharp16_1-closeup16-bit per-channel image, sharpened.

 

As you can see, there are no lines and no defects!  (anything you may see is from the 8-big jpeg compression for the blog).

Let’s sharpen the 8-bit image again:

 

noise2-closeup8-Bit per-Channel Image, Sharpened (pass 2)

 

Ouch!  You can see how certain things can really bring out the limitations of editing in 8-bits per-channel.

 

Let’s look at the 16-bit per-channel image, sharpened in the same way:

sharp16_2-closeup16-bit per-channel Image, Sharpened twice.

Now, that’s a textbook picture!  As you can see, there are still no lines or edges even after being sharpened twice.  Now, to brag a little about about Sagelight here – this was done with a shaped, lens blur.  Not all Bokeh packages are this clean.

The little lines and things you see is a result of the unsharp mask bringing out the natural texture in the image.  That is, it’s actually sharpening it without bringing any edges or artifacts.  You can even see the shape of the kernel I used (octagon) even though I had it set for a very soft focus.

By contrast, the 8-bit image sharpened twice still looks like the same blur image with a lot of noise piled on top of it.

 

Conclusion

 

As you can see from the above examples, it really doesn’t take too much to hit the limitations of 8-bit per-channel editing, and the Bokeh, Lens Blur functions in Sagelight ended up providing a great opportunity to show it in action.

On the other hand, I do want to repeat that minor edits and simple editing in 8-bits is just fine, as long as you save at high (or maximum) settings with Jpeg.  I do this all the time.

We’re really only talking about saving images and re-loading them (or initially loading them) in 8-bits per-channel, since Sagelight stores and works with your image in at least 16-bits per-channel at all times.  The 8-bit per-channel process happens when you save as a JPEG or BMP, or initially load your image as a Jpeg.

I only really turn to 16-bits per-channel as a practice when:

  • a) I know I am going to creatively edit the image more, or I am not sure if I am done with it.
  • b) I have fine gradients, such as a sky, or smooth areas such as the above blur.

I use Jpeg or 8-bit per-channel images (that is, saved on disk; it’s always 16-bits per-channel in Sagelight) when:

  • a) Most of the time, because not only are all the edits in Sagelight at 16-bits per-channel, so I really am editing in 16-bits, but also because I do the major core work on the image in one session.
  • b) When I want to edit something just for looks, or to tweak it.  But, this sometimes incurs a penalty.  I do have to understand that sometimes I will cause banding.  But, I can handle that, typically with the Median or Image Smooth function and the Undo brush.
  • c) Cloning, Dodging and Burning, effects – typically not necessary to use 16-bits per-channel, even though 16-bits per-channel, as a practice, can be better.

 

So why did I write this article if I’m really saying it doesn’t matter that much?

 

Because when it does matter, it matters.  However, one of the things I don’t want to do as the author of Sagelight is to tell you what to do, or to make editing more difficult.  Sagelight is a very pure editor, and contains many purist tools.  I want you to be able to edit at the highest degree possible.

However, I am not a purist about my personal image editing and most people aren’t.  I want to keep editing simple and fun, for people who use Sagelight, which includes myself.

About 85% of the time, most editing – again, since it’s all in 16-, 32, or 64- bits per-channel in Sagelight, as opposed to an editor that only operates in 8- or 16-bit space – isn’t really going to involve issues such as seen above.  But, sometimes they do.

So, I guess my main message is really informational. As you progress in image editing and you see lines, edges, and things of that nature.  Thinking about where either using RAW or saving a file you’ve re-edited in 16-bits per-channel may be a good thing. 

Advertisements

6 thoughts on “A Great example of 48-Bit Editing vs. 24-Bit Editing

  1. I don’t really see what’s so difficult about working with 16 bit file formats. They’re larger and *slightly* less well supported in imaging editing software. Granted they’re not appropriate for the web, but web output should always be a final step and usually includes some resizing and other things that you would not want to permanently save to your image source anyway.

    – Oshyan

    • Hi, Oshyan.

      It’s not really a matter of difficulty. I wasn’t saying it was hard at all, but it does need to get into the workflow, and I don’t want to force it on people. From a technical perspective, I would say that keeping your image in at least 16-bit per-channel is the best thing to do. But, as the author of Sagelight, I want to be careful in terms of getting too overbearing about what people should do, in the sense that image editing tends to be a growth process for many people. In that sense, I don’t think it is for me to lay down a bunch of rules about what one should or shouldn’t do, because I definitely take the side of keeping image editing a casual affair. From my perspective, I want to provide the tools, but then not get annoying about say “you should do this”.

      My thought on it is that as people get more and more involved with image-editing, keeping a 16-bit per-channel image is just a part of that natural process and, for my part, I just wanted to point out a really good example of where you can really see a difference. Actually, I would have liked to have been more technical with it, because it is really because of the fact that the blur on each pixel was different that a) allowed the 8-bit limitations to show so easily and b) showed how well the new Bokeh functions are working (since they’re applied at 32-bits and 64-bits per-channel).

      I really just wanted to point it out without making an authoritative statement, but rather one from experience that people can just take in and put where they want. As I said, I am pretty casual about my editing, and for many things, you know, I just want to edit the jpeg a little — add color, contrast, dodge and burn… whatever — and move on without making it ‘a process’ — actually, I think I just hit what I wanted to say on the head; I don’t want to put ‘processes’ on people who don’t want them, but make the information available for those that want to go a little further.

      • I hear you, but I wasn’t suggesting you tell people what to do, i.e. “Always use 16 bit or else!”. I just think you’re a bit *too* wishy-washy with the distinction here and make the option of going with 16 bit seem nebulously problematic, without pointing out any real difficulties with it. A better approach, I think, would be to say something like “While it’s ok to use JPG for saving of final files, or even intermediates if you use really high quality settings, ultimately you want to be using 16 bit save formats for everything except your final output when you get serious about image quality. Sagelight makes that easy, and here are some other tools for your workflow that do as well.” Then go on to mention image viewers, other editors, and additional systems that support 16 bit. Enable users by providing tools, just as you said. You actually spend a surprising amount of time/text in this article reiterating that “16 bit is better, but JPG is fine really, even though 16 bit is better, but JPG still ok-ish, kind of, but really you should use 16 bit…” It’s an unclear, mixed message and I think it’s OK to take a bit firmer stance on it as long as you’re clear and provide tools to make it work.

        I was not, of course, criticizing your example (which is great) or the fundamental reason for the article, only that its message is somewhat diluted by your concern for not being too heavy handed. I agree with the underlying sentiment – don’t force process on the user – but still think it’s good to be *clear* about what is best, provide tools to make best practices easy, and *don’t* worry too much about accommodating less ideal work flows by saying they’re ok repeatedly. I think almost anyone reading an article of this length about image editing is probably going to want to use best practices. Even just pointing out what *are* 16 bit file formats would have been a good step in providing tools for people to act on the information here.

        – Oshyan

    • I didn’t feel like he was attacking me at all. If anything, I was being a bit argumentative with him. 😉 But hopefully my point is understood. I think Rob does a great job with the software, blog posts, etc.

      – Oshyan

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s