You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I'm trying to read an image in and add an alpha channel if one doesn't exist, however I can't see any obvious way to do it.
This is useful for dealing with images where it is not known ahead of time whether there will be an alpha channel so that downstream operations can safely assume that it's present.
Describe the solution you'd like
It would be good to be able to specify a default value for a channel when reading, so if the channel is present it will use the channel data, otherwise it will use the default value.
A possible syntax for this would be something like:
$ oiiotool -i:ch=R,G,B,A?=1.0 in.exr -o rgba.exr
The same would also apply to --ch:
$ oiiotool in.exr --ch ,,,A?=1.0 -o rgba.exr
Note that this is not exactly equivalent to the example below using --if as the channel name would have to match.
however it will read all channels of the input - I encountered this issue when dealing with EXRs that contained a bunch of extra channels and I wanted to avoid reading in the unwanted ones. If I use -i:ch=R,G,B,A, it will add an A channel but the default will be 0.0 (and I get a warning) and if I add -i:ch=R,G,B,A=1.0, it will overwrite the alpha channel with a constant 1.0.
I also considered trying to read the image metadata with no channel information, check the channels then load just those channels, but this gets complex quite quickly.
There is also the option of just using the OpenImageIO API, however it would again be significantly more complex.
Additional context
The text was updated successfully, but these errors were encountered:
Do you think that the simplest thing (from a user perspective) would just be to add a --addmissingalpha command to oiiotool, which would add an A=1 channel if it doesn't already exist, and do nothing otherwise?
That does seem like a useful flag to have, although I'm not sure if it would cover the use-case of reading only the RGBA channels from an EXR that may contain others.
Saying that, I'm now wondering if oiiotool lazy-loads channel information or whether it reads the entire image - if it lazy-loads, this would work as it would theoretically not try and read data from any other channels:
Is your feature request related to a problem? Please describe.
I'm trying to read an image in and add an alpha channel if one doesn't exist, however I can't see any obvious way to do it.
This is useful for dealing with images where it is not known ahead of time whether there will be an alpha channel so that downstream operations can safely assume that it's present.
Describe the solution you'd like
It would be good to be able to specify a default value for a channel when reading, so if the channel is present it will use the channel data, otherwise it will use the default value.
A possible syntax for this would be something like:
$ oiiotool -i:ch=R,G,B,A?=1.0 in.exr -o rgba.exr
The same would also apply to
--ch
:$ oiiotool in.exr --ch ,,,A?=1.0 -o rgba.exr
Note that this is not exactly equivalent to the example below using
--if
as the channel name would have to match.Describe alternatives you've considered
There is this example in the documentation:
$ oiiotool in.exr --if "{TOP.nchannels == 3}" --ch ,,,A=1.0 --endif -o rgba.exr
however it will read all channels of the input - I encountered this issue when dealing with EXRs that contained a bunch of extra channels and I wanted to avoid reading in the unwanted ones. If I use
-i:ch=R,G,B,A
, it will add an A channel but the default will be 0.0 (and I get a warning) and if I add-i:ch=R,G,B,A=1.0
, it will overwrite the alpha channel with a constant 1.0.I also considered trying to read the image metadata with no channel information, check the channels then load just those channels, but this gets complex quite quickly.
There is also the option of just using the OpenImageIO API, however it would again be significantly more complex.
Additional context
The text was updated successfully, but these errors were encountered: