[Ffmpeg-devel] [PATCH/RFC] 1-7 and 9-15 bits per pixel PGM files
Sat Apr 7 15:43:40 CEST 2007
On Friday 06 April 2007 21:13, Justin Ruggles wrote:
> Ivo wrote:
> > OK. I think it is reasonable to assume only maxvals of (2^n)-1 for
> > 0<n<=16 are used in the wild. I have never seen anything other than
> > 255, 1023, 2047, 4095, 16383 and 65535.
> I have seen others in the wild. For example, when the dcraw program
> converts raw camera images formats to pnm it uses the camera's native
> raw format maximum value, which is sometimes a very odd non-power-of-two
> number. My guess is that it's either due to the A/D converter and/or to
> give some headroom for in-camera postprocessing.
I see. I have thought about it and I think the shift/or "upgrading" to
8/16-bits per component is better than multiply/division, even in this
case, because it won't introduce rounding errors and can be downgraded
losslessly (simple shift). With odd non-power-of-two maxvals the image will
be a little bit darker than it is supposed to be, but a lot less than it
used to be with the old code. A future filter layer could compensate for
those cases (luminance filter).
Attached is a new patch that implements this. I could merge the 8 and 16
bits cases, but that would be slower and degrade readability of the code,
so I left them separately.
It does not handle >8 bits/component RGB images yet, as there is no suitable
PIX_FMT for that (yet).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1798 bytes
Desc: not available
More information about the ffmpeg-devel