[Ffmpeg-devel] [PATCH/RFC] 1-7 and 9-15 bits per pixel PGM files

[Ivo]

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).

--Ivo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: maxval.patch
Type: text/x-diff
Size: 1798 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070407/6d4a9889/attachment.patch>