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

Justin Ruggles justinruggles
Fri Apr 6 21:13:05 CEST 2007

Ivo wrote:
> On Friday 06 April 2007 16:17, Reimar D?ffinger wrote:
>>On Fri, Apr 06, 2007 at 03:01:09PM +0200, Ivo wrote:
>>>PGM files have a maxval value in their headers defining the maximum
>>>value a pixel can have. This can be anything from 1 to 65535. Currently
>>>pnm.c only supports 255 and 65535. The attached patch fixes this (not
>>>yet for PPM and PAM files which can also have any maxval from 1 to
>>>65535 for the R, G and B components), but I am not sure if this is the
>>>way to go.
>>Is this transformation lossless (ignoring the case of a wrong maxval)?
> Yes, though I think I should add checks for maxval being between 0 and 
> 65536, not including the boundaries.
>>If you only care for these maxvals the code can be extremely simplified,
>>even doing SIMD without normal C constructs.
>>IMO simple enough that it doesn't need extra PIX_FMTs.
> 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.


More information about the ffmpeg-devel mailing list