Discussion:
[Oiio-dev] Error: jpeg does not support 6-channel images
Justin Israel
2015-02-05 23:56:12 UTC
Permalink
I was curious about some behavior in oiiotool v1.4.14, when dealing with a
source image that has 6 channels, and converting it to a jpeg.

oiiotool source.exr -o out.jpg
# oiiotool ERROR: jpeg does not support 6-channel images

I presume this bubbles up from libjpeg. Fair enough. But I know that the
mantra of OpenImageIO has usually been to try and do the right default
action, and attempt to avoid failures if possible. That being said, do you
think it would be more in line with that philosophy if the jpeg plugin
ensured it would only use 1, 3, or 4 of the first available channels, if
not using an explicit list already? That way you would still get a jpg
output, even if you passed it a 6 channel image, but could still explicitly
give is a channel list if you knew them up front.

Currently I have to inspect the source image first before calling oiiotool,
and ensure that I pass it a reduced channel list if needed.

Justin
Larry Gritz
2015-02-08 00:35:31 UTC
Permalink
On one hand, we don't want to do operations that are not supported in the output format, thereby resulting in significant loss of data. On the other hand, we can't be too trigger-happy with the errors, or it would be impossible to get anything done. So when we encounter a request to do something not possible with a given format, we try to ask "is there a particular thing that the human almost certainly meant when they made this impossible request?"

For example OpenEXR's least accurate pixel data type ('half') has more precision and range than JPEG's most accurate type, so there will be data loss, but we don't want to make every operation that starts with exr and ends with jpg to be an error. So we just convert any input pixel data type to UINT8 when outputting a JPEG. For most ordinary images, the data is LDR and our eyes are mostly satisfied with 8 bits in an sRGB-mapped intensity response, so this conversion will probably be fine. ("If you wanted to preserve the HDR data, you should not have output to JPEG, dummy.")

But what if we are asked to save more channels than a file format can accommodate? If you just drop the channels, you're not just reducing precision, you are losing whole sections of the original data. So at present, we make it a hard error.

As a special case (and maybe precedent?), we do just silently drop an alpha channel when saving JPEG. JPEG cannot accommodate alpha, but it's so common for an input to have alpha, it was painful for it to be an error when saving to JPEG. It seemed that the obvious human interpretation was "I'm using JPEG because this is final output for the web or for my mom to view, the alpha that was valuable for intermediate computations won't be needed for those purposes, so drop it."

I think that at the low level of ImageInput, open() should fail if you ask for more channels than can be supported in any obvious way. But for oiiotool in particular, I think we can make more "best guess" heuristics.

I'm certainly open to this being debated!

When oiiotool is outputting to a format that doesn't support as many channels as the image appears to have, do you think we should just silently output the first 3 channels and drop the rest? Should this be the one and only behavior? Or should there be a "strict/lax" option that determines whether this (and potentially other conversions) are an error or silently do whatever is necessary to complete the action somehow? If so, should the default be strict or lax?

-- lg


(Note for the pedants in the crowd: most of the places I wrote "JPEG", I'm not really talking about the JPEG compression, but rather the JFIF file format.)
I was curious about some behavior in oiiotool v1.4.14, when dealing with a source image that has 6 channels, and converting it to a jpeg.
oiiotool source.exr -o out.jpg
# oiiotool ERROR: jpeg does not support 6-channel images
I presume this bubbles up from libjpeg. Fair enough. But I know that the mantra of OpenImageIO has usually been to try and do the right default action, and attempt to avoid failures if possible. That being said, do you think it would be more in line with that philosophy if the jpeg plugin ensured it would only use 1, 3, or 4 of the first available channels, if not using an explicit list already? That way you would still get a jpg output, even if you passed it a 6 channel image, but could still explicitly give is a channel list if you knew them up front.
Currently I have to inspect the source image first before calling oiiotool, and ensure that I pass it a reduced channel list if needed.
Justin
--
Larry Gritz
***@larrygritz.com
Jono Gibbs
2015-02-08 01:10:59 UTC
Permalink
If the input file format had 3 obvious r g b channels and then 3 which were not related to color (z, alpha, obj-id) then it seems like keeping the r g b channels when going to JPEG is in the spirit of "do the obvious thing".

If it's a 6-channel color thing then it's unlikely any 3 channels make sense.

Does the input format have no information like channel names?

--jono --mobile--
Post by Larry Gritz
On one hand, we don't want to do operations that are not supported in the output format, thereby resulting in significant loss of data. On the other hand, we can't be too trigger-happy with the errors, or it would be impossible to get anything done. So when we encounter a request to do something not possible with a given format, we try to ask "is there a particular thing that the human almost certainly meant when they made this impossible request?"
For example OpenEXR's least accurate pixel data type ('half') has more precision and range than JPEG's most accurate type, so there will be data loss, but we don't want to make every operation that starts with exr and ends with jpg to be an error. So we just convert any input pixel data type to UINT8 when outputting a JPEG. For most ordinary images, the data is LDR and our eyes are mostly satisfied with 8 bits in an sRGB-mapped intensity response, so this conversion will probably be fine. ("If you wanted to preserve the HDR data, you should not have output to JPEG, dummy.")
But what if we are asked to save more channels than a file format can accommodate? If you just drop the channels, you're not just reducing precision, you are losing whole sections of the original data. So at present, we make it a hard error.
As a special case (and maybe precedent?), we do just silently drop an alpha channel when saving JPEG. JPEG cannot accommodate alpha, but it's so common for an input to have alpha, it was painful for it to be an error when saving to JPEG. It seemed that the obvious human interpretation was "I'm using JPEG because this is final output for the web or for my mom to view, the alpha that was valuable for intermediate computations won't be needed for those purposes, so drop it."
I think that at the low level of ImageInput, open() should fail if you ask for more channels than can be supported in any obvious way. But for oiiotool in particular, I think we can make more "best guess" heuristics.
I'm certainly open to this being debated!
When oiiotool is outputting to a format that doesn't support as many channels as the image appears to have, do you think we should just silently output the first 3 channels and drop the rest? Should this be the one and only behavior? Or should there be a "strict/lax" option that determines whether this (and potentially other conversions) are an error or silently do whatever is necessary to complete the action somehow? If so, should the default be strict or lax?
-- lg
(Note for the pedants in the crowd: most of the places I wrote "JPEG", I'm not really talking about the JPEG compression, but rather the JFIF file format.)
I was curious about some behavior in oiiotool v1.4.14, when dealing with a source image that has 6 channels, and converting it to a jpeg.
oiiotool source.exr -o out.jpg
# oiiotool ERROR: jpeg does not support 6-channel images
I presume this bubbles up from libjpeg. Fair enough. But I know that the mantra of OpenImageIO has usually been to try and do the right default action, and attempt to avoid failures if possible. That being said, do you think it would be more in line with that philosophy if the jpeg plugin ensured it would only use 1, 3, or 4 of the first available channels, if not using an explicit list already? That way you would still get a jpg output, even if you passed it a 6 channel image, but could still explicitly give is a channel list if you knew them up front.
Currently I have to inspect the source image first before calling oiiotool, and ensure that I pass it a reduced channel list if needed.
Justin
--
Larry Gritz
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
Justin Israel
2015-02-08 01:20:35 UTC
Permalink
Well in my case, one specific example of an input image is a non-subimage
style stereo, with [RGB] and right.[RGB] labels. But oiiotool obviously
should not have any knowledge of special labels, and the goal was to not
have to pre-inspect the source images before converting to jpeg.

Thanks Larry for breaking down the categories of when oiio wants to make
best default choices, vs erroring out. It does sound like a really similar
situation to the fact that it does automatically throw away the alpha
channel. If I have a source image with extra channels, and no channels have
specifically been selected, it would seem that choosing RGB by default
would be what the user most likely wants. If I knew I wanted specialized
channels, I would definitely select them. Otherwise, it should probably
complain about the alpha channel just as it does complain about 6 channels
passing through.
Post by Jono Gibbs
If the input file format had 3 obvious r g b channels and then 3 which
were not related to color (z, alpha, obj-id) then it seems like keeping the
r g b channels when going to JPEG is in the spirit of "do the obvious
thing".
If it's a 6-channel color thing then it's unlikely any 3 channels make sense.
Does the input format have no information like channel names?
--jono --mobile--
Post by Larry Gritz
On one hand, we don't want to do operations that are not supported in
the output format, thereby resulting in significant loss of data. On the
other hand, we can't be too trigger-happy with the errors, or it would be
impossible to get anything done. So when we encounter a request to do
something not possible with a given format, we try to ask "is there a
particular thing that the human almost certainly meant when they made this
impossible request?"
Post by Larry Gritz
For example OpenEXR's least accurate pixel data type ('half') has more
precision and range than JPEG's most accurate type, so there will be data
loss, but we don't want to make every operation that starts with exr and
ends with jpg to be an error. So we just convert any input pixel data type
to UINT8 when outputting a JPEG. For most ordinary images, the data is LDR
and our eyes are mostly satisfied with 8 bits in an sRGB-mapped intensity
response, so this conversion will probably be fine. ("If you wanted to
preserve the HDR data, you should not have output to JPEG, dummy.")
Post by Larry Gritz
But what if we are asked to save more channels than a file format can
accommodate? If you just drop the channels, you're not just reducing
precision, you are losing whole sections of the original data. So at
present, we make it a hard error.
Post by Larry Gritz
As a special case (and maybe precedent?), we do just silently drop an
alpha channel when saving JPEG. JPEG cannot accommodate alpha, but it's so
common for an input to have alpha, it was painful for it to be an error
when saving to JPEG. It seemed that the obvious human interpretation was
"I'm using JPEG because this is final output for the web or for my mom to
view, the alpha that was valuable for intermediate computations won't be
needed for those purposes, so drop it."
Post by Larry Gritz
I think that at the low level of ImageInput, open() should fail if you
ask for more channels than can be supported in any obvious way. But for
oiiotool in particular, I think we can make more "best guess" heuristics.
Post by Larry Gritz
I'm certainly open to this being debated!
When oiiotool is outputting to a format that doesn't support as many
channels as the image appears to have, do you think we should just silently
output the first 3 channels and drop the rest? Should this be the one and
only behavior? Or should there be a "strict/lax" option that determines
whether this (and potentially other conversions) are an error or silently
do whatever is necessary to complete the action somehow? If so, should the
default be strict or lax?
Post by Larry Gritz
-- lg
(Note for the pedants in the crowd: most of the places I wrote "JPEG",
I'm not really talking about the JPEG compression, but rather the JFIF file
format.)
Post by Larry Gritz
Post by Justin Israel
I was curious about some behavior in oiiotool v1.4.14, when dealing
with a source image that has 6 channels, and converting it to a jpeg.
Post by Larry Gritz
Post by Justin Israel
oiiotool source.exr -o out.jpg
# oiiotool ERROR: jpeg does not support 6-channel images
I presume this bubbles up from libjpeg. Fair enough. But I know that
the mantra of OpenImageIO has usually been to try and do the right default
action, and attempt to avoid failures if possible. That being said, do you
think it would be more in line with that philosophy if the jpeg plugin
ensured it would only use 1, 3, or 4 of the first available channels, if
not using an explicit list already? That way you would still get a jpg
output, even if you passed it a 6 channel image, but could still explicitly
give is a channel list if you knew them up front.
Post by Larry Gritz
Post by Justin Israel
Currently I have to inspect the source image first before calling
oiiotool, and ensure that I pass it a reduced channel list if needed.
Post by Larry Gritz
Post by Justin Israel
Justin
--
Larry Gritz
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
Larry Gritz
2015-02-08 01:36:21 UTC
Permalink
OK, so how about this proposed heuristic for oiiotool:

If the output format doesn't support as many channels as the input image, then it will perform the equivalent of "--ch R,G,B" (or "R,G,B,A", if the format does support an alpha channel) before saving. If the input doesn't contain (somewhere in it) channels named R, G, and B, then it's an error.

Or should we just ignore the issue of specific channel names and write the first 3 (or 4) channels and call it a day?

-- lg


PS. WTF, Jono, don't you have someplace more important to be tonight?
Well in my case, one specific example of an input image is a non-subimage style stereo, with [RGB] and right.[RGB] labels. But oiiotool obviously should not have any knowledge of special labels, and the goal was to not have to pre-inspect the source images before converting to jpeg.
Thanks Larry for breaking down the categories of when oiio wants to make best default choices, vs erroring out. It does sound like a really similar situation to the fact that it does automatically throw away the alpha channel. If I have a source image with extra channels, and no channels have specifically been selected, it would seem that choosing RGB by default would be what the user most likely wants. If I knew I wanted specialized channels, I would definitely select them. Otherwise, it should probably complain about the alpha channel just as it does complain about 6 channels passing through.
If the input file format had 3 obvious r g b channels and then 3 which were not related to color (z, alpha, obj-id) then it seems like keeping the r g b channels when going to JPEG is in the spirit of "do the obvious thing".
If it's a 6-channel color thing then it's unlikely any 3 channels make sense.
Does the input format have no information like channel names?
--jono --mobile--
Post by Larry Gritz
On one hand, we don't want to do operations that are not supported in the output format, thereby resulting in significant loss of data. On the other hand, we can't be too trigger-happy with the errors, or it would be impossible to get anything done. So when we encounter a request to do something not possible with a given format, we try to ask "is there a particular thing that the human almost certainly meant when they made this impossible request?"
For example OpenEXR's least accurate pixel data type ('half') has more precision and range than JPEG's most accurate type, so there will be data loss, but we don't want to make every operation that starts with exr and ends with jpg to be an error. So we just convert any input pixel data type to UINT8 when outputting a JPEG. For most ordinary images, the data is LDR and our eyes are mostly satisfied with 8 bits in an sRGB-mapped intensity response, so this conversion will probably be fine. ("If you wanted to preserve the HDR data, you should not have output to JPEG, dummy.")
But what if we are asked to save more channels than a file format can accommodate? If you just drop the channels, you're not just reducing precision, you are losing whole sections of the original data. So at present, we make it a hard error.
As a special case (and maybe precedent?), we do just silently drop an alpha channel when saving JPEG. JPEG cannot accommodate alpha, but it's so common for an input to have alpha, it was painful for it to be an error when saving to JPEG. It seemed that the obvious human interpretation was "I'm using JPEG because this is final output for the web or for my mom to view, the alpha that was valuable for intermediate computations won't be needed for those purposes, so drop it."
I think that at the low level of ImageInput, open() should fail if you ask for more channels than can be supported in any obvious way. But for oiiotool in particular, I think we can make more "best guess" heuristics.
I'm certainly open to this being debated!
When oiiotool is outputting to a format that doesn't support as many channels as the image appears to have, do you think we should just silently output the first 3 channels and drop the rest? Should this be the one and only behavior? Or should there be a "strict/lax" option that determines whether this (and potentially other conversions) are an error or silently do whatever is necessary to complete the action somehow? If so, should the default be strict or lax?
-- lg
(Note for the pedants in the crowd: most of the places I wrote "JPEG", I'm not really talking about the JPEG compression, but rather the JFIF file format.)
I was curious about some behavior in oiiotool v1.4.14, when dealing with a source image that has 6 channels, and converting it to a jpeg.
oiiotool source.exr -o out.jpg
# oiiotool ERROR: jpeg does not support 6-channel images
I presume this bubbles up from libjpeg. Fair enough. But I know that the mantra of OpenImageIO has usually been to try and do the right default action, and attempt to avoid failures if possible. That being said, do you think it would be more in line with that philosophy if the jpeg plugin ensured it would only use 1, 3, or 4 of the first available channels, if not using an explicit list already? That way you would still get a jpg output, even if you passed it a 6 channel image, but could still explicitly give is a channel list if you knew them up front.
Currently I have to inspect the source image first before calling oiiotool, and ensure that I pass it a reduced channel list if needed.
Justin
--
Larry Gritz
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
***@larrygritz.com
Justin Israel
2015-02-08 02:21:37 UTC
Permalink
Personally I would be happy with selecting the first 3 or 4 channels (or
the number supported by the output format) under that given circumstance,
but if we want to go the extra mile and do some checking, maybe that would
be a plus?

Maybe this is a dumb question, but what do you think the average image
viewer does when displaying images with arbitrary channels? Do they look
for R,G,B labeled channels, or maybe load the first N channels?
Post by Larry Gritz
If the output format doesn't support as many channels as the input image,
then it will perform the equivalent of "--ch R,G,B" (or "R,G,B,A", if the
format does support an alpha channel) before saving. If the input doesn't
contain (somewhere in it) channels named R, G, and B, then it's an error.
Or should we just ignore the issue of specific channel names and write the
first 3 (or 4) channels and call it a day?
-- lg
PS. WTF, Jono, don't you have someplace more important to be tonight?
Well in my case, one specific example of an input image is a non-subimage
style stereo, with [RGB] and right.[RGB] labels. But oiiotool obviously
should not have any knowledge of special labels, and the goal was to not
have to pre-inspect the source images before converting to jpeg.
Thanks Larry for breaking down the categories of when oiio wants to make
best default choices, vs erroring out. It does sound like a really similar
situation to the fact that it does automatically throw away the alpha
channel. If I have a source image with extra channels, and no channels have
specifically been selected, it would seem that choosing RGB by default
would be what the user most likely wants. If I knew I wanted specialized
channels, I would definitely select them. Otherwise, it should probably
complain about the alpha channel just as it does complain about 6 channels
passing through.
Post by Jono Gibbs
If the input file format had 3 obvious r g b channels and then 3 which
were not related to color (z, alpha, obj-id) then it seems like keeping the
r g b channels when going to JPEG is in the spirit of "do the obvious
thing".
If it's a 6-channel color thing then it's unlikely any 3 channels make sense.
Does the input format have no information like channel names?
--jono --mobile--
Post by Larry Gritz
On one hand, we don't want to do operations that are not supported in
the output format, thereby resulting in significant loss of data. On the
other hand, we can't be too trigger-happy with the errors, or it would be
impossible to get anything done. So when we encounter a request to do
something not possible with a given format, we try to ask "is there a
particular thing that the human almost certainly meant when they made this
impossible request?"
Post by Larry Gritz
For example OpenEXR's least accurate pixel data type ('half') has more
precision and range than JPEG's most accurate type, so there will be data
loss, but we don't want to make every operation that starts with exr and
ends with jpg to be an error. So we just convert any input pixel data type
to UINT8 when outputting a JPEG. For most ordinary images, the data is LDR
and our eyes are mostly satisfied with 8 bits in an sRGB-mapped intensity
response, so this conversion will probably be fine. ("If you wanted to
preserve the HDR data, you should not have output to JPEG, dummy.")
Post by Larry Gritz
But what if we are asked to save more channels than a file format can
accommodate? If you just drop the channels, you're not just reducing
precision, you are losing whole sections of the original data. So at
present, we make it a hard error.
Post by Larry Gritz
As a special case (and maybe precedent?), we do just silently drop an
alpha channel when saving JPEG. JPEG cannot accommodate alpha, but it's so
common for an input to have alpha, it was painful for it to be an error
when saving to JPEG. It seemed that the obvious human interpretation was
"I'm using JPEG because this is final output for the web or for my mom to
view, the alpha that was valuable for intermediate computations won't be
needed for those purposes, so drop it."
Post by Larry Gritz
I think that at the low level of ImageInput, open() should fail if you
ask for more channels than can be supported in any obvious way. But for
oiiotool in particular, I think we can make more "best guess" heuristics.
Post by Larry Gritz
I'm certainly open to this being debated!
When oiiotool is outputting to a format that doesn't support as many
channels as the image appears to have, do you think we should just silently
output the first 3 channels and drop the rest? Should this be the one and
only behavior? Or should there be a "strict/lax" option that determines
whether this (and potentially other conversions) are an error or silently
do whatever is necessary to complete the action somehow? If so, should the
default be strict or lax?
Post by Larry Gritz
-- lg
(Note for the pedants in the crowd: most of the places I wrote "JPEG",
I'm not really talking about the JPEG compression, but rather the JFIF file
format.)
Post by Larry Gritz
Post by Justin Israel
I was curious about some behavior in oiiotool v1.4.14, when dealing
with a source image that has 6 channels, and converting it to a jpeg.
Post by Larry Gritz
Post by Justin Israel
oiiotool source.exr -o out.jpg
# oiiotool ERROR: jpeg does not support 6-channel images
I presume this bubbles up from libjpeg. Fair enough. But I know that
the mantra of OpenImageIO has usually been to try and do the right default
action, and attempt to avoid failures if possible. That being said, do you
think it would be more in line with that philosophy if the jpeg plugin
ensured it would only use 1, 3, or 4 of the first available channels, if
not using an explicit list already? That way you would still get a jpg
output, even if you passed it a 6 channel image, but could still explicitly
give is a channel list if you knew them up front.
Post by Larry Gritz
Post by Justin Israel
Currently I have to inspect the source image first before calling
oiiotool, and ensure that I pass it a reduced channel list if needed.
Post by Larry Gritz
Post by Justin Israel
Justin
--
Larry Gritz
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
Larry Gritz
2015-02-08 06:05:34 UTC
Permalink
Personally I would be happy with selecting the first 3 or 4 channels (or the number supported by the output format) under that given circumstance, but if we want to go the extra mile and do some checking, maybe that would be a plus?
On one hand, it seems smarter to try to pull out the R, G, B among them, regardless of the order.

But that should be weighed against the distinct possibility that the channels are not named simply, or are even mis-labeled.

I'll think about this a bit. Maybe an even more convoluted approach is best: If the channel names contain is an identifiable R, G, B, use those (regardless of original order), otherwise use the first 3 channels and hope for the best?

I think most of the time these should be equivalent, because the OIIO guidelines say that a format reader should reshuffle as necessary to make R,G,B,A always be the first 4 channels, regardless of their appearance in the file.
Maybe this is a dumb question, but what do you think the average image viewer does when displaying images with arbitrary channels? Do they look for R,G,B labeled channels, or maybe load the first N channels?
Ha! I think the *average* viewer either crashes, refuses to load the image at all, or loads it but totally botches the memory layout and thus mis-draws the image, like this:

image: R G B A X Y | R G B A X Y |

display: | | | |

(I hope that comes out right, it takes a mono font on those lines to make the spacing right.)
If the output format doesn't support as many channels as the input image, then it will perform the equivalent of "--ch R,G,B" (or "R,G,B,A", if the format does support an alpha channel) before saving. If the input doesn't contain (somewhere in it) channels named R, G, and B, then it's an error.
Or should we just ignore the issue of specific channel names and write the first 3 (or 4) channels and call it a day?
-- lg
PS. WTF, Jono, don't you have someplace more important to be tonight?
Well in my case, one specific example of an input image is a non-subimage style stereo, with [RGB] and right.[RGB] labels. But oiiotool obviously should not have any knowledge of special labels, and the goal was to not have to pre-inspect the source images before converting to jpeg.
Thanks Larry for breaking down the categories of when oiio wants to make best default choices, vs erroring out. It does sound like a really similar situation to the fact that it does automatically throw away the alpha channel. If I have a source image with extra channels, and no channels have specifically been selected, it would seem that choosing RGB by default would be what the user most likely wants. If I knew I wanted specialized channels, I would definitely select them. Otherwise, it should probably complain about the alpha channel just as it does complain about 6 channels passing through.
If the input file format had 3 obvious r g b channels and then 3 which were not related to color (z, alpha, obj-id) then it seems like keeping the r g b channels when going to JPEG is in the spirit of "do the obvious thing".
If it's a 6-channel color thing then it's unlikely any 3 channels make sense.
Does the input format have no information like channel names?
--jono --mobile--
Post by Larry Gritz
On one hand, we don't want to do operations that are not supported in the output format, thereby resulting in significant loss of data. On the other hand, we can't be too trigger-happy with the errors, or it would be impossible to get anything done. So when we encounter a request to do something not possible with a given format, we try to ask "is there a particular thing that the human almost certainly meant when they made this impossible request?"
For example OpenEXR's least accurate pixel data type ('half') has more precision and range than JPEG's most accurate type, so there will be data loss, but we don't want to make every operation that starts with exr and ends with jpg to be an error. So we just convert any input pixel data type to UINT8 when outputting a JPEG. For most ordinary images, the data is LDR and our eyes are mostly satisfied with 8 bits in an sRGB-mapped intensity response, so this conversion will probably be fine. ("If you wanted to preserve the HDR data, you should not have output to JPEG, dummy.")
But what if we are asked to save more channels than a file format can accommodate? If you just drop the channels, you're not just reducing precision, you are losing whole sections of the original data. So at present, we make it a hard error.
As a special case (and maybe precedent?), we do just silently drop an alpha channel when saving JPEG. JPEG cannot accommodate alpha, but it's so common for an input to have alpha, it was painful for it to be an error when saving to JPEG. It seemed that the obvious human interpretation was "I'm using JPEG because this is final output for the web or for my mom to view, the alpha that was valuable for intermediate computations won't be needed for those purposes, so drop it."
I think that at the low level of ImageInput, open() should fail if you ask for more channels than can be supported in any obvious way. But for oiiotool in particular, I think we can make more "best guess" heuristics.
I'm certainly open to this being debated!
When oiiotool is outputting to a format that doesn't support as many channels as the image appears to have, do you think we should just silently output the first 3 channels and drop the rest? Should this be the one and only behavior? Or should there be a "strict/lax" option that determines whether this (and potentially other conversions) are an error or silently do whatever is necessary to complete the action somehow? If so, should the default be strict or lax?
-- lg
(Note for the pedants in the crowd: most of the places I wrote "JPEG", I'm not really talking about the JPEG compression, but rather the JFIF file format.)
I was curious about some behavior in oiiotool v1.4.14, when dealing with a source image that has 6 channels, and converting it to a jpeg.
oiiotool source.exr -o out.jpg
# oiiotool ERROR: jpeg does not support 6-channel images
I presume this bubbles up from libjpeg. Fair enough. But I know that the mantra of OpenImageIO has usually been to try and do the right default action, and attempt to avoid failures if possible. That being said, do you think it would be more in line with that philosophy if the jpeg plugin ensured it would only use 1, 3, or 4 of the first available channels, if not using an explicit list already? That way you would still get a jpg output, even if you passed it a 6 channel image, but could still explicitly give is a channel list if you knew them up front.
Currently I have to inspect the source image first before calling oiiotool, and ensure that I pass it a reduced channel list if needed.
Justin
--
Larry Gritz
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
***@larrygritz.com
Justin Israel
2015-02-08 20:00:19 UTC
Permalink
Post by Justin Israel
Personally I would be happy with selecting the first 3 or 4 channels (or
the number supported by the output format) under that given circumstance,
but if we want to go the extra mile and do some checking, maybe that would
be a plus?
On one hand, it seems smarter to try to pull out the R, G, B among them,
regardless of the order.
But that should be weighed against the distinct possibility that the
channels are not named simply, or are even mis-labeled.
I'll think about this a bit. Maybe an even more convoluted approach is
best: If the channel names contain is an identifiable R, G, B, use those
(regardless of original order), otherwise use the first 3 channels and hope
for the best?
I think most of the time these should be equivalent, because the OIIO
guidelines say that a format reader should reshuffle as necessary to make
R,G,B,A always be the first 4 channels, regardless of their appearance in
the file.
Actually, your mixture of the two approaches would probably be best. Funny
thing... just this morning I got bit by assuming the first 3 channels would
be ok... Turned out it was an exr with 4 channels:

B
matte
G
R

Go figure.
Post by Justin Israel
Maybe this is a dumb question, but what do you think the average image
viewer does when displaying images with arbitrary channels? Do they look
for R,G,B labeled channels, or maybe load the first N channels?
Ha! I think the *average* viewer either crashes, refuses to load the image
at all, or loads it but totally botches the memory layout and thus
image: R G B A X Y | R G B A X Y |
display: | | | |
(I hope that comes out right, it takes a mono font on those lines to make
the spacing right.)
Hah. Well I meant viewers that can actually display the formats ;-)
Post by Justin Israel
Post by Larry Gritz
If the output format doesn't support as many channels as the input image,
then it will perform the equivalent of "--ch R,G,B" (or "R,G,B,A", if the
format does support an alpha channel) before saving. If the input doesn't
contain (somewhere in it) channels named R, G, and B, then it's an error.
Or should we just ignore the issue of specific channel names and write
the first 3 (or 4) channels and call it a day?
-- lg
PS. WTF, Jono, don't you have someplace more important to be tonight?
Well in my case, one specific example of an input image is a non-subimage
style stereo, with [RGB] and right.[RGB] labels. But oiiotool obviously
should not have any knowledge of special labels, and the goal was to not
have to pre-inspect the source images before converting to jpeg.
Thanks Larry for breaking down the categories of when oiio wants to make
best default choices, vs erroring out. It does sound like a really similar
situation to the fact that it does automatically throw away the alpha
channel. If I have a source image with extra channels, and no channels have
specifically been selected, it would seem that choosing RGB by default
would be what the user most likely wants. If I knew I wanted specialized
channels, I would definitely select them. Otherwise, it should probably
complain about the alpha channel just as it does complain about 6 channels
passing through.
Post by Jono Gibbs
If the input file format had 3 obvious r g b channels and then 3 which
were not related to color (z, alpha, obj-id) then it seems like keeping the
r g b channels when going to JPEG is in the spirit of "do the obvious
thing".
If it's a 6-channel color thing then it's unlikely any 3 channels make sense.
Does the input format have no information like channel names?
--jono --mobile--
Post by Larry Gritz
On one hand, we don't want to do operations that are not supported in
the output format, thereby resulting in significant loss of data. On the
other hand, we can't be too trigger-happy with the errors, or it would be
impossible to get anything done. So when we encounter a request to do
something not possible with a given format, we try to ask "is there a
particular thing that the human almost certainly meant when they made this
impossible request?"
Post by Larry Gritz
For example OpenEXR's least accurate pixel data type ('half') has more
precision and range than JPEG's most accurate type, so there will be data
loss, but we don't want to make every operation that starts with exr and
ends with jpg to be an error. So we just convert any input pixel data type
to UINT8 when outputting a JPEG. For most ordinary images, the data is LDR
and our eyes are mostly satisfied with 8 bits in an sRGB-mapped intensity
response, so this conversion will probably be fine. ("If you wanted to
preserve the HDR data, you should not have output to JPEG, dummy.")
Post by Larry Gritz
But what if we are asked to save more channels than a file format can
accommodate? If you just drop the channels, you're not just reducing
precision, you are losing whole sections of the original data. So at
present, we make it a hard error.
Post by Larry Gritz
As a special case (and maybe precedent?), we do just silently drop an
alpha channel when saving JPEG. JPEG cannot accommodate alpha, but it's so
common for an input to have alpha, it was painful for it to be an error
when saving to JPEG. It seemed that the obvious human interpretation was
"I'm using JPEG because this is final output for the web or for my mom to
view, the alpha that was valuable for intermediate computations won't be
needed for those purposes, so drop it."
Post by Larry Gritz
I think that at the low level of ImageInput, open() should fail if you
ask for more channels than can be supported in any obvious way. But for
oiiotool in particular, I think we can make more "best guess" heuristics.
Post by Larry Gritz
I'm certainly open to this being debated!
When oiiotool is outputting to a format that doesn't support as many
channels as the image appears to have, do you think we should just silently
output the first 3 channels and drop the rest? Should this be the one and
only behavior? Or should there be a "strict/lax" option that determines
whether this (and potentially other conversions) are an error or silently
do whatever is necessary to complete the action somehow? If so, should the
default be strict or lax?
Post by Larry Gritz
-- lg
(Note for the pedants in the crowd: most of the places I wrote "JPEG",
I'm not really talking about the JPEG compression, but rather the JFIF file
format.)
Post by Larry Gritz
Post by Justin Israel
I was curious about some behavior in oiiotool v1.4.14, when dealing
with a source image that has 6 channels, and converting it to a jpeg.
Post by Larry Gritz
Post by Justin Israel
oiiotool source.exr -o out.jpg
# oiiotool ERROR: jpeg does not support 6-channel images
I presume this bubbles up from libjpeg. Fair enough. But I know that
the mantra of OpenImageIO has usually been to try and do the right default
action, and attempt to avoid failures if possible. That being said, do you
think it would be more in line with that philosophy if the jpeg plugin
ensured it would only use 1, 3, or 4 of the first available channels, if
not using an explicit list already? That way you would still get a jpg
output, even if you passed it a 6 channel image, but could still explicitly
give is a channel list if you knew them up front.
Post by Larry Gritz
Post by Justin Israel
Currently I have to inspect the source image first before calling
oiiotool, and ensure that I pass it a reduced channel list if needed.
Post by Larry Gritz
Post by Justin Israel
Justin
--
Larry Gritz
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
Larry Gritz
2015-02-10 20:37:15 UTC
Permalink
Justin, how about this: https://github.com/OpenImageIO/oiio/pull/1058
Post by Larry Gritz
Personally I would be happy with selecting the first 3 or 4 channels (or the number supported by the output format) under that given circumstance, but if we want to go the extra mile and do some checking, maybe that would be a plus?
On one hand, it seems smarter to try to pull out the R, G, B among them, regardless of the order.
But that should be weighed against the distinct possibility that the channels are not named simply, or are even mis-labeled.
I'll think about this a bit. Maybe an even more convoluted approach is best: If the channel names contain is an identifiable R, G, B, use those (regardless of original order), otherwise use the first 3 channels and hope for the best?
I think most of the time these should be equivalent, because the OIIO guidelines say that a format reader should reshuffle as necessary to make R,G,B,A always be the first 4 channels, regardless of their appearance in the file.
B
matte
G
R
Go figure.
Maybe this is a dumb question, but what do you think the average image viewer does when displaying images with arbitrary channels? Do they look for R,G,B labeled channels, or maybe load the first N channels?
image: R G B A X Y | R G B A X Y |
display: | | | |
(I hope that comes out right, it takes a mono font on those lines to make the spacing right.)
Hah. Well I meant viewers that can actually display the formats ;-)
If the output format doesn't support as many channels as the input image, then it will perform the equivalent of "--ch R,G,B" (or "R,G,B,A", if the format does support an alpha channel) before saving. If the input doesn't contain (somewhere in it) channels named R, G, and B, then it's an error.
Or should we just ignore the issue of specific channel names and write the first 3 (or 4) channels and call it a day?
-- lg
PS. WTF, Jono, don't you have someplace more important to be tonight?
Well in my case, one specific example of an input image is a non-subimage style stereo, with [RGB] and right.[RGB] labels. But oiiotool obviously should not have any knowledge of special labels, and the goal was to not have to pre-inspect the source images before converting to jpeg.
Thanks Larry for breaking down the categories of when oiio wants to make best default choices, vs erroring out. It does sound like a really similar situation to the fact that it does automatically throw away the alpha channel. If I have a source image with extra channels, and no channels have specifically been selected, it would seem that choosing RGB by default would be what the user most likely wants. If I knew I wanted specialized channels, I would definitely select them. Otherwise, it should probably complain about the alpha channel just as it does complain about 6 channels passing through.
If the input file format had 3 obvious r g b channels and then 3 which were not related to color (z, alpha, obj-id) then it seems like keeping the r g b channels when going to JPEG is in the spirit of "do the obvious thing".
If it's a 6-channel color thing then it's unlikely any 3 channels make sense.
Does the input format have no information like channel names?
--jono --mobile--
Post by Larry Gritz
On one hand, we don't want to do operations that are not supported in the output format, thereby resulting in significant loss of data. On the other hand, we can't be too trigger-happy with the errors, or it would be impossible to get anything done. So when we encounter a request to do something not possible with a given format, we try to ask "is there a particular thing that the human almost certainly meant when they made this impossible request?"
For example OpenEXR's least accurate pixel data type ('half') has more precision and range than JPEG's most accurate type, so there will be data loss, but we don't want to make every operation that starts with exr and ends with jpg to be an error. So we just convert any input pixel data type to UINT8 when outputting a JPEG. For most ordinary images, the data is LDR and our eyes are mostly satisfied with 8 bits in an sRGB-mapped intensity response, so this conversion will probably be fine. ("If you wanted to preserve the HDR data, you should not have output to JPEG, dummy.")
But what if we are asked to save more channels than a file format can accommodate? If you just drop the channels, you're not just reducing precision, you are losing whole sections of the original data. So at present, we make it a hard error.
As a special case (and maybe precedent?), we do just silently drop an alpha channel when saving JPEG. JPEG cannot accommodate alpha, but it's so common for an input to have alpha, it was painful for it to be an error when saving to JPEG. It seemed that the obvious human interpretation was "I'm using JPEG because this is final output for the web or for my mom to view, the alpha that was valuable for intermediate computations won't be needed for those purposes, so drop it."
I think that at the low level of ImageInput, open() should fail if you ask for more channels than can be supported in any obvious way. But for oiiotool in particular, I think we can make more "best guess" heuristics.
I'm certainly open to this being debated!
When oiiotool is outputting to a format that doesn't support as many channels as the image appears to have, do you think we should just silently output the first 3 channels and drop the rest? Should this be the one and only behavior? Or should there be a "strict/lax" option that determines whether this (and potentially other conversions) are an error or silently do whatever is necessary to complete the action somehow? If so, should the default be strict or lax?
-- lg
(Note for the pedants in the crowd: most of the places I wrote "JPEG", I'm not really talking about the JPEG compression, but rather the JFIF file format.)
I was curious about some behavior in oiiotool v1.4.14, when dealing with a source image that has 6 channels, and converting it to a jpeg.
oiiotool source.exr -o out.jpg
# oiiotool ERROR: jpeg does not support 6-channel images
I presume this bubbles up from libjpeg. Fair enough. But I know that the mantra of OpenImageIO has usually been to try and do the right default action, and attempt to avoid failures if possible. That being said, do you think it would be more in line with that philosophy if the jpeg plugin ensured it would only use 1, 3, or 4 of the first available channels, if not using an explicit list already? That way you would still get a jpg output, even if you passed it a 6 channel image, but could still explicitly give is a channel list if you knew them up front.
Currently I have to inspect the source image first before calling oiiotool, and ensure that I pass it a reduced channel list if needed.
Justin
--
Larry Gritz
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
***@larrygritz.com
Justin Israel
2015-02-10 22:02:42 UTC
Permalink
Wow you did the whole she-banga-bang already! Awesome!

I would love to give it a test, but won't be able to until probably
tomorrow. But if it handles 5-channel case => jpeg, as well as the
alpha-only single-channel case => jpeg, as advertised...I would say it
looks great to me!
Post by Larry Gritz
Justin, how about this: https://github.com/OpenImageIO/oiio/pull/1058
Post by Justin Israel
Personally I would be happy with selecting the first 3 or 4 channels (or
the number supported by the output format) under that given circumstance,
but if we want to go the extra mile and do some checking, maybe that would
be a plus?
On one hand, it seems smarter to try to pull out the R, G, B among them,
regardless of the order.
But that should be weighed against the distinct possibility that the
channels are not named simply, or are even mis-labeled.
I'll think about this a bit. Maybe an even more convoluted approach is
best: If the channel names contain is an identifiable R, G, B, use those
(regardless of original order), otherwise use the first 3 channels and hope
for the best?
I think most of the time these should be equivalent, because the OIIO
guidelines say that a format reader should reshuffle as necessary to make
R,G,B,A always be the first 4 channels, regardless of their appearance in
the file.
Actually, your mixture of the two approaches would probably be best. Funny
thing... just this morning I got bit by assuming the first 3 channels would
B
matte
G
R
Go figure.
Post by Justin Israel
Maybe this is a dumb question, but what do you think the average image
viewer does when displaying images with arbitrary channels? Do they look
for R,G,B labeled channels, or maybe load the first N channels?
Ha! I think the *average* viewer either crashes, refuses to load the
image at all, or loads it but totally botches the memory layout and thus
image: R G B A X Y | R G B A X Y |
display: | | | |
(I hope that comes out right, it takes a mono font on those lines to make
the spacing right.)
Hah. Well I meant viewers that can actually display the formats ;-)
Post by Justin Israel
Post by Larry Gritz
If the output format doesn't support as many channels as the input
image, then it will perform the equivalent of "--ch R,G,B" (or "R,G,B,A",
if the format does support an alpha channel) before saving. If the input
doesn't contain (somewhere in it) channels named R, G, and B, then it's an
error.
Or should we just ignore the issue of specific channel names and write
the first 3 (or 4) channels and call it a day?
-- lg
PS. WTF, Jono, don't you have someplace more important to be tonight?
Well in my case, one specific example of an input image is a
non-subimage style stereo, with [RGB] and right.[RGB] labels. But oiiotool
obviously should not have any knowledge of special labels, and the goal was
to not have to pre-inspect the source images before converting to jpeg.
Thanks Larry for breaking down the categories of when oiio wants to make
best default choices, vs erroring out. It does sound like a really similar
situation to the fact that it does automatically throw away the alpha
channel. If I have a source image with extra channels, and no channels have
specifically been selected, it would seem that choosing RGB by default
would be what the user most likely wants. If I knew I wanted specialized
channels, I would definitely select them. Otherwise, it should probably
complain about the alpha channel just as it does complain about 6 channels
passing through.
Post by Jono Gibbs
If the input file format had 3 obvious r g b channels and then 3 which
were not related to color (z, alpha, obj-id) then it seems like keeping the
r g b channels when going to JPEG is in the spirit of "do the obvious
thing".
If it's a 6-channel color thing then it's unlikely any 3 channels make sense.
Does the input format have no information like channel names?
--jono --mobile--
Post by Larry Gritz
On one hand, we don't want to do operations that are not supported in
the output format, thereby resulting in significant loss of data. On the
other hand, we can't be too trigger-happy with the errors, or it would be
impossible to get anything done. So when we encounter a request to do
something not possible with a given format, we try to ask "is there a
particular thing that the human almost certainly meant when they made this
impossible request?"
Post by Larry Gritz
For example OpenEXR's least accurate pixel data type ('half') has
more precision and range than JPEG's most accurate type, so there will be
data loss, but we don't want to make every operation that starts with exr
and ends with jpg to be an error. So we just convert any input pixel data
type to UINT8 when outputting a JPEG. For most ordinary images, the data is
LDR and our eyes are mostly satisfied with 8 bits in an sRGB-mapped
intensity response, so this conversion will probably be fine. ("If you
wanted to preserve the HDR data, you should not have output to JPEG,
dummy.")
Post by Larry Gritz
But what if we are asked to save more channels than a file format can
accommodate? If you just drop the channels, you're not just reducing
precision, you are losing whole sections of the original data. So at
present, we make it a hard error.
Post by Larry Gritz
As a special case (and maybe precedent?), we do just silently drop an
alpha channel when saving JPEG. JPEG cannot accommodate alpha, but it's so
common for an input to have alpha, it was painful for it to be an error
when saving to JPEG. It seemed that the obvious human interpretation was
"I'm using JPEG because this is final output for the web or for my mom to
view, the alpha that was valuable for intermediate computations won't be
needed for those purposes, so drop it."
Post by Larry Gritz
I think that at the low level of ImageInput, open() should fail if
you ask for more channels than can be supported in any obvious way. But for
oiiotool in particular, I think we can make more "best guess" heuristics.
Post by Larry Gritz
I'm certainly open to this being debated!
When oiiotool is outputting to a format that doesn't support as many
channels as the image appears to have, do you think we should just silently
output the first 3 channels and drop the rest? Should this be the one and
only behavior? Or should there be a "strict/lax" option that determines
whether this (and potentially other conversions) are an error or silently
do whatever is necessary to complete the action somehow? If so, should the
default be strict or lax?
Post by Larry Gritz
-- lg
"JPEG", I'm not really talking about the JPEG compression, but rather the
JFIF file format.)
Post by Larry Gritz
Post by Justin Israel
I was curious about some behavior in oiiotool v1.4.14, when dealing
with a source image that has 6 channels, and converting it to a jpeg.
Post by Larry Gritz
Post by Justin Israel
oiiotool source.exr -o out.jpg
# oiiotool ERROR: jpeg does not support 6-channel images
I presume this bubbles up from libjpeg. Fair enough. But I know that
the mantra of OpenImageIO has usually been to try and do the right default
action, and attempt to avoid failures if possible. That being said, do you
think it would be more in line with that philosophy if the jpeg plugin
ensured it would only use 1, 3, or 4 of the first available channels, if
not using an explicit list already? That way you would still get a jpg
output, even if you passed it a 6 channel image, but could still explicitly
give is a channel list if you knew them up front.
Post by Larry Gritz
Post by Justin Israel
Currently I have to inspect the source image first before calling
oiiotool, and ensure that I pass it a reduced channel list if needed.
Post by Larry Gritz
Post by Justin Israel
Justin
--
Larry Gritz
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
Larry Gritz
2015-02-10 22:05:27 UTC
Permalink
No rush, I just wanted to take care of it while it was still fresh in my mind, and yesterday was a work holiday in BC.
Post by Justin Israel
Wow you did the whole she-banga-bang already! Awesome!
I would love to give it a test, but won't be able to until probably tomorrow. But if it handles 5-channel case => jpeg, as well as the alpha-only single-channel case => jpeg, as advertised...I would say it looks great to me!
Justin, how about this: https://github.com/OpenImageIO/oiio/pull/1058
Post by Larry Gritz
Personally I would be happy with selecting the first 3 or 4 channels (or the number supported by the output format) under that given circumstance, but if we want to go the extra mile and do some checking, maybe that would be a plus?
On one hand, it seems smarter to try to pull out the R, G, B among them, regardless of the order.
But that should be weighed against the distinct possibility that the channels are not named simply, or are even mis-labeled.
I'll think about this a bit. Maybe an even more convoluted approach is best: If the channel names contain is an identifiable R, G, B, use those (regardless of original order), otherwise use the first 3 channels and hope for the best?
I think most of the time these should be equivalent, because the OIIO guidelines say that a format reader should reshuffle as necessary to make R,G,B,A always be the first 4 channels, regardless of their appearance in the file.
B
matte
G
R
Go figure.
Maybe this is a dumb question, but what do you think the average image viewer does when displaying images with arbitrary channels? Do they look for R,G,B labeled channels, or maybe load the first N channels?
image: R G B A X Y | R G B A X Y |
display: | | | |
(I hope that comes out right, it takes a mono font on those lines to make the spacing right.)
Hah. Well I meant viewers that can actually display the formats ;-)
If the output format doesn't support as many channels as the input image, then it will perform the equivalent of "--ch R,G,B" (or "R,G,B,A", if the format does support an alpha channel) before saving. If the input doesn't contain (somewhere in it) channels named R, G, and B, then it's an error.
Or should we just ignore the issue of specific channel names and write the first 3 (or 4) channels and call it a day?
-- lg
PS. WTF, Jono, don't you have someplace more important to be tonight?
Well in my case, one specific example of an input image is a non-subimage style stereo, with [RGB] and right.[RGB] labels. But oiiotool obviously should not have any knowledge of special labels, and the goal was to not have to pre-inspect the source images before converting to jpeg.
Thanks Larry for breaking down the categories of when oiio wants to make best default choices, vs erroring out. It does sound like a really similar situation to the fact that it does automatically throw away the alpha channel. If I have a source image with extra channels, and no channels have specifically been selected, it would seem that choosing RGB by default would be what the user most likely wants. If I knew I wanted specialized channels, I would definitely select them. Otherwise, it should probably complain about the alpha channel just as it does complain about 6 channels passing through.
If the input file format had 3 obvious r g b channels and then 3 which were not related to color (z, alpha, obj-id) then it seems like keeping the r g b channels when going to JPEG is in the spirit of "do the obvious thing".
If it's a 6-channel color thing then it's unlikely any 3 channels make sense.
Does the input format have no information like channel names?
--jono --mobile--
Post by Larry Gritz
On one hand, we don't want to do operations that are not supported in the output format, thereby resulting in significant loss of data. On the other hand, we can't be too trigger-happy with the errors, or it would be impossible to get anything done. So when we encounter a request to do something not possible with a given format, we try to ask "is there a particular thing that the human almost certainly meant when they made this impossible request?"
For example OpenEXR's least accurate pixel data type ('half') has more precision and range than JPEG's most accurate type, so there will be data loss, but we don't want to make every operation that starts with exr and ends with jpg to be an error. So we just convert any input pixel data type to UINT8 when outputting a JPEG. For most ordinary images, the data is LDR and our eyes are mostly satisfied with 8 bits in an sRGB-mapped intensity response, so this conversion will probably be fine. ("If you wanted to preserve the HDR data, you should not have output to JPEG, dummy.")
But what if we are asked to save more channels than a file format can accommodate? If you just drop the channels, you're not just reducing precision, you are losing whole sections of the original data. So at present, we make it a hard error.
As a special case (and maybe precedent?), we do just silently drop an alpha channel when saving JPEG. JPEG cannot accommodate alpha, but it's so common for an input to have alpha, it was painful for it to be an error when saving to JPEG. It seemed that the obvious human interpretation was "I'm using JPEG because this is final output for the web or for my mom to view, the alpha that was valuable for intermediate computations won't be needed for those purposes, so drop it."
I think that at the low level of ImageInput, open() should fail if you ask for more channels than can be supported in any obvious way. But for oiiotool in particular, I think we can make more "best guess" heuristics.
I'm certainly open to this being debated!
When oiiotool is outputting to a format that doesn't support as many channels as the image appears to have, do you think we should just silently output the first 3 channels and drop the rest? Should this be the one and only behavior? Or should there be a "strict/lax" option that determines whether this (and potentially other conversions) are an error or silently do whatever is necessary to complete the action somehow? If so, should the default be strict or lax?
-- lg
(Note for the pedants in the crowd: most of the places I wrote "JPEG", I'm not really talking about the JPEG compression, but rather the JFIF file format.)
I was curious about some behavior in oiiotool v1.4.14, when dealing with a source image that has 6 channels, and converting it to a jpeg.
oiiotool source.exr -o out.jpg
# oiiotool ERROR: jpeg does not support 6-channel images
I presume this bubbles up from libjpeg. Fair enough. But I know that the mantra of OpenImageIO has usually been to try and do the right default action, and attempt to avoid failures if possible. That being said, do you think it would be more in line with that philosophy if the jpeg plugin ensured it would only use 1, 3, or 4 of the first available channels, if not using an explicit list already? That way you would still get a jpg output, even if you passed it a 6 channel image, but could still explicitly give is a channel list if you knew them up front.
Currently I have to inspect the source image first before calling oiiotool, and ensure that I pass it a reduced channel list if needed.
Justin
--
Larry Gritz
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
***@larrygritz.com
Larry Gritz
2015-02-10 17:59:24 UTC
Permalink
Based on the time stamp of this email, I must assume that Jono was typing this while wearing a tuxedo. Posting to oiio-dev is a classy affair!


Post by Jono Gibbs
If the input file format had 3 obvious r g b channels and then 3 which were not related to color (z, alpha, obj-id) then it seems like keeping the r g b channels when going to JPEG is in the spirit of "do the obvious thing".
If it's a 6-channel color thing then it's unlikely any 3 channels make sense.
Does the input format have no information like channel names?
--jono --mobile--
Post by Larry Gritz
On one hand, we don't want to do operations that are not supported in the output format, thereby resulting in significant loss of data. On the other hand, we can't be too trigger-happy with the errors, or it would be impossible to get anything done. So when we encounter a request to do something not possible with a given format, we try to ask "is there a particular thing that the human almost certainly meant when they made this impossible request?"
For example OpenEXR's least accurate pixel data type ('half') has more precision and range than JPEG's most accurate type, so there will be data loss, but we don't want to make every operation that starts with exr and ends with jpg to be an error. So we just convert any input pixel data type to UINT8 when outputting a JPEG. For most ordinary images, the data is LDR and our eyes are mostly satisfied with 8 bits in an sRGB-mapped intensity response, so this conversion will probably be fine. ("If you wanted to preserve the HDR data, you should not have output to JPEG, dummy.")
But what if we are asked to save more channels than a file format can accommodate? If you just drop the channels, you're not just reducing precision, you are losing whole sections of the original data. So at present, we make it a hard error.
As a special case (and maybe precedent?), we do just silently drop an alpha channel when saving JPEG. JPEG cannot accommodate alpha, but it's so common for an input to have alpha, it was painful for it to be an error when saving to JPEG. It seemed that the obvious human interpretation was "I'm using JPEG because this is final output for the web or for my mom to view, the alpha that was valuable for intermediate computations won't be needed for those purposes, so drop it."
I think that at the low level of ImageInput, open() should fail if you ask for more channels than can be supported in any obvious way. But for oiiotool in particular, I think we can make more "best guess" heuristics.
I'm certainly open to this being debated!
When oiiotool is outputting to a format that doesn't support as many channels as the image appears to have, do you think we should just silently output the first 3 channels and drop the rest? Should this be the one and only behavior? Or should there be a "strict/lax" option that determines whether this (and potentially other conversions) are an error or silently do whatever is necessary to complete the action somehow? If so, should the default be strict or lax?
-- lg
(Note for the pedants in the crowd: most of the places I wrote "JPEG", I'm not really talking about the JPEG compression, but rather the JFIF file format.)
I was curious about some behavior in oiiotool v1.4.14, when dealing with a source image that has 6 channels, and converting it to a jpeg.
oiiotool source.exr -o out.jpg
# oiiotool ERROR: jpeg does not support 6-channel images
I presume this bubbles up from libjpeg. Fair enough. But I know that the mantra of OpenImageIO has usually been to try and do the right default action, and attempt to avoid failures if possible. That being said, do you think it would be more in line with that philosophy if the jpeg plugin ensured it would only use 1, 3, or 4 of the first available channels, if not using an explicit list already? That way you would still get a jpg output, even if you passed it a 6 channel image, but could still explicitly give is a channel list if you knew them up front.
Currently I have to inspect the source image first before calling oiiotool, and ensure that I pass it a reduced channel list if needed.
Justin
--
Larry Gritz
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
_______________________________________________
Oiio-dev mailing list
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
***@larrygritz.com
Jonathan Gibbs
2015-02-11 08:51:47 UTC
Permalink
Yes, I was. I was waiting for my wife to be ready to head over, and I
figure how better to spend the time than thinking about 6-channel images!

From now on, I'll try to be in formal attire when posting.

--jono

Loading...