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

[Ivo]

On Friday 06 April 2007 18:58, Michael Niedermayer wrote:
> On Fri, Apr 06, 2007 at 05:06:59PM +0200, Ivo wrote:
> > It seems that for legacy Cineon, there are only 10-bit log files in the
> > wild (which is that the Kodak scanner produces) with matching dimension
> > for all channels. For DPX files, it looks like 1, 8, 10, 12 and 16 bits
> > per component are common. There's also 32 bits (float) but I haven't
> > seen an implementation of that yet.
> >
> > Pixels can be stored in a variety of ways. They define cells being 8,
> > 16 or 32 bits wide and fields being packed inside those cells. They can
> > be padded with zeroes, or they can have as much fields per cell as
> > possible (i.e. 6 bits per field, ch1[6] ch2[6] ch3[6] ch1[6] ch2[6]
> > pad[2] etc...). Well, supporting these funky schemes is madness, so
> > they should be torn appart and stored as 1 or 2 bytes per pixel IMHO.
> > The question is, should we add PIX_FMT's for 10, 12 and 16
> > bits/component RGB(A) and do not support anything else or should we
> > only add PIX_FMT_RGB48/64 and blow everything else up in the image
> > decoder? (including proper scaling so white stays white, i.e. 0x3fff ->
> > 0xffff instead of 0xfffc).
>
> i think there is no sense in supporting anything between 8 and 16 bits
> per component, at least not currently, it can always be added later
>
> its IMHO too a big mess to manage hundreads of pix formats noone uses
> this of course would change if these formats get used alot more in the
> future or we would have a more generic pix_fmt_descriptor which can
> handle arbitrary pix_fmts  ...

Perhaps we could find a compromise and only add a 16-bits/component RGB 
PIX_FMT and have the decoder upgrade lower bitdepths itself? Otherwise I 
don't see much sense in adding a DPX/Cineon decoder if all components have 
to be truncated down to 8-bits.

What I propose is adding PIX_FMT_RGB48BE and PIX_FMT_RGB48LE and three new 
functions in libswscale, namely rgb48torgb24, rgb24torgb48 and rgb48swap 
(similar to how gray8 and gray16 are currently handled). After that, I will 
add 9-16 bits PPM/PAM support to pnm.c (probably during the process so the 
libswscale changes can be tested) and it will make it possible to write a 
half-decent DPX/Cineon decoder. What do you think?

--Ivo