Posterization in skies

[lfbrown]

I use an APS-C camera and have noticed that when darkening skies in Photoshop during post processing there comes a point - and

rather quickly - when the smooth tonal range begins to posterize producing an unpleasant mottling. I've come up with various

workarounds but I was wondering if this is as much of a problem when using a camera with a full frame sensor. In other words, can an

image from a full frame sensor be pushed further before damaging artifacts begin showing up I the image.

 

Thanks

[digitaldog]

<p>Is the capture provided in high bit (what PS calls "16-bit")?<br>

Banding can occur in the data itself or from the display path. If we know about the bit depth of the data, might be able to decide which is which. </p>

[frans_waterlander]

<p>Expose to the right is one of the best tools to prevent posterization.</p>

[digitaldog]

<blockquote>

<p>Expose to the right is one of the best tools to prevent posterization.</p>

</blockquote>

<p>To be exact; optimal exposure for <strong>raw</strong> is the best method to prevent noise in the shadows:<br /> <strong>schewe</strong>photo.com/ETTR/<br /> http://digitaldog.net/files/ExposeForRaw.pdf<br>

<br /> "<em>ETTR</em>" (a term that should really disappear, it's more about <strong>optimal exposure</strong> for the raw capture) is all about the signal to noise ratio. Key word: noise.<br>

<br /> Adding noise to posterization is actually a technique to reduce said banding:<br>

<br /> http://planetphotoshop.com/say-goodbye-to-gradient-banding.html<br /> http://forum.luminous-landscape.com/index.php?topic=59613.msg481119#msg481119:</p>

<blockquote>

<p><em>ETTR means better SNR, i.e. less visible noise. If a plain area of a scene (e.g. your sky) is sufficiently clean of noise because of ETTR, once converted to an 8-bit output (e.g. JPEG) the bands will be visible like in this case. The RAW file had a lot of levels thanks to ETTR, but far from preventing posterization, the low noise achieved through ETTR produced banding on the 8-bit output.</em><br /><br /><em>Contrarily to what many times is said, posterization usually comes from insuficient levels on well exposed areas in 8-bit, never from insufficient levels in the RAW file since noise always dithers captured information, no matter the exposure achieved.</em><br /><br /><em>A possible solution is to <strong>add noise</strong> in the sky to make the bands invisible.</em></p>

</blockquote>

[lfbrown]

My camera captures in 14 bit and I send the raw image from ACR to Photoshop as a 16bit image. I want to emphasize

that the sky areas not subjected to heavy tonal manipulation have no hint of the problem. It's only after shifting the tonal

value down 2 or 3 stops that the pixel structure begins to lose its monotone appearance. I like those dark skies but they

aren't always achievable at the moment of exposure.

[digitaldog]

<p>Based on what you've said Les, it <em><strong>could</strong></em> be banding seen on-screen, not in the data itself. <br>

With high bit data, you'd have to really crunch the levels <strong>hugely</strong> to end up with banding. <br>

Perhaps you could post a raw for others to examine. On this Mac, with my high bit display, card and recent version of Photoshop, I'm running a full 10-bit video path so I shouldn't see any banding unless it's in the data. <br>

You should of course do any or all of the sky darkening in a raw processor, not afterwards in Photoshop IF possible. </p>

[lfbrown]

Re Andrew's post: the problem would probably appear in any given gradiation dropped a couple of stops. However, I most

consistently seem to be changing the value in the sky tones and never (almost) move other tones in the image that far.

So I'm always dealing with a sky, properly exposed for its actual light value, but then cranking it down in value for esthetic

purposes. The effect, as noted I the OP, is not so much banding (which I am familiar with when a large graduated tonal

scale is scaled down too severely) but literally a mottled appearance. However, this could be attributed to the fact that

skies are almost never perfectly graduated tonal scales.

[ellis_vener_photography]

Which color space are you exporting the 16-bit TIFFs in?

[digitaldog]

<p>Again, it be useful to visually see what you're referring to and having access to the raw. <br>

I agree, this has nothing to do with exposure. </p>

[lfbrown]

I' m using RGB. Would that effect how a graduated scale is rendered? I think I've solved the problem, however. Part of it

is screen render in ACR. I'm using CS5 and it appears - never noticed it before - that at 25% - 50% image render the on screen

image is terrible. Once I move up to 66% the tonal scales improve immensely. So it seems partly a perceptual problem.

 

Often, however, I go straight to PS as in my CS5 ACR there is no way to do selections and trying to isolate out skies with

complicated horizons or foreground objects intruding into sky space is - for me - difficult to impossible. Once in PS I

work the tools there and also go to two Topaz plugins: Clarity and Details. Sometimes one or the other and sometimes

both. And it is easy to go past reasonable limits with those hence my original question as to whether or not using a full

frame camera would would allow more tolerance of brute force editing.

 

While I don't think it is worth anyone's time for me to upload a raw example, perhaps someone could enlighten me as to

how to do that in the future. Do I just load it up in the window offering uploads following this message box and know that it

will load outside of the message or is raw just altogether too big and I need to achieve it in some other way?

 

I'll try doing more in ACR this coming week and if I'm still having problems I'll post again with examples.

 

Thanks for all the input and fast response. And if anyone has an opinion on whether or not a larger sensor would give more editing latitude I'd appreciate a note.

[digitaldog]

<blockquote>

<p>I' m using RGB.</p>

</blockquote>

<p>Which? ProPhoto RGB, sRGB, etc?</p>

<blockquote>

<p>Would that effect how a graduated scale is rendered?</p>

</blockquote>

<p>In high bit, it really wouldn’t. With wider gamut color spaces, you want to edit high bit (the distance between the device values are wider apart). We can go there if you want.</p>

<blockquote>

<p>Part of it is screen render in ACR. I'm using CS5 and it appears - never noticed it before - that at 25% - 50% image render the on screen image is terrible. Once I move up to 66% the tonal scales improve immensely.</p>

</blockquote>

<p>Exactly! You always want to view at 100%/1:1 for accurate previews of screen data. Lower ratio's subsample the pixels to '<em>zoom out</em>' and you see this kind of banding or artifacts. IF you don't see this at 100%, you're fine. Got nothing to do with exposure, you're working high bit so plenty of device value data precision for the edits.<br>

<br /> So as I pointed out in my first post, the issue <em><strong>can</strong></em> be the display, not the actual data and if you don't see this at 100%, no reason to upload anything, you're set and all is fine. Just view the data at 100% when you need the most precise preview of the data. When you zoom out, if you see this subsampling, just ignore it. True in Photoshop, ACR, Lightroom and probably any software that provides differing zoom levels of pixel data.</p>

[alan_cox3]

<p>This should also be a warning about what you are attempting. When you see problems on the screen you may be getting close to other problems in the real image.</p>

<p>Since posterization is the opposite problem of noise, having less variation than what is there. Noise has too much (artificial) variation due to imperfect reproduction. So ETTR or optimal exposure, while reducing the noise in shadows is also risking the opposite problem in the lightest continuous areas of a scene. When it comes to skies, a little noise is your friend as Andrew has pointed out. Before collapsing a high quality image down into a low quality one (like say Jpeg), consider adding noise, or at least not removing it in the first place.</p>

[digitaldog]

<blockquote>

<p>Since posterization is the opposite problem of noise, having less variation than what is there</p>

</blockquote>

<p>It is? </p>

<blockquote>

<p>So ETTR or optimal exposure, while reducing the noise in shadows is also risking the opposite problem in the lightest continuous areas of a scene.<br /></p>

</blockquote>

<p>True, <em>if</em> you clip highlight data you don't want to clip (don't do that, it's not optimized exposure). </p>

[alan_cox3]

<p>The problem in the skies isn't just clipping. By being almost perfectly smooth, it's a waiting trap when collapsing it's values down to just a few. ETTR and low ISOs, while helping shadows, also takes a slight bit of noise out of the skies. It's all OK in the original capture, but in collapsed jpegs (and screen displays) -- not so much.</p>

[digitaldog]

<blockquote>

<p>The problem in the skies isn't just clipping. By being almost perfectly smooth, it's a waiting trap when collapsing it's values down to just a few.</p>

</blockquote>

<p>Not sure what you mean and would love to see such an example. <br /> Here's one: It's just a part of a full resolution ProPhoto RGB, 16-bit capture from Lightroom. There isn't a lick of banding, posterization (viewed at 100%). ISO 100, 5DMII. <br /> Viewed in a high bit display path. Perfectly smooth.<br /> <img src="http://digitaldog.net/files/sky.jpg" alt="" /><br>

High bit data should have more than enough device values to even allow pretty severe editing without introducing banding. And I'd submit, far better, faster and better data, conducting those edits on the raw data! </p>

[digitaldog]

<p>More proof of concept. First the severe edit in Photoshop using Levels. Notice where the sliders are in terms of what I consider a <strong>super</strong> severe edit:<br>

<img src="http://digitaldog.net/files/Levels.jpg" alt="" /><br>

Now the image after edit (this is a TIFF since JPEG compression plays a role seeing all this):<br>

<img src="http://digitaldog.net/files/SkyEdit.tiff" alt="" /><br>

The edit does show a sensor dust spot! It doesn't show any banding. </p>

[alan_cox3]

<p>The potential trap is in the handling of the round-off errors during the down-sampling process. As long as all the errors are distributed to neighboring pixels during the process it's OK. But if it's not done well, or the emphasis is on speed over quality, then the errors are discarded as in display algorithms and hardware conversions. That's when the banding shows up. It depends on the implementation, and most are much better than they used to be. Obviously your images have all been faithfully down-sampled.</p>

<p>Note that I was just alerting to a potential issue, and attempting to explain why adding noise sometimes helps a banding problem. </p>

 

[digitaldog]

<blockquote>

<p>The potential trap is in the handling of the round-off errors during the down-sampling process.</p>

</blockquote>

<p>Not seeing that either. The image above can/was sized to an odd value from Lightroom and Photoshop, no banding. Smooth as a baby's behind:<br /> <img src="http://digitaldog.net/files/skyResample.tif" alt="" /><br /> IF anything, downsampling using something like Bicubic should reduce banding and noise. <br /> IF you've got examples, I'm all ears and eyes. <G>.<br /> I can't replicate using what I believe is a sound workflow; high bit data, even in a very, very large gamut working space.<br>

JPEG is moot; it's not high bit. It should be the final iteration for it's intended use; the web or mobile devices. Those devices can have a rather low bit per pixel output depending on the quality of the device and you can see banding that's not in the data but <strong>in the display path</strong>. <br>

I can provide the smoothest data on the planet and on a 6-bit display, it will appear to band while on my PA272W which is high bit, appear as smooth as the data really is. </p>

[digitaldog]

<p>BTW, it's easy to introduce banding into a sky:<br /> Save out of Lightroom as a JPEG in ProPhoto RGB, 24-bit. <br /> Examine the Levels (you can see the data loss within the Histogram).<br /> Apply a correction in Levels as seen. Banding! This is a TIFF screen capture:<br /> <img src="http://digitaldog.net/files/SkyBand.tiff" alt="" /><br /> Lesson: don't do the above steps in your workflow unless you want banding in the sky!</p>

[alan_cox3]

<p>I think at this point we are saying the same thing. No problem in original data or high quality output. Potential problem with down-sampling to low bit per pixel output. Obviously if you are not having such a problem, then good. Best regards.</p>

[digitaldog]

<blockquote>

<p>Potential problem with down-sampling to low bit per pixel output</p>

</blockquote>

<p>In a very wide gamut space, a JPEG with insufficient quality on creation, with edits applied afterwards, yes.</p>