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.)
On Feb 5, 2015, at 3:56 PM, Justin Israel <[email protected]> wrote:
> 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
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
