RAW Camera support (part 2)

--===============2804895706617584749==
Content-Type: multipart/alternative; boundary="000000000000404ea70582245b1d"

--000000000000404ea70582245b1d
Content-Type: text/plain; charset="UTF-8"

Raw image formats store the untouched, original sensor data, almost all
cameras use a Bayer filter to record samples in a R, G1, G2, B format.

Traditionally, the 2 green channels were averaged, and the resulting RGB
image data was further processed to be encoded with JPEG or MPEG.

In the last decade or so, raw cameras have come onto the scene that don't
do this and therefore store the image data as the four original channels,
Red, Green1, Green2, and Blue.

There's a litany of camera specific formats to address this issue, (Canon's
CR2, Nikon's NEF, RED's R3D, SilverSoft's HDRi, and Wikipedia lists dozens
of further raw formats)

in short, there's quite a bit of demand for storing 4/5 channel images.

Adobe tried fixing this problem by releasing their Digital Negative (DNG)
format, but it's not guaranteed to be lossless, and it's very complicated
to manage, and it's been ignored by the industry.

That's where PNG comes in.

I suggest we create a few additional values in the Color Type field in the
iHDR chunk to support these formats.

In my system I would assign the following values:

Color type 7 pertains to an image with RGGB channels using the same layout
as suggested by it's name; Red, Green1, Green2, Blue.

Color type 8 pertains to an image with RGGBA channels using the same layout
as suggested by it's name; Red, Green1, Green2, Blue, Alpha.

Last time this was brought up, concerns were raised about breaking
backwards compatibility and about how widely applicable this feature would
be.

I don't think it would really break anything, all color types that aren't
0, 2, 3, 4, and 6 are invalid currently, all it would take is a single case
or if else check in the source to log an error about using an unsupported
color type.

and if that's not enough, I'd be ok with adding a new chunk to store the
second green channel all on it's own that way existing software that does
erroneously try to decode color types that it wasn't built for, would still
be able to decode what it could and it would otherwise look like a
perfectly normal image.

if we go that route, we could set the RGGB color type to 10 (0xA, that way
software could just AND the color type with 6 to get the impression that
it's RGB data) and store the Red, Green1, and Blue channels in the primary
iDAT chunks and store the Green2 channel in a separate chunk

and for RGGBA we could set the color type to 14 (0xE) so when ANDed with 6
it would appear to be RGBA data, again, storing the second Green channel in
it's own chunk.

I don't think backwards compatibility is a major concern.

As for how widespread the use for this feature will be, I don't think
that's a real concern either because:

HEVC's follow up, Versatile Video Coding (due for release in 2020) calls
for supporting lossless compression, as well as "auxiliary channels for
depth and transparency".

According to https://en.wikipedia.org/wiki/Versatile_Video_Coding

--000000000000404ea70582245b1d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div di=
r=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-size:=
large"><div class=3D"gmail_default">Raw image formats store the untouched, =
original sensor data, almost all cameras use a Bayer filter to record sampl=
es in a R, G1, G2, B format.</div><div class=3D"gmail_default"><br></div><d=
iv class=3D"gmail_default">Traditionally, the 2 green channels were average=
d, and the resulting RGB image data was further processed to be encoded wit=
h JPEG or MPEG.</div><div class=3D"gmail_default"><br></div><div class=3D"g=
mail_default">In the last decade or so, raw cameras have come onto the scen=
e that don&#39;t do this and therefore store the image data as the four ori=
ginal channels, Red, Green1, Green2, and Blue.</div><div class=3D"gmail_def=
ault"><br></div><div class=3D"gmail_default">There&#39;s a litany of camera=
 specific formats to address this issue, (Canon&#39;s CR2, Nikon&#39;s NEF,=
 RED&#39;s R3D, SilverSoft&#39;s HDRi, and Wikipedia lists dozens of furthe=
r raw formats)</div><div class=3D"gmail_default"><br></div><div class=3D"gm=
ail_default">in short, there&#39;s quite a bit of demand for storing 4/5 ch=
annel images.</div><div class=3D"gmail_default"><br></div><div class=3D"gma=
il_default">Adobe tried fixing this problem by releasing their Digital Nega=
tive (DNG) format, but it&#39;s not guaranteed to be lossless, and it&#39;s=
 very complicated to manage, and it&#39;s been ignored by the industry.</di=
v><div class=3D"gmail_default"><br></div><div class=3D"gmail_default">That&=
#39;s where PNG comes in.</div><div class=3D"gmail_default"><br></div><div =
class=3D"gmail_default">I suggest we create a few additional values in the =
Color Type field in the iHDR chunk to support these formats.</div><div clas=
s=3D"gmail_default"><br></div><div class=3D"gmail_default">In my system I w=
ould assign the following values:</div><div class=3D"gmail_default"><br></d=
iv><div class=3D"gmail_default">Color type 7 pertains to an image with RGGB=
 channels using the same layout as suggested by it&#39;s name; Red, Green1,=
 Green2, Blue.</div><div class=3D"gmail_default"><br></div><div class=3D"gm=
ail_default">Color type 8 pertains to an image with RGGBA channels using th=
e same layout as suggested by it&#39;s name; Red, Green1, Green2, Blue, Alp=
ha.</div><div class=3D"gmail_default"><br></div><div class=3D"gmail_default=
">Last time this was brought up, concerns were raised about breaking backwa=
rds compatibility and about how widely applicable this feature would be.</d=
iv><div class=3D"gmail_default"><br></div><div class=3D"gmail_default">I do=
n&#39;t think it would really break anything, all color types that aren&#39=
;t 0, 2, 3, 4, and 6 are invalid currently, all it would take is a single c=
ase or if else check in the source to log an error about using an unsupport=
ed color type.</div><div class=3D"gmail_default"><br></div><div class=3D"gm=
ail_default">and if that&#39;s not enough, I&#39;d be ok with adding a new =
chunk to store the second green channel all on it&#39;s own that way existi=
ng software that does erroneously try to decode color types that it wasn&#3=
9;t built for, would still be able to decode what it could and it would oth=
erwise look like a perfectly normal image.</div><div class=3D"gmail_default=
"><br></div><div class=3D"gmail_default">if we go that route, we could set =
the RGGB color type to 10 (0xA, that way software could just AND the color =
type with 6 to get the impression that it&#39;s RGB data) and store the Red=
, Green1, and Blue channels in the primary iDAT chunks and store the Green2=
 channel in a separate chunk</div><div class=3D"gmail_default"><br></div><d=
iv class=3D"gmail_default">and for RGGBA we could set the color type to 14 =
(0xE) so when ANDed with 6 it would appear to be RGBA data, again, storing =
the second Green channel in it&#39;s own chunk.</div><div class=3D"gmail_de=
fault"><br></div><div class=3D"gmail_default">I don&#39;t think backwards c=
ompatibility is a major concern.</div><div class=3D"gmail_default"><br></di=
v><div class=3D"gmail_default">As for how widespread the use for this featu=
re will be, I don&#39;t think that&#39;s a real concern either because:</di=
v><div class=3D"gmail_default"><br></div><div class=3D"gmail_default">HEVC&=
#39;s follow up, Versatile Video Coding (due for release in 2020) calls for=
 supporting lossless compression, as well as &quot;auxiliary channels for d=
epth and transparency&quot;.</div><div class=3D"gmail_default"><br></div><d=
iv class=3D"gmail_default">According to <a href=3D"https://en.wikipedia.org=
/wiki/Versatile_Video_Coding">https://en.wikipedia.org/wiki/Versatile_Video=
_Coding</a></div></div></div></div></div></div></div></div>

--000000000000404ea70582245b1d--


--===============2804895706617584749==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============2804895706617584749==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
png-mng-misc mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

--===============2804895706617584749==--