Re: DWA compression

I *think* I described how that parameter is working at the giant comment in
ImfDwaCompressor.cpp. If it's vague that can probably be remedied.

The standard jpeg 1-100 sort of range is a bit annoying, because there is
large swath of the range that isn't terribly useful (like < 50), and not a
ton of control where high quality image folks might want there to be (>
90).

If I was going to hand wave about building a slider for DWAx, I'd probably
put one of end of the slider at 45, and then debate over where to put the
other end. There's a range of values that is probably good for production
images (maybe < 150) and a range of values that's probably useful for HDR
vacation snaps (< 500, lets say). For something rather arbitrary, how about
2000 for the far end.

Then, to give a little more control for the production folks, I might pick
a third point that's at the top end of what could be useful for production.
Use those three points for fit a quadratic.

Maybe:

   1.0  -->   45
   0.75 -->  125
   0.0  --> 2000

I doubt that a linear mapping would be terribly satisfying for control, but
I could be wrong.

Karl



On Sun, Aug 17, 2014 at 10:18 AM, Brendan Bolles <[email protected]>
wrote:

> On Aug 16, 2014, at 11:35 PM, Sean Y Chen wrote:
>
> > In Brendan Bolles's demo video, it seems that 100000 is the limit for a
> couple of the images, though one of them goes to 250000 before reaching
> file size 1.
>
>
> Here's the code for the little program I wrote to generate those
> sequences.  I'm basically doing compression = pow(10.0, frame / 25.0), with
> frames going from 0-149.  I wouldn't say it's perceptually linear exactly,
> although if you look at the MtTamWest example where I show difference mode,
> the diff seems to come in pretty linearly.
>
> Karl's has a nice write-up on the algorithm at the top of
> ImfDwaCompressor.cpp.
>

_______________________________________________
Openexr-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/openexr-devel