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

[Michael Niedermayer]

Hi

On Sat, Apr 07, 2007 at 03:56:18PM +0200, Ivo wrote:
> 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?

ok

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070407/6bf718a6/attachment.pgp>