HDR comparison, I16 vs FP16

bloodbob said:
Espically your description of method three really sounds like there should be a condintional.

There was a conditional in my first implementation, since I was optimizing for the minimum channel, so I only redistributed the bits whenever the range got smaller than the minimum channel. Optimizing for the maximum channel instead makes it possible to redistribute all the time, well, at least as long as the final bitdepths for RGB is the same as range (it's possible to move RGB into a separate lower precision texture, like RGB8 or DXT1 while keeping range in L16).
 
bloodbob said:
Method 4 encoder

Maybe I missed something here, but this looks more like method 2. The only difference I see is the ceil call, which I don't quite see the purpose of. Is that for emulating int math?
"range" seems to be unreferenced too.
 
Humus said:
Maybe I missed something here, but this looks more like method 2. The only difference I see is the ceil call, which I don't quite see the purpose of. Is that for emulating int math?
"range" seems to be unreferenced too.
Ceil is the int emulation bit if you do it on a GPU with HLSL you get errors. Just ignore the range variable.

Actually this is close to what I thought your descript of 3 was. Though I didn't think you had a ceilin in that at all its there to make the behaviour more predictable as you know the alpha channel can always be trusted and the maxium channel will always have atleast 15bits accuracy for values above 1.0 and you will always have a contrast ratio between the maxium and minium of atleast 1:2^15. If you didn't use ceiling for low numbers you would get errors if you have your maxium component as 2.49.

Also ciel avoids some potentially nasty rounding errors.
RGB values=2.49
You encoded 1.0 in the RGB components and you would encode 2.49/65536 which could very well be rounded to 2/65536. When you come to decode it ends up being 1.0x2.0 instead of 1.0 x 2.49 and you get ~25% error in the worest case.

Also using Ceil gets rid of a conditional to handle numbers less then 1.0.

Method 3 doesn't really need the cieling function because well when the cieling errors get large your gonna be having big accuracy problems anyway. ( Since the RGB precesision scales with the value of alpha. )

By my current calculation which could be very wrong method 3 provides ~31 bits of accuracy for the maxium channel and ~14.4 bits for the non maxium channels & method 4 ~31 bits of accuracy for the maxium channel and ~15 bits for the non maxium channels. Thats on average by summing the states ( including partial ) for both.


Edit: Please ignore this entire post its extremely wrong!. BTW ?precision?( not quite the correct word ) for method 4 is 17bits and I doubt humus' method 3 is anywhere near 31 bits either. Geeze 17 bits from 32 thats pretty bad I hope hums' method 3 can top that.
 
Last edited by a moderator:
Back
Top