[RFC] add Bayer fourccs
--- Hi. Here is my stab at assigning fourcs for Bayer pixel formats. I've used character 0xBA to identify Bayer formats, followed by the top component order and bit-depth. A 7-bit ASCII value would probably be better. Ideas/suggestions welcome. docs/nut4cc.txt | 12 ++++++++++++ 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/docs/nut4cc.txt b/docs/nut4cc.txt index e28de7b..a111a0a 100644 --- a/docs/nut4cc.txt +++ b/docs/nut4cc.txt @@ -112,6 +112,18 @@ RBA[64] Packed RGBA 16:16:16:16, 64bpp, 16R, 16G, 16B, 16A, the 2-byte value for ARB[64] Packed ARGB 16:16:16:16, 64bpp, 16A, 16R, 16G, 16B, the 2-byte value for each R/G/B component is stored as little-endian [NOT in AVI] BRA[64] Packed BGRA 16:16:16:16, 64bpp, 16B, 16G, 16R, 16A, the 2-byte value for each R/G/B component is stored as little-endian [NOT in AVI] ABR[64] Packed ABGR 16:16:16:16, 64bpp, 16A, 16B, 16G, 16R, the 2-byte value for each R/G/B component is stored as little-endian [NOT in AVI] +[0xBA]BG[8] Bayer, BGBG..(odd line), GRGR..(even line), 8-bit samples [NOT in AVI] +[0xBA]BG[16] Bayer, BGBG..(odd line), GRGR..(even line), 16-bit samples, little-endian [NOT in AVI] +[16]GB[0xBA] Bayer, BGBG..(odd line), GRGR..(even line), 16-bit samples, big-endian [NOT in AVI] +[0xBA]RG[8] Bayer, RGRG..(odd line), GBGB..(even line), 8-bit samples [NOT in AVI] +[0xBA]RG[16] Bayer, RGRG..(odd line), GBGB..(even line), 16-bit samples, little-endian [NOT in AVI] +[16]GR[0xBA] Bayer, RGRG..(odd line), GBGB..(even line), 16-bit samples, big-endian [NOT in AVI] +[0xBA]GB[8] Bayer, GBGB..(odd line), RGRG..(even line), 8-bit samples [NOT in AVI] +[0xBA]GB[16] Bayer, GBGB..(odd line), RGRG..(even line), 16-bit samples, little-endian [NOT in AVI] +[16]BG[0xBA] Bayer, GBGB..(odd line), RGRG..(even line), 16-bit samples, big-endian [NOT in AVI] +[0xBA]GR[8] Bayer, GRGR..(odd line), BGBG..(even line), 8-bit samples [NOT in AVI] +[0xBA]GR[16] Bayer, GRGR..(odd line), BGBG..(even line), 16-bit samples, little-endian [NOT in AVI] +[16]RG[0xBA] Bayer, GRGR..(odd line), BGBG..(even line), 16-bit samples, big-endian [NOT in AVI] Since many exotic planar YUVA pixel formats are not contemplated by the AVI/QuickTime FourCC lists, the following scheme is adopted for -- 1.7.4.1 -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
On Thu, Mar 31, 2011 at 12:29:01AM +1100, Peter Ross wrote:
--- Hi. Here is my stab at assigning fourcs for Bayer pixel formats.
I've used character 0xBA to identify Bayer formats, followed by the top component order and bit-depth. A 7-bit ASCII value would probably be better. Ideas/suggestions welcome.
docs/nut4cc.txt | 12 ++++++++++++ 1 files changed, 12 insertions(+), 0 deletions(-)
The patch is ok from my side if noone else has suggestions to improve it [..] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato
--- This was last discussed here http://lists.mplayerhq.hu/pipermail/nut-devel/2011-March/001795.html (and there were no further comments.) docs/nut4cc.txt | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/docs/nut4cc.txt b/docs/nut4cc.txt index 4f4898d..3e44979 100644 --- a/docs/nut4cc.txt +++ b/docs/nut4cc.txt @@ -122,6 +122,18 @@ ABR[64] Packed ABGR 16:16:16:16, 64bpp, 16A, 16B, 16G, 16R, the 2-byte value for [64]ABR Packed ABGR 16:16:16:16, 64bpp, 16A, 16B, 16G, 16R, the 2-byte value for each R/G/B component is stored as big-endian [NOT in AVI] XYZ[36] Packed XYZ 12:12:12, 48bpp, 12X, 4, 12Y, 4, 12Z, 4, the 2-byte value for each XYZ+4bit component is stored as little-endian [NOT in AVI] [36]ZYX Packed XYZ 12:12:12, 48bpp, 12X, 4, 12Y, 4, 12Z, 4, the 2-byte value for each XYZ+4bit component is stored as big-endian [NOT in AVI] +[0xBA]BG[8] Bayer, BGBG..(odd line), GRGR..(even line), 8-bit samples [NOT in AVI] +[0xBA]BG[16] Bayer, BGBG..(odd line), GRGR..(even line), 16-bit samples, little-endian [NOT in AVI] +[16]GB[0xBA] Bayer, BGBG..(odd line), GRGR..(even line), 16-bit samples, big-endian [NOT in AVI] +[0xBA]RG[8] Bayer, RGRG..(odd line), GBGB..(even line), 8-bit samples [NOT in AVI] +[0xBA]RG[16] Bayer, RGRG..(odd line), GBGB..(even line), 16-bit samples, little-endian [NOT in AVI] +[16]GR[0xBA] Bayer, RGRG..(odd line), GBGB..(even line), 16-bit samples, big-endian [NOT in AVI] +[0xBA]GB[8] Bayer, GBGB..(odd line), RGRG..(even line), 8-bit samples [NOT in AVI] +[0xBA]GB[16] Bayer, GBGB..(odd line), RGRG..(even line), 16-bit samples, little-endian [NOT in AVI] +[16]BG[0xBA] Bayer, GBGB..(odd line), RGRG..(even line), 16-bit samples, big-endian [NOT in AVI] +[0xBA]GR[8] Bayer, GRGR..(odd line), BGBG..(even line), 8-bit samples [NOT in AVI] +[0xBA]GR[16] Bayer, GRGR..(odd line), BGBG..(even line), 16-bit samples, little-endian [NOT in AVI] +[16]RG[0xBA] Bayer, GRGR..(odd line), BGBG..(even line), 16-bit samples, big-endian [NOT in AVI] Since many exotic planar YUVA pixel formats are not contemplated by the AVI/QuickTime FourCC lists, the following scheme is adopted for -- 1.8.3.2 -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
On Sun, Feb 23, 2014 at 09:19:14AM +1100, Peter Ross wrote:
--- This was last discussed here http://lists.mplayerhq.hu/pipermail/nut-devel/2011-March/001795.html (and there were no further comments.)
applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt.
participants (2)
-
Michael Niedermayer -
Peter Ross