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

[Michael Niedermayer]

Hi

On Fri, Apr 06, 2007 at 05:06:59PM +0200, Ivo wrote:
[...]
> >>[Cineon weird formats]
> > Well, how are they stored? Do they actually use e.g. 12 bit per pixel,
> > or do they in reality use 16 bit per pixel with the highest 4 bits
> > unused? In that case I think they're idiots for needlessly complicating
> > a storage format, they should just have shifted the whole thing left.
> > If they actually use only 12 bit to store, then blowing it up is a small
> > thing (and by far not as costly as the arbitrary maxval).
> 
> 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  ...


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire
-------------- 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/20070406/d9bd0de1/attachment.pgp>