[theora-dev] Higher quality video - supporting greater than 8 bit color depth

[KarasevAS at aol.com]

Hi,

I was wondering what are this forum's collective thoughts on the best way to 
support video color fidelity greater than what we have today.

I am not a video developer myself. I edit video. A type of problems I come 
across fairly often, have to do with the limited color depth of the digital 
video medium. They often manifest themselves as "cartoonish" areas of adjacent 
flat colors observable in a low-noise footage of a smooth-colored subject such as 
sky or a non-textured wall. And trouble is, ANY footage becomes subject to 
color depth limitations whenever it is needed to adjust its gamma level or 
affect its historgam in other ways.

While most digital video acquisition methods available today (save for 
film-to-video rank transfers) still yield the low bit rate file, the evolution 
clearly must be towards the greater fidelity, similar to what happened in 
film/flatbed scanners (that are now 16bit/channel color depth) and digital cameras 
(most prosumer models 12bit/color depoth).

Even if source AND finished product are 8 bit/channel, there's still a huge 
benefit in having the processing be in the higher bit depth domain, forcleaner 
support of complex filter trains including things like PAL/NTSC conversion, 
tone curve / gamma adjustment, video noise reduction, etc.

As a user, I would like to see the following things in the next high quality 
video format:

1. Ability to support greater than 8 bits per RGB or YPrPb channel color 
depth, either arbitrarily defined (preferred) or as a selection of "good" values 
or "green or luminance"/other color depth pairs, to have say 12 bit Y and 8 bit 
Pr, Pb. You be the judges what would be the good values to support; I'd sure 
love to see e.g. 8, 12, 16, 24 bits per channel.

2. Ability to specify the "authoring" gamma value and color temperature in 
the video header. Thus the video would "know" the settings at which it was 
authored. On the other hand, the playback device could know its own gamma and color 
temp. Thus when playing a given video file, the playback device can make 
adjustments (through either adjusting itself, or applying the proper filtration to 
the video), so the video looks the way it was intended.

3. Robust internal support for interleaved subtitles, so each word is tied to 
a section of a video. Header could include "recommended" font / color / text 
field size & position within frame / text alignment within field / 
modification (bold/italic/underline/outline/strikethrough) / transparency / merging type 
(direct/add/subtract/multiply). These should be midstream-adjustable so 
sections of text could appear with different settings. The player chould be able to 
override some or all of these settings. When intercutting multiple files, 
would be great if subtitles could be cleanly sliced along with corresponding video.

4. Speaking of subtitles, would be good to have multiple streams of ... 
EVERYTHING! I mean, multiple angles of video; multiple audio tracks; multiple 
subtitle tracks.

5. Would be very forward-looking, I think, to support ability to qualify the 
video components in the video header (i.e. in RGB terms, "what kind of green 
is this, really"). This means defining filter's median wave length and breadth. 
Something even more elegant to scal eto scientific applications perhaps would 
be, for each channel, specify the filter curve and response curve. ... and 
support potentially more (or less) than three channels such as our plain (R G B 
or Y Pr Pb). There may be applications incluing IR or UV channels, or simply 
additional channels at specific other wavelengths. It would be up to the player 
to interpret these in a user-defined way, by ignoring or mixing them in as 
specific colors or applying threshold or logical operations.

Regards,

Alexander

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'theora-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.