[gst-devel] Proposed MIME types/caps for high bit-depth and float video
Josh D
joshthephysicist at gmail.com
Mon Jun 14 16:25:52 CEST 2010
Sure, didn't think of that at first since I was thinking I'd be lucky
if I got any input on this.
Bugzilla Bug 621553
https://bugzilla.gnome.org/show_bug.cgi?id=621553
On Mon, Jun 14, 2010 at 9:53 AM, Benjamin Otte <otte at redhat.com> wrote:
> Could you please file this as a feature request in Bugzilla (copy paste
> of your mail is fine)?
> It's much easier to keep track that way.
>
> Thanks in advance,
> Benjamin
>
>
> On Mon, 2010-06-14 at 09:38 -0400, Josh wrote:
>> I'm working with cameras that output high bit-depth and sometimes
>> floating point video. While some of these might seem crazy, (almost)
>> all of these will automatically be supported by the gst-opencv
>> elements, so many operations including colorspace conversion will be
>> possible.
>>
>> Below are the MIME types and caps that I've come up with, omitting the
>> common width, height, and framerate fields. I'm taking some liberty
>> with the formatting of these caps to save space, so this isn't exactly
>> how they'd appear in actual use.
>>
>> Raw 16-bit, 32-bit grayscale, signed or unsigned (use existing caps,
>> but add signed field):
>> video/x-raw-gray
>> bpp: [ 1, 32 ]
>> depth: { 8, 16, 32 }
>> endianness: BYTE_ORDER
>> signed: {TRUE, FALSE}
>>
>> Raw floating point (half, single, and double) grayscale:
>> video/x-raw-gray-float
>> bpp: { 16, 32, 64 }
>> depth: { 16, 32, 64 }
>> endianness: BYTE_ORDER
>>
>> Raw 16-bits per channel RGB(A):
>> video/x-raw-rgb16
>> bpp: { 48, 64 }
>> depth: { 48, 64 }
>> endianness: BYTE_ORDER
>> red_mask: { 255, ... }
>> green_mask: { 255, ... }
>> blue_mask: { 255, ... }
>> alpha_mask: { 255, ... }
>>
>> Raw floating point RGB(A):
>> video/x-raw-rgb-float
>> bpp: { 96, 128 }
>> depth: { 96, 128 }
>> endianness: BYTE_ORDER
>> red_mask: { ?? }
>> green_mask: { ?? }
>> blue_mask: { ?? }
>> alpha_mask: { ?? }
>>
>> For the floating point grayscale we could also create separate types
>> such as video/x-raw-gray-half, video/x-raw-gray-single (or float),
>> video/x-raw-gray-double.
>>
>> For RGB(A)16 we can't (and probably shouldn't) re-use the existing
>> video/x-raw-rgb since the masks are only 32-bits and we need at least
>> 64-bits.
>>
>> For RGB(A)F it might be crazy to think of adding half and double
>> formats here. The other big problem is we don't have a 128-bit integer
>> yet so to have masks we'd need two integers for each channel. Since
>> there aren't many (any?) using this type now we could just force them
>> to use RGB order and forget the masks entirely.
>>
>> I would appreciate any feedback. Thanks!
>> -Josh
>>
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit. See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit. See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
More information about the gstreamer-devel
mailing list