16 bits per channel

[bkh]

The smaller layer was cropped from a screenshot of the picture without the histogram correction.

Thanks – if I turn off global antialiasing (in the General Toolbar), I get output like yours – if I turn it on, the screen output is dithered. Maybe you have disabled global antialiasing?

Cheers

Burkhard.

[Hoogo]

Maybe you have disabled global antialiasing?

No, it's enabled, and it works fine for vector lines.

[Martin Huber]

For a test I ceated a picture of 16Bit, 1024 pixels, and placed a vector with gradient above it.

There is no dithering in 16 or 32 bit, because there is no device, that is able to display the fine differences between two steps. Of course you can make them visible with a very extreme histogram correction, but is this really something, that is happening in real world's work?

Martin

[Hoogo]

For a test I created a picture of 16Bit, 1024 pixels, and placed a vector with gradient above it.

There is no dithering in 16 or 32 bit, because there is no device, that is able to display the fine differences between two steps. Of course you can make them visible with a very extreme histogram correction, but is this really something, that is happening in real world's work?

I rarely see banding on my monitor, but people who work in AdobeRGB and use better devices have this effect quite often. Discussion about that topic appear regularly, and usually the problem is solved by adding noise.
Once 16Bit pictures were dithered for the display in PL.

[Martin Huber]

Once 16Bit pictures were dithered for the display in PL.

16 bit pictures are still dithered on-screen (and when converted to 8 bit).

But in order to see this dithering, it is not sufficient to apply an histogram adjustment to the 16 bit document. You will have to make a screenshot and apply the histogram to that.

And if you are creating a gradient in 8 bit, it will be dithered, too.

Martin

[bkh]

Once 16Bit pictures were dithered for the display in PL.

16 bit pictures are still dithered on-screen (and when converted to 8 bit).

But in order to see this dithering, it is not sufficient to apply an histogram adjustment to the 16 bit document. You will have to make a screenshot and apply the histogram to that.

I think that this is what Hoogo did – turned off the histogram correction in his sample file, made a screenshot, pasted it back and re-applied the histogram correction. In any case, that's what I did. With global antialiasing turned on, I get a file showing antialiasing. If I do the same with global antialiasing turned off, the file has distinct vertical bands. Here's the relevant part of the results made more visible using the same histogram correction as in Hoogo's file:

gradient3.png

With antialiasing turned off, I can see the bands on my screen even without histogram correction applied, especially at magnifications above 100% and the "jumps" caused by the adjustments made in the lookup table of the video card. With antialiasing turned on, the bands are evened out, and the jumps disappear, so I think that having antialiasing for screen output definitely makes sense in 16 bit mode. Of course, even if an image looks good in PL due to antialiasing, there is no guarantee that it will look equally good in other programs. OS X Preview, for instance, doesn't seem to dither 16 bit tiffs.

So far, I thought that global antialiasing only controlled the way certain image elements are rendered in the bitmap file, but I wasn't aware that it also controlled an aspect of screen rendering. Maybe the two should be separated? Thinking of it, I guess that the antialiasing setting, as far as it affects bitmap files, should be a document property, not a global setting in PL, and antialiasing of 16 and 32 bit screen output should be controllable via the "View" menu.

Cheers

Burkhard.

[Hoogo]

I think that this is what Hoogo did – turned off the histogram correction in his sample file, made a screenshot, pasted it back and re-applied the histogram correction.

Yes, just like this.
Btw: When I convert the vector to bitmap, it always results in 8Bit. The dithering is applied correctly according to the setting of the antialiasing.

[bkh]

I think that this is what Hoogo did – turned off the histogram correction in his sample file, made a screenshot, pasted it back and re-applied the histogram correction.

Yes, just like this.
Btw: When I convert the vector to bitmap, it always results in 8Bit. The dithering is applied correctly according to the setting of the antialiasing.

I suppose you convert via the Attributes panel? I agree that it would be nice to have a 16 bit layer by default if the document is in 16 bit mode. However, if you use "Convert Layer Type …", you can choose 16 bit and it works as expected.

Cheers

Burkhard.

[Martin Huber]

I think that this is what Hoogo did – turned off the histogram correction in his sample file, made a screenshot, pasted it back and re-applied the histogram correction.

Yes, just like this.

Well, I misunderstood your sample document then.

So there is still the question: Why aren't your 16 bit images dithered on-screen?

Can others reproduce the problem?

Martin

[GM1968]

For me, the problem is not Photoline but my computer. The problem is visible with all softwares...

The modification of color profil ICC change the banding on-sceen (sRGB IEC61966-2.1 ou Samsung - natural pro color 1.0). This proves that it's a display problem and not a problem of color smoothing.

A tool for color measurement (curve) along a line would be nice ... We could check the color smoothing.

[Hoogo]

For me, the problem is not Photoline but my computer. The problem is visible with all softwares...

Partly...

If there's a visible banding for 8Bit pictures or photos, it's possibly because of a big color space and the LUTs, just as Burkhard described it. I can't imagine a simple way to solve that for displaying the picture. I assume that converting to 16Bit and using an adaptive soften with very small threshold could help, but that's surely too much change to the picture, that's not useful for displaying it.

But for gradients created in 16Bit and real 16Bit pictures it is possible to solve the problem by dithering the 16Bit picture to 8Bit before displaying it. That's how it used to be, and it still seems to work for others but me. I'll have to check if resetting my usersetting could help.

[Martin Huber]

I'll have to check if resetting my usersetting could help.

But please backup the settings before resetting. If it's really a problem with the settings, I'd like to check that.

Martin

[bkh]

If there's a visible banding for 8Bit pictures or photos, it's possibly because of a big color space and the LUTs, just as Burkhard described it. I can't imagine a simple way to solve that for displaying the picture.

Actually, PL solves the LUT problem for me in 16 bit mode. If I create an 8 bit gradient without dithering (i.e., with antialiasing turned off), then I can see the jumps in my display LUT. However, if I just switch to 16 bit mode, PL (or OS X?) dithers the individual steps and the gradient looks smooth (or, when I use broader steps, the steps look much more even). Here's an example, the real gradient goes from 0 to 25 without dithering. The upper part shows a screen shot with 8 bit colour depth, the lower strip is what I get when I just switch the bitmap layer to 16 bit – the steps are dithered to better match the expected greyscale value (I've applied a histogram correction to make the steps more visible.)

dithering.png

So even with 8 bit pictures, dithering helps to remove banding caused during image display.

Cheers

Burkhard.

[GM1968]

Sorry in french : http://www.cmp-color.fr/affichage_10_bits.html

[Herbert123]

Good thread - I learned something new, because I was looking for a dithering option for gradients when converting those to a bitmap version.

So far, I thought that global antialiasing only controlled the way certain image elements are rendered in the bitmap file, but I wasn't aware that it also controlled an aspect of screen rendering. Maybe the two should be separated? Thinking of it, I guess that the antialiasing setting, as far as it affects bitmap files, should be a document property, not a global setting in PL, and antialiasing of 16 and 32 bit screen output should be controllable via the "View" menu.

Cheers

Burkhard.

You can also set the anti-aliasing property on a per layer basis before converting. I do not think it is wise to move the anti-aliasing of 16 and 32bit screen output as a view property, since that property not only affects the way objects are viewed, but also controls (physically) how a conversion is made from one type of layer to the next.

I control anti-aliasing for each layer individually - gives me the most control.