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
