Page MenuHome

Fix T41185 Dithering is not applied for Texture Baking
Needs RevisionPublic

Authored by Dalai Felinto (dfelinto) on Aug 6 2014, 11:39 AM.

Details

Summary

Applying dithering for non-color bake types only (e.g., Normal, UV).
Note I didn't test Blender internal baking, but I suspect dithering doesn't work there either.

Diff Detail

Repository
rB Blender
Branch
fix-bake-dither

Event Timeline

Dalai Felinto (dfelinto) retitled this revision from to Fix T41185 Dithering is not applied for Texture Baking.Aug 6 2014, 11:39 AM
Dalai Felinto (dfelinto) updated this object.
Dalai Felinto (dfelinto) updated this revision to Diff 2343.

Not sure about this, if clear isn't set it will re-dither each time.
Maybe it should dither when writing assigning pixels rather then on save.

Dalai Felinto (dfelinto) updated this revision to Diff 2344.
  • only setting dither when "use_clear"

@Campbell Barton (campbellbarton) how about that? (it works fine too)

Then it just seems an unreliable feature, cant this be done when assigning pixels instead?

@camobellbarton, i'm not sure why you think there's dither will accumulate and o idea how you're gonna to apply it on pixels apply.

Dither is a part of color management display, it's only used when converting float buffer to the display space, avoiding color bands. It'll be only stored back to the image if you save the file to byte file format.

At least that's the theory.

@Sergey Sharybin (sergey) - right, you would have to bake, save, load, bake again.
Also dither would need to be set high for this to be noticeably lossy.

It still seems a bit odd to me, baking can be used like painting, you may only bake to some small region, so changing image settings based on that isnt great imho.
since dither is very subtle, probably its OK though.

Still think its more correct to apply dither only to baked areas.

How about any complaints we get on this are known-limitation and closed. (probably nobody notices!)

I'm not really sure why saving and rebaking will add more dither. If you save float to byte, load, then dither wouldn't be applied because it's a byte space already.

Saving float to float and rebaking wouldn't add extra dither at all.

I'd rather not to try limiting dither to specific areas, dither is a part of CM pipeline which simply shouldn't be aware on where color came from.

Dither 2.0 is greater than 1/255, so re-dithering will be lossy.

Chatted on IRC with Sergey, and since this is only ever used going float->byte, then its OK. (since baking doesn't turn a byte image into a float).

That means if you open a PNG, bake to it, you cant avoid banding right? - You would have to explicitly convert to float buffer (which we dont have obvious way to do), or add new float buffer and save over your old PNG.

Dalai Felinto (dfelinto) updated this revision to Diff 2346.
  • dither even when !use_clear

I read the IRC discussion. Not sure I understand it entirely, but thanks for going over that. From what I read we should do dither even when use_clear is false. We are writing to a mask, so it shouldn't over-dither. good to go?

@Dalai Felinto (dfelinto).

Theres a bit of a conflict with applying dither since current imbuf code only does when float->byte.

So probably its better to dither-on-bake, this could be done by adding a bit of noise when writing bake pixels back, (only in the case where those pixels change from the original).

This wont give a nice distribution but its OK for avoiding banding.

A different solution would be to apply dither as is done with renders, but only dither the baked pixels. but this still requires the image be a float to begin with.

Sergey Sharybin (sergey) requested changes to this revision.
This revision now requires changes to proceed.Sep 5 2014, 9:36 AM