[Oiio-dev] multichannel exr > jpeg conversion

[Larry Gritz]

I hope you don't mind that I'm CCing oiio-dev with my reply.

This is an interesting question. Currently, if you try to open a file for output and request a number of channels that it can't support, the open() call will fail. That said, it does seem an entirely reasonable operation to want to convert, say, an RGBA file to a format that does not support alpha, by copying the RGB only.

I'm curious to hear people's opinions on how to address this problem. I can think of several possible strategies:

1. (Logic in the plugins) Change the JPEG (and/or others) output to silently and automatically truncate channels if asked to write more channels than the format supports, much like how it will force uint8 data (because that's all JPEG supports) even if you ask for something else. Or, we could keep the default as it is (fail), but have JPEG support a request by the app to truncate channels (via the "open with config" call) and have iconvert and certain other apps make that request.

2. (Logic in the app) Leave the drivers alone, but make iconvert and oiiotool check the failure messages and, if an open() fails and nchannels > 3, make an intelligent guess by trying to open the file a second time with fewer channels, and if that succeeds, output that way.

3. (Logic in the user's head) Add a --channels option to oiiotool that lets you explicitly prune or shuffle channels, so you could

oiiotool my5channelfile.exr --channels R,G,B -o besticando.jpg


Opinions? None are very hard, I can fix right away, but first I'd like to get consensus on which level of the onion ought to have the control of this behavior.

Hi,
iconvert ERROR: Could not open "p:/1310.Adam-testy.Base/conv/outCh3.jpg" : jpeg does not support 5-channel images
Is there a way to strip exr to rgb channels and convert it to jpeg anyway?
regards
Adam

--
Larry Gritz
lg at larrygritz.com

[Hugh Macdonald]

I would suggest that the writer should automatically truncate channels that it doesn't know how to deal with. If this leaves fewer channels than it is expecting (e.g. an EXR with no RGBA, but beauty.r, beauty.g, beauty.b), then it should gracefully error (or maybe it could try to intelligently pick other channels to show? This sounds dangerous to me, unless there are only R, G, B channels but named differently, as in the example above).

The user would then also be able to specify channel shuffling if they want to use different channels, or if there is, as in the example above, no definitive channel group.

Hugh Macdonald
nvizible ? VISUAL EFFECTS

[phone]
[phone]

www.nvizible.com

Post by Larry Gritz
I hope you don't mind that I'm CCing oiio-dev with my reply.
This is an interesting question. Currently, if you try to open a file for output and request a number of channels that it can't support, the open() call will fail. That said, it does seem an entirely reasonable operation to want to convert, say, an RGBA file to a format that does not support alpha, by copying the RGB only.
1. (Logic in the plugins) Change the JPEG (and/or others) output to silently and automatically truncate channels if asked to write more channels than the format supports, much like how it will force uint8 data (because that's all JPEG supports) even if you ask for something else. Or, we could keep the default as it is (fail), but have JPEG support a request by the app to truncate channels (via the "open with config" call) and have iconvert and certain other apps make that request.
2. (Logic in the app) Leave the drivers alone, but make iconvert and oiiotool check the failure messages and, if an open() fails and nchannels > 3, make an intelligent guess by trying to open the file a second time with fewer channels, and if that succeeds, output that way.
3. (Logic in the user's head) Add a --channels option to oiiotool that lets you explicitly prune or shuffle channels, so you could
oiiotool my5channelfile.exr --channels R,G,B -o besticando.jpg
Opinions? None are very hard, I can fix right away, but first I'd like to get consensus on which level of the onion ought to have the control of this behavior.

Hi,
iconvert ERROR: Could not open "p:/1310.Adam-testy.Base/conv/outCh3.jpg" : jpeg does not support 5-channel images
Is there a way to strip exr to rgb channels and convert it to jpeg anyway?
regards
Adam

--
Larry Gritz
lg at larrygritz.com
_______________________________________________
Oiio-dev mailing list
Oiio-dev at lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
D I S C L A I M E R : This email and any files transmitted with it are
intended solely for the intended addressee, and may contain confidential
information or material protected by law, copyright or other legislation.
If you have received this message in error, please return it to the sender
or notify the sender by calling [phone], and immediately and
permanently delete it. You should not copy it or use it for any purpose,
nor disclose its contents to any other person. Only the intended recipient
may place any reliance upon it. Nvizible Limited accepts no responsibility
or liability for emails sent by its employees or personnel which are not
sent in the course of its business or that of its clients.

Nvizible Limited, 3 Richfield Avenue, Richfield Place, Reading, Berkshire,
RG1 8EQ . Registered in England & Wales with Company Number: 6900121
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openimageio.org/pipermail/oiio-dev-openimageio.org/attachments/20120804/a10c3c7e/attachment.htm>

[Larry Gritz]

Hmmm... sometimes it will fail outright, sometimes it will save only certain channels, and it will depend on how they are named? That sounds awfully confusing to me.

-- lg

Post by Hugh Macdonald
I would suggest that the writer should automatically truncate channels that it doesn't know how to deal with. If this leaves fewer channels than it is expecting (e.g. an EXR with no RGBA, but beauty.r, beauty.g, beauty.b), then it should gracefully error (or maybe it could try to intelligently pick other channels to show? This sounds dangerous to me, unless there are only R, G, B channels but named differently, as in the example above).
The user would then also be able to specify channel shuffling if they want to use different channels, or if there is, as in the example above, no definitive channel group.
Hugh Macdonald
nvizible ? VISUAL EFFECTS
[phone]
[phone]
www.nvizible.com

Post by Larry Gritz
I hope you don't mind that I'm CCing oiio-dev with my reply.
This is an interesting question. Currently, if you try to open a file for output and request a number of channels that it can't support, the open() call will fail. That said, it does seem an entirely reasonable operation to want to convert, say, an RGBA file to a format that does not support alpha, by copying the RGB only.
1. (Logic in the plugins) Change the JPEG (and/or others) output to silently and automatically truncate channels if asked to write more channels than the format supports, much like how it will force uint8 data (because that's all JPEG supports) even if you ask for something else. Or, we could keep the default as it is (fail), but have JPEG support a request by the app to truncate channels (via the "open with config" call) and have iconvert and certain other apps make that request.
2. (Logic in the app) Leave the drivers alone, but make iconvert and oiiotool check the failure messages and, if an open() fails and nchannels > 3, make an intelligent guess by trying to open the file a second time with fewer channels, and if that succeeds, output that way.
3. (Logic in the user's head) Add a --channels option to oiiotool that lets you explicitly prune or shuffle channels, so you could
oiiotool my5channelfile.exr --channels R,G,B -o besticando.jpg
Opinions? None are very hard, I can fix right away, but first I'd like to get consensus on which level of the onion ought to have the control of this behavior.

--
Larry Gritz
lg at larrygritz.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openimageio.org/pipermail/oiio-dev-openimageio.org/attachments/20120804/6241db3a/attachment-0001.htm>

[Larry Gritz]

Hmmm... sometimes it will fail outright, sometimes it will save only certain channels, and it will depend on how they are named? That sounds awfully confusing to me.

-- lg

Post by Hugh Macdonald
I would suggest that the writer should automatically truncate channels that it doesn't know how to deal with. If this leaves fewer channels than it is expecting (e.g. an EXR with no RGBA, but beauty.r, beauty.g, beauty.b), then it should gracefully error (or maybe it could try to intelligently pick other channels to show? This sounds dangerous to me, unless there are only R, G, B channels but named differently, as in the example above).
The user would then also be able to specify channel shuffling if they want to use different channels, or if there is, as in the example above, no definitive channel group.
Hugh Macdonald
nvizible ? VISUAL EFFECTS
[phone]
[phone]
www.nvizible.com

Post by Larry Gritz
I hope you don't mind that I'm CCing oiio-dev with my reply.
This is an interesting question. Currently, if you try to open a file for output and request a number of channels that it can't support, the open() call will fail. That said, it does seem an entirely reasonable operation to want to convert, say, an RGBA file to a format that does not support alpha, by copying the RGB only.
1. (Logic in the plugins) Change the JPEG (and/or others) output to silently and automatically truncate channels if asked to write more channels than the format supports, much like how it will force uint8 data (because that's all JPEG supports) even if you ask for something else. Or, we could keep the default as it is (fail), but have JPEG support a request by the app to truncate channels (via the "open with config" call) and have iconvert and certain other apps make that request.
2. (Logic in the app) Leave the drivers alone, but make iconvert and oiiotool check the failure messages and, if an open() fails and nchannels > 3, make an intelligent guess by trying to open the file a second time with fewer channels, and if that succeeds, output that way.
3. (Logic in the user's head) Add a --channels option to oiiotool that lets you explicitly prune or shuffle channels, so you could
oiiotool my5channelfile.exr --channels R,G,B -o besticando.jpg
Opinions? None are very hard, I can fix right away, but first I'd like to get consensus on which level of the onion ought to have the control of this behavior.

--
Larry Gritz
lg at larrygritz.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openimageio.org/pipermail/oiio-dev-openimageio.org/attachments/20120804/551bc444/attachment.htm>

[Larry Gritz]

Hmmm... sometimes it will fail outright, sometimes it will save only certain channels, and it will depend on how they are named? That sounds awfully confusing to me.

-- lg

Post by Hugh Macdonald
I would suggest that the writer should automatically truncate channels that it doesn't know how to deal with. If this leaves fewer channels than it is expecting (e.g. an EXR with no RGBA, but beauty.r, beauty.g, beauty.b), then it should gracefully error (or maybe it could try to intelligently pick other channels to show? This sounds dangerous to me, unless there are only R, G, B channels but named differently, as in the example above).
The user would then also be able to specify channel shuffling if they want to use different channels, or if there is, as in the example above, no definitive channel group.
Hugh Macdonald
nvizible ? VISUAL EFFECTS
[phone]
[phone]
www.nvizible.com

Post by Larry Gritz
I hope you don't mind that I'm CCing oiio-dev with my reply.
This is an interesting question. Currently, if you try to open a file for output and request a number of channels that it can't support, the open() call will fail. That said, it does seem an entirely reasonable operation to want to convert, say, an RGBA file to a format that does not support alpha, by copying the RGB only.
1. (Logic in the plugins) Change the JPEG (and/or others) output to silently and automatically truncate channels if asked to write more channels than the format supports, much like how it will force uint8 data (because that's all JPEG supports) even if you ask for something else. Or, we could keep the default as it is (fail), but have JPEG support a request by the app to truncate channels (via the "open with config" call) and have iconvert and certain other apps make that request.
2. (Logic in the app) Leave the drivers alone, but make iconvert and oiiotool check the failure messages and, if an open() fails and nchannels > 3, make an intelligent guess by trying to open the file a second time with fewer channels, and if that succeeds, output that way.
3. (Logic in the user's head) Add a --channels option to oiiotool that lets you explicitly prune or shuffle channels, so you could
oiiotool my5channelfile.exr --channels R,G,B -o besticando.jpg
Opinions? None are very hard, I can fix right away, but first I'd like to get consensus on which level of the onion ought to have the control of this behavior.

--
Larry Gritz
lg at larrygritz.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openimageio.org/pipermail/oiio-dev-openimageio.org/attachments/20120804/6241db3a/attachment-0002.htm>

[Larry Gritz]

Hmmm... sometimes it will fail outright, sometimes it will save only certain channels, and it will depend on how they are named? That sounds awfully confusing to me.

-- lg

Post by Hugh Macdonald
I would suggest that the writer should automatically truncate channels that it doesn't know how to deal with. If this leaves fewer channels than it is expecting (e.g. an EXR with no RGBA, but beauty.r, beauty.g, beauty.b), then it should gracefully error (or maybe it could try to intelligently pick other channels to show? This sounds dangerous to me, unless there are only R, G, B channels but named differently, as in the example above).
The user would then also be able to specify channel shuffling if they want to use different channels, or if there is, as in the example above, no definitive channel group.
Hugh Macdonald
nvizible ? VISUAL EFFECTS
[phone]
[phone]
www.nvizible.com

Post by Larry Gritz
I hope you don't mind that I'm CCing oiio-dev with my reply.
This is an interesting question. Currently, if you try to open a file for output and request a number of channels that it can't support, the open() call will fail. That said, it does seem an entirely reasonable operation to want to convert, say, an RGBA file to a format that does not support alpha, by copying the RGB only.
1. (Logic in the plugins) Change the JPEG (and/or others) output to silently and automatically truncate channels if asked to write more channels than the format supports, much like how it will force uint8 data (because that's all JPEG supports) even if you ask for something else. Or, we could keep the default as it is (fail), but have JPEG support a request by the app to truncate channels (via the "open with config" call) and have iconvert and certain other apps make that request.
2. (Logic in the app) Leave the drivers alone, but make iconvert and oiiotool check the failure messages and, if an open() fails and nchannels > 3, make an intelligent guess by trying to open the file a second time with fewer channels, and if that succeeds, output that way.
3. (Logic in the user's head) Add a --channels option to oiiotool that lets you explicitly prune or shuffle channels, so you could
oiiotool my5channelfile.exr --channels R,G,B -o besticando.jpg
Opinions? None are very hard, I can fix right away, but first I'd like to get consensus on which level of the onion ought to have the control of this behavior.

--
Larry Gritz
lg at larrygritz.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openimageio.org/pipermail/oiio-dev-openimageio.org/attachments/20120804/551bc444/attachment-0001.htm>

[Chris Foster]

Post by Larry Gritz
I hope you don't mind that I'm CCing oiio-dev with my reply.
This is an interesting question. Currently, if you try to open a file for output and request a number of channels that it can't support, the open() call will fail. That said, it does seem an entirely reasonable operation to want to convert, say, an RGBA file to a format that does not support alpha, by copying the RGB only.
1. (Logic in the plugins) Change the JPEG (and/or others) output to silently and automatically truncate channels if asked to write more channels than the format supports, much like how it will force uint8 data (because that's all JPEG supports) even if you ask for something else. Or, we could keep the default as it is (fail), but have JPEG support a request by the app to truncate channels (via the "open with config" call) and have iconvert and certain other apps make that request.
2. (Logic in the app) Leave the drivers alone, but make iconvert and oiiotool check the failure messages and, if an open() fails and nchannels > 3, make an intelligent guess by trying to open the file a second time with fewer channels, and if that succeeds, output that way.
3. (Logic in the user's head) Add a --channels option to oiiotool that lets you explicitly prune or shuffle channels, so you could
oiiotool my5channelfile.exr --channels R,G,B -o besticando.jpg
Opinions? None are very hard, I can fix right away, but first I'd like to
get consensus on which level of the onion ought to have the control of this
behavior.

I don't like option 1. IMHO it would be nasty for the output plugins to be
too opinionated about what channels they care to save. If I'm using the C++
API I don't want my hand held, I just want it to do what I say and if that's
impossible then fail with a useful error :) Furthermore, if all we really
want is some uniform logic like in option 2, there's no point putting it in
each and every output plugin.

Either of options 2 or 3 seem reasonable though personally I like option 3
because it gives the most flexibility and seems the most well defined.

~Chris

[Larry Gritz]

#3 solution proposed here: https://github.com/OpenImageIO/oiio/pull/418

Post by Chris Foster
I don't like option 1. IMHO it would be nasty for the output plugins to be
too opinionated about what channels they care to save. If I'm using the C++
API I don't want my hand held, I just want it to do what I say and if that's
impossible then fail with a useful error :) Furthermore, if all we really
want is some uniform logic like in option 2, there's no point putting it in
each and every output plugin.
Either of options 2 or 3 seem reasonable though personally I like option 3
because it gives the most flexibility and seems the most well defined.
~Chris

--
Larry Gritz
lg at larrygritz.com

[Larry Gritz]

#3 solution proposed here: https://github.com/OpenImageIO/oiio/pull/418

Post by Chris Foster
I don't like option 1. IMHO it would be nasty for the output plugins to be
too opinionated about what channels they care to save. If I'm using the C++
API I don't want my hand held, I just want it to do what I say and if that's
impossible then fail with a useful error :) Furthermore, if all we really
want is some uniform logic like in option 2, there's no point putting it in
each and every output plugin.
Either of options 2 or 3 seem reasonable though personally I like option 3
because it gives the most flexibility and seems the most well defined.
~Chris

--
Larry Gritz
lg at larrygritz.com

[Larry Gritz]

I hope you don't mind that I'm CCing oiio-dev with my reply.

This is an interesting question. Currently, if you try to open a file for output and request a number of channels that it can't support, the open() call will fail. That said, it does seem an entirely reasonable operation to want to convert, say, an RGBA file to a format that does not support alpha, by copying the RGB only.

I'm curious to hear people's opinions on how to address this problem. I can think of several possible strategies:

1. (Logic in the plugins) Change the JPEG (and/or others) output to silently and automatically truncate channels if asked to write more channels than the format supports, much like how it will force uint8 data (because that's all JPEG supports) even if you ask for something else. Or, we could keep the default as it is (fail), but have JPEG support a request by the app to truncate channels (via the "open with config" call) and have iconvert and certain other apps make that request.

2. (Logic in the app) Leave the drivers alone, but make iconvert and oiiotool check the failure messages and, if an open() fails and nchannels > 3, make an intelligent guess by trying to open the file a second time with fewer channels, and if that succeeds, output that way.

3. (Logic in the user's head) Add a --channels option to oiiotool that lets you explicitly prune or shuffle channels, so you could

oiiotool my5channelfile.exr --channels R,G,B -o besticando.jpg


Opinions? None are very hard, I can fix right away, but first I'd like to get consensus on which level of the onion ought to have the control of this behavior.

Hi,
iconvert ERROR: Could not open "p:/1310.Adam-testy.Base/conv/outCh3.jpg" : jpeg does not support 5-channel images
Is there a way to strip exr to rgb channels and convert it to jpeg anyway?
regards
Adam

--
Larry Gritz
lg at larrygritz.com

[Hugh Macdonald]

I would suggest that the writer should automatically truncate channels that it doesn't know how to deal with. If this leaves fewer channels than it is expecting (e.g. an EXR with no RGBA, but beauty.r, beauty.g, beauty.b), then it should gracefully error (or maybe it could try to intelligently pick other channels to show? This sounds dangerous to me, unless there are only R, G, B channels but named differently, as in the example above).

The user would then also be able to specify channel shuffling if they want to use different channels, or if there is, as in the example above, no definitive channel group.

Hugh Macdonald
nvizible ? VISUAL EFFECTS

[phone]
[phone]

www.nvizible.com

Post by Larry Gritz
I hope you don't mind that I'm CCing oiio-dev with my reply.
This is an interesting question. Currently, if you try to open a file for output and request a number of channels that it can't support, the open() call will fail. That said, it does seem an entirely reasonable operation to want to convert, say, an RGBA file to a format that does not support alpha, by copying the RGB only.
1. (Logic in the plugins) Change the JPEG (and/or others) output to silently and automatically truncate channels if asked to write more channels than the format supports, much like how it will force uint8 data (because that's all JPEG supports) even if you ask for something else. Or, we could keep the default as it is (fail), but have JPEG support a request by the app to truncate channels (via the "open with config" call) and have iconvert and certain other apps make that request.
2. (Logic in the app) Leave the drivers alone, but make iconvert and oiiotool check the failure messages and, if an open() fails and nchannels > 3, make an intelligent guess by trying to open the file a second time with fewer channels, and if that succeeds, output that way.
3. (Logic in the user's head) Add a --channels option to oiiotool that lets you explicitly prune or shuffle channels, so you could
oiiotool my5channelfile.exr --channels R,G,B -o besticando.jpg
Opinions? None are very hard, I can fix right away, but first I'd like to get consensus on which level of the onion ought to have the control of this behavior.

Hi,
iconvert ERROR: Could not open "p:/1310.Adam-testy.Base/conv/outCh3.jpg" : jpeg does not support 5-channel images
Is there a way to strip exr to rgb channels and convert it to jpeg anyway?
regards
Adam

--
Larry Gritz
lg at larrygritz.com
_______________________________________________
Oiio-dev mailing list
Oiio-dev at lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
D I S C L A I M E R : This email and any files transmitted with it are
intended solely for the intended addressee, and may contain confidential
information or material protected by law, copyright or other legislation.
If you have received this message in error, please return it to the sender
or notify the sender by calling [phone], and immediately and
permanently delete it. You should not copy it or use it for any purpose,
nor disclose its contents to any other person. Only the intended recipient
may place any reliance upon it. Nvizible Limited accepts no responsibility
or liability for emails sent by its employees or personnel which are not
sent in the course of its business or that of its clients.

Nvizible Limited, 3 Richfield Avenue, Richfield Place, Reading, Berkshire,
RG1 8EQ . Registered in England & Wales with Company Number: 6900121
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openimageio.org/pipermail/oiio-dev-openimageio.org/attachments/20120804/a10c3c7e/attachment-0002.htm>

[Chris Foster]

Post by Larry Gritz
I hope you don't mind that I'm CCing oiio-dev with my reply.
This is an interesting question. Currently, if you try to open a file for output and request a number of channels that it can't support, the open() call will fail. That said, it does seem an entirely reasonable operation to want to convert, say, an RGBA file to a format that does not support alpha, by copying the RGB only.
1. (Logic in the plugins) Change the JPEG (and/or others) output to silently and automatically truncate channels if asked to write more channels than the format supports, much like how it will force uint8 data (because that's all JPEG supports) even if you ask for something else. Or, we could keep the default as it is (fail), but have JPEG support a request by the app to truncate channels (via the "open with config" call) and have iconvert and certain other apps make that request.
2. (Logic in the app) Leave the drivers alone, but make iconvert and oiiotool check the failure messages and, if an open() fails and nchannels > 3, make an intelligent guess by trying to open the file a second time with fewer channels, and if that succeeds, output that way.
3. (Logic in the user's head) Add a --channels option to oiiotool that lets you explicitly prune or shuffle channels, so you could
oiiotool my5channelfile.exr --channels R,G,B -o besticando.jpg
Opinions? None are very hard, I can fix right away, but first I'd like to
get consensus on which level of the onion ought to have the control of this
behavior.

I don't like option 1. IMHO it would be nasty for the output plugins to be
too opinionated about what channels they care to save. If I'm using the C++
API I don't want my hand held, I just want it to do what I say and if that's
impossible then fail with a useful error :) Furthermore, if all we really
want is some uniform logic like in option 2, there's no point putting it in
each and every output plugin.

Either of options 2 or 3 seem reasonable though personally I like option 3
because it gives the most flexibility and seems the most well defined.

~Chris