Histogram don't takes Dither into account #38018

New Issue

Paulo José Oliveira Amaro · 2014-01-01T20:03:39+01:00

2014-01-01 20:03:39 +01:00

System Information
Ubuntu 13.10 32-bit
Intel Ironlake Mobile x86/MMX/SSE

Blender Version
Broken: 2.69.7 e1b322b

Shor description of error
The histogram in UV/Image Editor don't takes Dither into account. I can't make sure, but I suspect other analysis widgets don't do it also.
The image below compares a previous saved PNG with the Render Result (below) and the Current Render Result (above), both with Dither = 2.

Exact steps for others to reproduce the error

Render a empty scene with just a background image with low bit depth
Look in the histogram (with bands).
Set Dither value to 2. Histogram don't change.

Open and render the scene in blend file for confirm.
dithering-histogram-bug.blend

Another Dither related bug
There are another bug on Dither behaviour on Sequencer Editor output, maybe related to this bug - and for this reason I'll not open another task -, witch Dither is not applied to Render Result if the Sequence's strip has no Float data. For instance, if you add to Sequencer the same rainbow image used here (arcoiris.png ), and don't enable "Convert to Float" option, Dither will not be applied to the Final Render. Just check the "Convert to Float" box of the image strip and Dither will be applied. Sorry if is too away from this bug context, but I think is may be related, so it can be easier to fix both at once.

**System Information** Ubuntu 13.10 32-bit Intel Ironlake Mobile x86/MMX/SSE **Blender Version** Broken: 2.69.7 e1b322b **Shor description of error** The histogram in UV/Image Editor don't takes Dither into account. I can't make sure, but I suspect other analysis widgets don't do it also. The image below compares a previous saved PNG with the Render Result (below) and the Current Render Result (above), both with Dither = 2. ![dithering-histogram-bug.blend.png](https://archive.blender.org/developer/F60176/dithering-histogram-bug.blend.png) **Exact steps for others to reproduce the error** 1. Render a empty scene with just a background image with low bit depth 2. Look in the histogram (with bands). 3. Set Dither value to 2. Histogram don't change. Open and render the scene in blend file for confirm. [dithering-histogram-bug.blend](https://archive.blender.org/developer/F60175/dithering-histogram-bug.blend) **Another Dither related bug** There are another bug on Dither behaviour on Sequencer Editor output, maybe related to this bug - and for this reason I'll not open another task -, witch Dither is not applied to Render Result if the Sequence's strip has no Float data. For instance, if you add to Sequencer the same rainbow image used here ([arcoiris.png ](https://developer.blender.org/file/data/unbptwoelylkzku3gpwg/PHID-FILE-wgwdts6yftap5qdipnnu/arcoiris.png)), and don't enable "Convert to Float" option, Dither will not be applied to the Final Render. Just check the "Convert to Float" box of the image strip and Dither will be applied. Sorry if is too away from this bug context, but I think is may be related, so it can be easier to fix both at once.

Paulo José Oliveira Amaro commented

2014-01-01 20:03:39 +01:00

Changed status to: 'Open'

Paulo José Oliveira Amaro commented

2014-01-01 20:03:39 +01:00

Added subscriber: @PauloJoseOliveiraAmaro

Brecht Van Lommel commented

2014-01-01 23:46:35 +01:00

Added subscribers: @Sergey, @brecht

Brecht Van Lommel commented

2014-01-01 23:46:35 +01:00

About dithering for histograms, I can see the case for doing it and not doing it. It's a trick to display float images on a monitor that can only handle byte precision, should it really affect this? I wouldn't be surprised if other applications didn't include dithering either, but I don't know.

Dither not being applied to byte images, that is intentional. What dithering does is avoid banding when you convert from float to byte precision, it uses the extra information in the float image. If it's already a byte image that information is lost, dithering should have been applied earlier in the pipeline.

About dithering for histograms, I can see the case for doing it and not doing it. It's a trick to display float images on a monitor that can only handle byte precision, should it really affect this? I wouldn't be surprised if other applications didn't include dithering either, but I don't know. Dither not being applied to byte images, that is intentional. What dithering does is avoid banding when you convert from float to byte precision, it uses the extra information in the float image. If it's already a byte image that information is lost, dithering should have been applied earlier in the pipeline.

Paulo José Oliveira Amaro commented

2014-01-02 00:33:04 +01:00

@brecht, Dither also can be used to add noise to a flat image. In my case, I play with the Curves modifier on a H264 video strip, witch creates bands on histogram. With dithering I can reduce banding effect, adding noise with dithering. But it only works with "Convert to Float" enabled, what is no intuitive at all.

Dither is not applied internally by the curves modifier - as an attempt to accommodate the float result from the modifier into the byte precision strip output. Are you suggesting it should be? What do you mean with dithering applied earlier?

In my opinion, if dithering (or any other post effect) is used, it is intentionally to be applied to the output image. No surprising, it's saved within the image. Then it should be taken into account by the analysis tools. Otherwise, we are not analysing the final result.

@brecht, Dither also can be used to add noise to a flat image. In my case, I play with the Curves modifier on a H264 video strip, witch creates bands on histogram. With dithering I can reduce banding effect, adding noise with dithering. But it only works with "Convert to Float" enabled, what is no intuitive at all. Dither is not applied internally by the curves modifier - as an attempt to accommodate the float result from the modifier into the byte precision strip output. Are you suggesting it should be? What do you mean with dithering applied earlier? In my opinion, if dithering (or any other post effect) is used, it is intentionally to be applied to the output image. No surprising, it's saved within the image. Then it should be taken into account by the analysis tools. Otherwise, we are not analysing the final result.

Sergey Sharybin commented

2014-01-02 12:31:39 +01:00

@PauloJoseOliveiraAmaro, dither is the last step of color management pipeline for float buffers. And it adds noise directly to the display buffer which is stored in bytes. It does not affect original float buffer and could not be used for effects in that buffer.

In image editor histogram works with the original buffer and it know nothing about the rest of color management.

@PauloJoseOliveiraAmaro, dither is the last step of color management pipeline for float buffers. And it adds noise directly to the display buffer which is stored in bytes. It does not affect original float buffer and could not be used for effects in that buffer. In image editor histogram works with the original buffer and it know nothing about the rest of color management.

Paulo José Oliveira Amaro commented

2014-01-02 19:42:38 +01:00

Thank you for the explanation, @sergey. I think just now I understand why Dither has to be the last step. But I still think it should be applied before histogram analysis, otherwise we can't know its effectiveness in removing banding.

Correct me if I'm wrong, but it seems that histogram takes into account any option of Color Management in "Scene" tab. I mean, it changes when I play with "Look" presets, or gamma/expo or curstomize Curves.

Thank you for the explanation, @sergey. I think just now I understand why Dither has to be the last step. But I still think it should be applied before histogram analysis, otherwise we can't know its effectiveness in removing banding. Correct me if I'm wrong, but it seems that histogram takes into account any option of Color Management in "Scene" tab. I mean, it changes when I play with "Look" presets, or gamma/expo or curstomize Curves.

Sergey Sharybin commented

2014-01-02 21:01:28 +01:00

Historgram (and other scopes) doesn't make much sense in scene linear space, so it for sure will convert float to the display space first. But they're still operating on float buffer, no conversion to byte buffer happens to calculate scopes.

Dither is really just a thing to avoid color bands on the monitor when displaying float buffer on a byte display. For other usages it's just a rather unwanted noise. Don't think it's really to be taken into account by the scopes.

Historgram (and other scopes) doesn't make much sense in scene linear space, so it for sure will convert float to the display space first. But they're still operating on float buffer, no conversion to byte buffer happens to calculate scopes. Dither is really just a thing to avoid color bands on the monitor when displaying float buffer on a byte display. For other usages it's just a rather unwanted noise. Don't think it's really to be taken into account by the scopes.

Paulo José Oliveira Amaro commented

2014-01-02 23:05:24 +01:00

I know what you mean. I know dither has no practical utility in many aspects.

But analysing an histogram with banding effect is actually hard and also invites to a non precise correction. So to try understand what could be done to improve it, I tried to recreate the problem in Darktable. For those who don't know it, Darktable is one of the most powerful tools for image editing, comparable to Adobe LightRoom.

Well, I tried to get a non corrected image and correct it in Darktable and Blender, both (almost) exactly same way. Here the result:
Image corrected in Blender with Curves Modifier:

Image corrected in Darktable with Base Curves, exported as PNG 8bit and added to Blender:

Darktable correction don't apply any dithering to avoid banding. It even has a Dither module, but I didn't use it. The interesting thing is that its histogram monitor don't show any banding at all:

So it makes me think how can their histogram handle banding so well? Maybe Blender could try an option to do that too. Then would not to be needed to use Dither to prevent banding in histogram.

Interesting to note how the Blue channel in Darktable Histogram is much darker than the Blender histogram for the same channel, aside the fact both show the same image result... It feels like another bug (for Blender or for Darktable)

I know what you mean. I know dither has no practical utility in many aspects. But analysing an histogram with banding effect is actually hard and also invites to a non precise correction. So to try understand what could be done to improve it, I tried to recreate the problem in Darktable. For those who don't know it, Darktable is one of the most powerful tools for image editing, comparable to Adobe LightRoom. Well, I tried to get a non corrected image and correct it in Darktable and Blender, both (almost) exactly same way. Here the result: Image corrected in Blender with Curves Modifier: ![blender-no-dither.png](https://archive.blender.org/developer/F60678/blender-no-dither.png) Image corrected in Darktable with Base Curves, exported as PNG 8bit and added to Blender: ![blender-darktable.png](https://archive.blender.org/developer/F60677/blender-darktable.png) Darktable correction don't apply any dithering to avoid banding. It even has a Dither module, but I didn't use it. The interesting thing is that its histogram monitor don't show any banding at all: ![Screenshot_from_2014-01-02_19:39:45.png](https://archive.blender.org/developer/F60675/Screenshot_from_2014-01-02_19_39_45.png) So it makes me think how can their histogram handle banding so well? Maybe Blender could try an option to do that too. Then would not to be needed to use Dither to prevent banding in histogram. Interesting to note how the Blue channel in Darktable Histogram is much darker than the Blender histogram for the same channel, aside the fact both show the same image result... It feels like another bug (for Blender or for Darktable)

Brecht Van Lommel commented

2014-01-03 00:05:26 +01:00

The gaps in the histogram are not the same as banding. An undithered image of a gradient will have no gaps in the histogram but still show very clear banding anyway. There is a relation in some circumstances but you can't equate banding in the image and gaps in the histogram, you can have either one without the other.

I don't know the cause of the gaps in the histogram, for example PNG compression could cause this, I can't tell without the source image. The reason you do not see them in darktable (even if they are there) may be that it samples a histogram with e.g. 128 bins instead of 256 bins as in Blender, which would smooth out the histogram but would hide details.

The gaps in the histogram are not the same as banding. An undithered image of a gradient will have no gaps in the histogram but still show very clear banding anyway. There is a relation in some circumstances but you can't equate banding in the image and gaps in the histogram, you can have either one without the other. I don't know the cause of the gaps in the histogram, for example PNG compression could cause this, I can't tell without the source image. The reason you do not see them in darktable (even if they are there) may be that it samples a histogram with e.g. 128 bins instead of 256 bins as in Blender, which would smooth out the histogram but would hide details.

Paulo José Oliveira Amaro commented

2014-01-03 02:19:12 +01:00

@brecht If a gradient is 8bit (like the png image I used), this is the depth of colours, right? Its represent the quantization for the original color information. When I applied the Curves Modifier, it maps these values into another values. And as you can see, I actually increase contrast of the image, so a value of 35 before it became now 0, and a value of 235 became 255. So I think this make some pixels that was close (spatially and in value), with values like 200 and 201, become separated in value after the modifier is applied, turning into 199 and 201. This way, none pixel has the value of 200 and there's a gap in the histogram for the 200 value. This is the cause for gaps.

With Dither, theses spatially close pixels, but not close in "real value" anymore are randomized a little and gain some noise. This way, some of these pixels with value of 199 became 200, and some of 201 became 200, filling the gap of 200 in the histogram.

I think you already knew every bit of what I sad, but I did it to show you actually what I think to know and what is my understanding about it. So, If I'm misunderstanding something (very often), then it is easier to you pointing where.

PS: I tried to understand the behaviour of Darktable's Histogram and sorry (I can be wrong), but this is a mess! It is actually very unstable and completely unpredictable for some images. So I think you may be right about the amount of samples taken by Darktable.

@brecht If a gradient is 8bit (like the [png image ](https://developer.blender.org/file/data/6vt2thchevugndltk53y/PHID-FILE-yz6jxqhwn7yonoglvjad/brian.png) I used), this is the depth of colours, right? Its represent the quantization for the original color information. When I applied the Curves Modifier, it maps these values into another values. And as you can see, I actually increase contrast of the image, so a value of 35 before it became now 0, and a value of 235 became 255. So I think this make some pixels that was close (spatially and in value), with values like 200 and 201, become separated in value after the modifier is applied, turning into 199 and 201. This way, none pixel has the value of 200 and there's a gap in the histogram for the 200 value. This is the cause for gaps. With Dither, theses spatially close pixels, but not close in "real value" anymore are randomized a little and gain some noise. This way, some of these pixels with value of 199 became 200, and some of 201 became 200, filling the gap of 200 in the histogram. I think you already knew every bit of what I sad, but I did it to show you actually what **I think to know** and what is my understanding about it. So, If I'm misunderstanding something (very often), then it is easier to you pointing where. PS: I tried to understand the behaviour of Darktable's Histogram and sorry (I can be wrong), but this is a mess! It is actually very unstable and completely unpredictable for some images. So I think you may be right about the amount of samples taken by Darktable.

Sergey Sharybin commented

2014-01-03 09:05:58 +01:00

Hold on, are you talking about histogram of 8bit image with curve (or other color correction) modifier applied? For sure this will give you gaps in the histogram due to nature of 8bit precision: correction happens with 8bit precision which leads to data loss due to rounding. This is not a bug and that's what you'll see in gimp as well.

Enabling Convert Float for this strip will give you smoother-looking historgram.

Hold on, are you talking about histogram of 8bit image with curve (or other color correction) modifier applied? For sure this will give you gaps in the histogram due to nature of 8bit precision: correction happens with 8bit precision which leads to data loss due to rounding. This is not a bug and that's what you'll see in gimp as well. Enabling `Convert Float` for this strip will give you smoother-looking historgram.

Paulo José Oliveira Amaro commented

2014-01-03 10:34:26 +01:00

Yes, this is very common problem. In Gimp I usually overlay a noise texture layer to the image, which is almost the same than applying Dither in Blender.

At least for me, Convert to Float has no effect in VSE Histogram but just extends its horizontal limits. In the Render Result histogram, it has no effect also.

In the image, from top to bottom:

1st histogram: Original image with curves modifier and Convert To Float disabled
2st histogram: Original image with curves modifier and Convert To Float enabled
3st histogram: Render Result histogram for the Convert To Float enabled image (it is exactly the same when disabled)
4st histogram: Render Result saved in PNG 8bit format and then opened back in the UV/Image Editor

The blend file: histogram-bug1.blend

Yes, this is very common problem. In Gimp I usually overlay a noise texture layer to the image, which is almost the same than applying Dither in Blender. At least for me, Convert to Float has no effect in VSE Histogram but just extends its horizontal limits. In the Render Result histogram, it has no effect also. ![histogram-bug1.blend.png](https://archive.blender.org/developer/F60956/histogram-bug1.blend.png) In the image, from top to bottom: - 1st histogram: Original image with curves modifier and Convert To Float **disabled** - 2st histogram: Original image with curves modifier and Convert To Float **enabled** - 3st histogram: Render Result histogram for the Convert To Float **enabled** image (it is exactly the same when disabled) - 4st histogram: Render Result saved in PNG 8bit format and then opened back in the UV/Image Editor The blend file: [histogram-bug1.blend](https://archive.blender.org/developer/F60953/histogram-bug1.blend)

Paulo José Oliveira Amaro commented

2014-01-03 10:47:58 +01:00

Since banding effect (in this case showed by the histogram) is inevitable, Dither can help to minimize the problem. And see it through the histogram would be a way to know how much it can help, and this way, to know how much it is needed.

And it can help a lot:

Histograms with banding are without Dither
Histograms without banding are with Dither=2 (saved in PNG and opened back to blender)

Since banding effect (in this case showed by the histogram) is inevitable, Dither can help to minimize the problem. And see it through the histogram would be a way to know how much it can help, and this way, to know how much it is needed. And it can help a lot: ![histogram-bug2.png](https://archive.blender.org/developer/F60964/histogram-bug2.png) Histograms with banding are without Dither Histograms without banding are with Dither=2 (saved in PNG and opened back to blender)

Sergey Sharybin commented

2014-01-03 11:38:02 +01:00

Ah well, was confused by some additional re-sampling being applied (due to image and render resolution mismatch). Indeed conversion to float wouldn't make it so image covers the whole 0..1 range continuously.

Gaps in the histogram with Convert Float enabled could be explained by the same fact -- 0..1 space is not covered continuously, and there're gaps in the colors distribution.

Now, if you apply dither here, you'll just partially masquerade the issue by adding some additional pixels with "missing" colors (it'll look like partially filled gaps).

So, here's the summary:

From math POV histogram works as it should, and "discontinuity" is caused by higher resolution comparing to darktable. We might reduce resolution, but that'd make you impossible to see all the details.
Color-managing of 8bit byte images will never give you smooth color distribution. You could fake the distribution by adding noise there, but dither is not what you shall rely. You can overlay a noise pattern and multiple underlying strips on it. This could give smooth color distribution in some circumstances.
I'm not sure why you call it "problem". It's just a detailed information about colors in your image.
I might also be full of crap and missing something here, but that's why we've got @brecht in this thread :)

Ah well, was confused by some additional re-sampling being applied (due to image and render resolution mismatch). Indeed conversion to float wouldn't make it so image covers the whole 0..1 range continuously. Gaps in the histogram with `Convert Float` enabled could be explained by the same fact -- 0..1 space is not covered continuously, and there're gaps in the colors distribution. Now, if you apply dither here, you'll just partially masquerade the issue by adding some additional pixels with "missing" colors (it'll look like partially filled gaps). So, here's the summary: * From math POV histogram works as it should, and "discontinuity" is caused by higher resolution comparing to darktable. We might reduce resolution, but that'd make you impossible to see all the details. * Color-managing of 8bit byte images will never give you smooth color distribution. You could fake the distribution by adding noise there, but dither is not what you shall rely. You can overlay a noise pattern and multiple underlying strips on it. This could give smooth color distribution in some circumstances. * I'm not sure why you call it "problem". It's just a detailed information about colors in your image. * I might also be full of crap and missing something here, but that's why we've got @brecht in this thread :)

Paulo José Oliveira Amaro commented

2014-01-03 11:48:06 +01:00

I found that for movie strips (MOV h264 8bit), VSE Histogram will not include Dither result (of course, unfortunately), but UV/Image Editor histogram will do!

No dither and with dither Render Results. "Convert to Float" is disabled. Amazing how the histogram changes, with almost no visual change in the image (the darks get lighter a little, very little)

I found that for movie strips (MOV h264 8bit), VSE Histogram will not include Dither result (of course, unfortunately), but UV/Image Editor histogram will do! ![color-correction-parque-no-dither.blend.png](https://archive.blender.org/developer/F60976/color-correction-parque-no-dither.blend.png) ![color-correction-parque.blend-dither.png](https://archive.blender.org/developer/F60975/color-correction-parque.blend-dither.png) No dither and with dither Render Results. "Convert to Float" is disabled. Amazing how the histogram changes, with almost no visual change in the image (the darks get lighter a little, very little)

Paulo José Oliveira Amaro commented

2014-01-03 12:10:33 +01:00

@Sergey, I call it a problem because it affects a lot the way Histogram looks like, and then it affects the analysis. See the peaks in the VSE histogram. Some of them are not true peaks, they are artefacts caused by lost of information - that you mentioned -, but are not visually perceptible in the image. So if you see them in the color correction process, it may be unclear if they are caused by the round errors or are real peaks (that should be decreased - by changing all your color correction - to avoid to left the image unsafe (i.e., overflow the allowed light intensity limit for a broadcast).

Specially for video, these gaped histograms are very imprecise to analyse, because the codec compression when exporting the final video (almost all 8bit) will do almost the same job as Dither does of eliminating the gaps. So the final histogram will be very different than witch one you was work on. What is some kind of paradox, because the most accurate the gaps are to show the problem of rounding a processed image, most inaccurate it turns the analysis process - what is the reason histograms are made for.

@Sergey, I call it a problem because it affects a lot the way Histogram looks like, and then it affects the analysis. See the peaks in the VSE histogram. Some of them are not true peaks, they are artefacts caused by lost of information - that you mentioned -, but are not visually perceptible in the image. So if you see them in the color correction process, it may be unclear if they are caused by the round errors or are real peaks (that should be decreased - by changing all your color correction - to avoid to left the image unsafe (i.e., overflow the allowed light intensity limit for a broadcast). Specially for video, these gaped histograms are very imprecise to analyse, because the codec compression when exporting the final video (almost all 8bit) will do almost the same job as Dither does of eliminating the gaps. So the final histogram will be very different than witch one you was work on. What is some kind of paradox, because the most accurate the gaps are to show the problem of rounding a processed image, most inaccurate it turns the analysis process - what is the reason histograms are made for.

Sergey Sharybin commented

2014-01-03 17:17:01 +01:00

I couldn't see any difference in render result histogram with the dither change. Histogram of render result stays the same for me in all cases. What i did for tests is:

Added movie strip
Applied curves modifier on it so it's histogram have some gaps
Rendered the image, and in image editor opened histogram

That histogram in image editor had gaps with both dither=0 and dither=2. Mind uploading your file where you saw difference in render result.

Peaks can not appear due to information loss, only gaps might appear. And for analysis you want to see actual data, not something which will happen on image display stage when noise is being applied on your float image to avoid color bands. In almost all the cases you would want to know what the histogram of your actual float image is.

As for codecs, unless they're lossless formats analysis of histogram is always imprecise. Codec will change the histogram, that's in the nature of behavior of lossy formats. If you're gonna to use dither to try to mimic behavior of codec you're still screwed up -- you couldn't know whether codec's behavior will mimic your dither pattern. So you simply couldn't predict behavior of histogram of encoded video.

Now, if video codec is lossless, then it wouldn't change your histogram. If you're working in float pipeline (as you should) then histogram wouldn't suddenly become gapped due to float->byte conversion. Dither will only "smooth" the histogram (really, dither is not to make histogram look without gaps, it's to avoid color bands). If you're working in byte pipeline, then histogram will map directly from what you see in blender to what you've got in the video.

Further, if you're grading 8 bit image (which i have no idea why you do, video is already in a lossy format, and tweaking colors further will loss even more data. Color correction is usually performed on at least half-float file formats in a production pipeline) then dither is not what you need to use. Dither will have no affect in this case (at least by design, it might be some issue in the code which violated the design and which you're trying to use for your specific need).

And last but not least, as for the original request of taking dither into account. Imagine situation of you're having video strip with curves applied. It'll lead to gaps for sure. Now, if you convert this strip to float and apply dither, in most of cases gaps wouldn't fully eliminate. They'll be partially filled, but you'll still have gaps. So i don't see why it suddenly will make you happy.

Not saying things are ideal here, but they're all working as were intended to. Improvements here are possible, but i couldn't think of any at this point which wouldn't ruin others' expectation about the tools and information.

I couldn't see any difference in render result histogram with the dither change. Histogram of render result stays the same for me in all cases. What i did for tests is: * Added movie strip * Applied curves modifier on it so it's histogram have some gaps * Rendered the image, and in image editor opened histogram That histogram in image editor had gaps with both dither=0 and dither=2. Mind uploading your file where you saw difference in render result. Peaks can not appear due to information loss, only gaps might appear. And for analysis you want to see actual data, not something which will happen on image display stage when noise is being applied on your float image to avoid color bands. In almost all the cases you would want to know what the histogram of your actual float image is. As for codecs, unless they're lossless formats analysis of histogram is always imprecise. Codec *will* change the histogram, that's in the nature of behavior of lossy formats. If you're gonna to use dither to try to mimic behavior of codec you're still screwed up -- you couldn't know whether codec's behavior will mimic your dither pattern. So you simply couldn't predict behavior of histogram of encoded video. Now, if video codec is lossless, then it wouldn't change your histogram. If you're working in float pipeline (as you should) then histogram wouldn't suddenly become gapped due to float->byte conversion. Dither will only "smooth" the histogram (really, dither is not to make histogram look without gaps, it's to avoid color bands). If you're working in byte pipeline, then histogram will map directly from what you see in blender to what you've got in the video. Further, if you're grading 8 bit image (which i have no idea why you do, video is already in a lossy format, and tweaking colors further will loss even more data. Color correction is usually performed on at least half-float file formats in a production pipeline) then dither is not what you need to use. Dither will have no affect in this case (at least by design, it might be some issue in the code which violated the design and which you're trying to use for your specific need). And last but not least, as for the original request of taking dither into account. Imagine situation of you're having video strip with curves applied. It'll lead to gaps for sure. Now, if you convert this strip to float and apply dither, in most of cases gaps wouldn't fully eliminate. They'll be partially filled, but you'll still have gaps. So i don't see why it suddenly will make you happy. Not saying things are ideal here, but they're all working as were intended to. Improvements here are possible, but i couldn't think of any at this point which wouldn't ruin others' expectation about the tools and information.

Paulo José Oliveira Amaro commented

2014-01-03 23:44:51 +01:00

You pointed things that just don't work the same way in my experience. Many cinematographers are using DSLR footage (lossy 8bit, not raw video) for a long time, essentially for grading in post production. There's a topic on the [DVXUser forums ]] with many examples and information. http:*www.technicolor.com/en/solutions-services/cinestyle even created a color profile called Cinestyle for Canon DSLR that saves footage in an almost LOG space intended for grading purposes. http:*web.canon.jp/imaging/picturestyle/file/videocamera.html did it too recently. The downside effects of doing this are very knew ( http:*www.shutterangle.com/2012/canon-picture-styles-shooting-flat-or-not/ , here and http:*philipbloom.net/forum/threads/canon-technicolor-cinestyles-what-say-you.647/page-2 ), but the [ http://www.eoshd.com/content/641/hands-on-guide-to-technicolor-cinestyle-lut-curves-and-canon-600d | advantages are great, most to retain more information on shadows and highlights.

Searching for video examples to show that's not my specific need, I found a tutorial that uses Noise Reduction and Dither to remove banding and increase the bit depth of a 8bit footage to prepare to grading. You can see the effect of dithering is positive to grading process for 8bit image.

Dither don't eliminate, but minimizes banding effect. In Blender, if you want you can edit without Dither and see the histogram without Dither. But if you enable Dither, you can't see the histogram with dither - dither that will be saved in the 8bit exported image or video. If it's not a problem and it's working as was intended to, I'm OK with closing this bug as Invalid. Thank you for your time and good argumentation.

You pointed things that just don't work the same way in my experience. Many cinematographers are using DSLR footage (lossy 8bit, not raw video) for a long time, essentially for grading in post production. There's a topic on the [DVXUser forums ]] with many examples and information. [[ http:*www.technicolor.com/en/solutions-services/cinestyle | Technocolor ]] even created a color profile called Cinestyle for Canon DSLR that saves footage in an almost LOG space intended for grading purposes. [[ http:*web.canon.jp/imaging/picturestyle/file/videocamera.html | Canon ]] did it too recently. The downside effects of doing this are very knew ([[ http:*www.shutterangle.com/2012/canon-picture-styles-shooting-flat-or-not/ | here ]], [[ http:*photography-on-the.net/forum/showthread.php?t=1056420 | here ]] and [[ http:*philipbloom.net/forum/threads/canon-technicolor-cinestyles-what-say-you.647/page-2 | here ]]), but the [[ http://www.eoshd.com/content/641/hands-on-guide-to-technicolor-cinestyle-lut-curves-and-canon-600d | advantages ](http:*www.dvxuser.com/V6/showthread.php?262094-Adventures-in-the-PSE) are great, most to retain more information on shadows and highlights. Searching for video examples to show that's not **my specific** need, I found [a tutorial ](http://vimeo.com/19908622) that uses Noise Reduction and Dither to remove banding and increase the bit depth of a 8bit footage to prepare to grading. You can see the effect of dithering is positive to grading process for 8bit image. Dither don't eliminate, but minimizes banding effect. In Blender, if you want you **can** edit **without** Dither and see the histogram **without** Dither. But if you enable Dither, you **can't see** the histogram **with dither** - dither that **will be saved** in the 8bit exported image or video. If it's not a problem and it's working as was intended to, I'm OK with closing this bug as Invalid. Thank you for your time and good argumentation.

Brecht Van Lommel commented

2014-01-09 00:01:55 +01:00

Changed status from 'Open' to: 'Archived'

Brecht Van Lommel closed this issue

2014-01-09 00:01:55 +01:00

Brecht Van Lommel self-assigned this 2014-01-09 00:01:55 +01:00

Brecht Van Lommel commented

2014-01-09 00:01:55 +01:00

I'll close this since I do think dither and the histogram are working as intended.

There's also various things we could do to improve quality of images when you edit in 8 bit, but for best quality footage should be converted to float, but we don't do it by default because it's slower and the sequencer is intended to have reasonably fast playback with most color editing done in compositing.

I'll close this since I do think dither and the histogram are working as intended. There's also various things we could do to improve quality of images when you edit in 8 bit, but for best quality footage should be converted to float, but we don't do it by default because it's slower and the sequencer is intended to have reasonably fast playback with most color editing done in compositing.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Histogram don't takes Dither into account #38018