For our needs, the most important thing is that the order of subimages remains the same. If an EXR contains multiple subimages, it's always the first that is the beauty image. And since we use oiiotool heavily for all of our deliveries any additional subimages in an EXR are just mattes. So at least we are only operating on the first subimage and in our case --colorconvert has been the only function so far for EXRs (as everything is already prepared in comp).
I do like your idea about supplying subimage to each operation, but I'm happy with using --subimage command since it feels clean and easy to read. I guess it's just when you merge them back that might confuse people? But I don't have any better suggestions either. As long as it's mentioned in the documentation :) On Wed, 6 May 2020 at 19:13, Larry Gritz <l...@larrygritz.com> wrote: > No, it's no trouble at all. > > I am wondering, though, if it's enough. This fix is relatively > straightforward if you want to extract one subimage, change it alone, and > then reassemble with the extracted subimage as the new first subimage > (maybe you don't care about the resulting order, or maybe the first is the > one you wanted to change anyway). It's a little tricker if you wanted to > color correct subimage #5, and then reinsert it back in the #5 position. If > that's important, I could add some sort of modifier to --siappend that lets > you insert it into an arbitrary position rather than only at the end? > > Somewhat more generally, is this a common enough operation that > --colorconvert should have a modifier that lets you apply it in place to > just one subimage, without the extra steps of --subimage/--siappend? Or all > the color conversion functions (like --ociolook, etc)? Or should nearly all > oiiotool commands have an option that lets you restrict their work to a > specific subimage? (That is obviously a lot more work.) > > > > On May 6, 2020, at 1:15 AM, Andreas Ekoutsidis < > andreas.ekoutsi...@ilpvfx.com> wrote: > > Hey, > > Thanks for the super fast reply! Your fix works for me, as long as it > doesn't introduce other problems for your code :) > > On Wed, 6 May 2020 at 06:19, Larry Gritz <l...@larrygritz.com> wrote: > >> How does this look as a potential way to address this case? >> >> https://github.com/OpenImageIO/oiio/pull/2575 >> >> >> On May 5, 2020, at 5:25 PM, Larry Gritz <l...@larrygritz.com> wrote: >> >> Oof, that is currently an awkward thing to do. >> >> I think I know a way to do it, with some changes. Stay tuned, I'll try >> something tonight. >> >> -- lg >> >> >> On May 5, 2020, at 6:37 AM, Andreas Ekoutsidis < >> andreas.ekoutsi...@ilpvfx.com> wrote: >> >> Hi, >> >> Is it possible to only operate on one subimage and still keep the rest >> untouched? >> >> In my case I get EXRs from comp that have mattes as separate subimages in >> the EXR. I want to perform a colorconvert on the main subimage of the EXRs, >> but if I do so I lose the rest of the subimages: >> >> oiiotool /path/to/frame.exr --colorconvert linear AlexaV3LogC -o >> /path/to/out.exr >> >> By reading around on the mail list here, I then got inspired into trying >> this: >> >> oiiotool /path/to/frame.exr --subimage main --colorconvert linear >> AlexaV3LogC /path/to/frame.exr --subimage matte1 --siappendall -o >> /path/to/out.exr >> >> This will indeed create an EXR with the same number of subimages as >> before, but the "matte1" remains completely empty. Subimage "main" has in >> this case the channels "R, G, B, A" and "matte1" have the channels "red, >> green, blue, alpha". >> >> What did I do wrong? Is this possible? >> >> I have tried this in both 1.8.17 and 2.0.12. >> >> Thanks in advance, >> Andreas >> _______________________________________________ >> Oiio-dev mailing list >> Oiio-dev@lists.openimageio.org >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> >> >> -- >> Larry Gritz >> l...@larrygritz.com >> >> >> >> >> _______________________________________________ >> Oiio-dev mailing list >> Oiio-dev@lists.openimageio.org >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> >> >> -- >> Larry Gritz >> l...@larrygritz.com >> >> >> >> >> _______________________________________________ >> Oiio-dev mailing list >> Oiio-dev@lists.openimageio.org >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> > _______________________________________________ > Oiio-dev mailing list > Oiio-dev@lists.openimageio.org > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > > > -- > Larry Gritz > l...@larrygritz.com > > > > > _______________________________________________ > Oiio-dev mailing list > Oiio-dev@lists.openimageio.org > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >
_______________________________________________ Oiio-dev mailing list Oiio-dev@lists.openimageio.org http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
