I think this is the solution needed for this issue:
https://github.com/OpenImageIO/oiio/pull/2987
> On May 26, 2021, at 11:40 PM, Larry Gritz <l...@larrygritz.com> wrote:
>
> Hi, Dave, sorry for the delay. Just busy.
>
> OK, looking at the file you sent me, the subimages=0 is a red herring because
> it's not really a multi-part openexr file at all. It's just one part, with 7
> channels: R, G, B, A, and MattesA.{red green,blue}.
>
> You are quite right, after the colorconvert, in the output the matte channels
> end up black for some reason. I am investigating.
>
>
>
>> On May 26, 2021, at 2:16 AM, Dave Walker <davewalker...@gmail.com
>> <mailto:davewalker...@gmail.com>> wrote:
>>
>> Hi Larry,
>>
>> I sent this message yesterday to your l...@larrygritz.zom
>> <mailto:l...@larrygritz.zom> email address but I wondered if you may block
>> unsolicited emails so I'm posting it here too. I did send a sample exr
>> yesterday to the same address but let me know if you'd like it resent...
>> Thanks!
>>
>>
>>
>> I appreciate you giving me a hand with this. I've taken it off the dev group
>> as I'd like to send you a sample exr.
>> I have tried the :subimages=0 option and I get similar results to my
>> original message.
>> Oddly, I did manage to get the 'correct' result out when I used:
>> oiiotool -a input.0001001.exr --colorconvert:subimages=0 "ACES - ACEScg"
>> "ACES - ACEScg" -o output.0001001.exr
>>
>> I was doing a test just to check my syntax... but as soon as I replace the
>> output colour space with either ACES - ACES2065-1 or Input - RED - Linear -
>> REDWideGamutRGB I get black in my channel matte channel again.
>> (Just a note that I also get the 'correct' result when I run oiiotool -a
>> input.0001001.exr -o output.0001001.exr performing no conversion)
>>
>> This is a screen shot from RV showing where the matte is found (this is from
>> the aces cg -> aces cg test above:
>> <image.png>
>>
>> And this second is just showing the empty channel. As I mentioned, the name
>> persists but the content does not. This file was created when I tested going
>> from Acescg to Red Linear Wide Gamut
>>
>> <image.png>
>>
>> I get the same result when viewing the files in Nuke too.
>>
>> I have attached a sample sourcefile exr for you to test with. (I can resend
>> this if you need) I'd be interested to see if you get the same results. You
>> should be able to see the red character matte in MatteA in this file.
>> (I'm aware there is also a low value matte in the blue channel as well -
>> this isn't a final file, just one I'm using for testing purposes)
>>
>> As I mentioned, I'm on 2.3.4dev on linux.
>>
>> Regarding colourspace converting the whole file or not, at the moment I'm
>> not sure which I'd rather do - my common sense tells me to just colorspace
>> convert the first RGB channels and simply pass through the mattes, but I
>> have often had strange requests from graders where they want the entire
>> contents of the file converted, so a working route to get to both options
>> would be preferable.
>> FYI - our working internal colourspace is always AcesCG and we convert to
>> Aces 2065-1 or other on delivery to grade. In the case of this test, the
>> client have asked to deliver in Red but have not specified the colour space
>> of the embedded mattes specifically.
>>
>> Many thanks for your help,
>> Dave
>>
>> On Mon, May 24, 2021 at 6:44 PM Larry Gritz <l...@larrygritz.com
>> <mailto:l...@larrygritz.com>> wrote:
>> Are the matte channels in different "parts"?
>>
>> I can see a potential dilemma being that without -a, only the first subimage
>> is converted and all the other subimages are dropped, yet with -a, it might
>> try to do the color conversion on every subimage (which is inappropriate,
>> you only want to convert the first one, right?).
>>
>> Are you aware of the `:subimages=...` modifier that applies to most oiiotool
>> commands? It enumerates (by name or by index) which subimages should have
>> the operation applied and which should simply be copied. For example,
>>
>> oiiotool -a inputname.0001001.exr --colorconvert:subimages=0 "ACES -
>> ACEScg" "ACES - ACES2065-1" -o outputname.0001001.exr
>>
>> will make the color conversion apply to the first subimage only, with the
>> others simply copied from input to output. Does that solve your problem?
>>
>> Some more information can be found here:
>> https://openimageio.readthedocs.io/en/v2.2.14.0/oiiotool.html#dealing-with-multi-subimage-multi-part-files
>>
>> <https://openimageio.readthedocs.io/en/v2.2.14.0/oiiotool.html#dealing-with-multi-subimage-multi-part-files>
>>
>> If this is not the proper diagnosis, then to help me understand the
>> structure of the file, is it possible for you to provide (privately is fine)
>> an example input file so I can try this?
>>
>>
>>> On May 24, 2021, at 5:43 AM, Dave Walker <davewalker...@gmail.com
>>> <mailto:davewalker...@gmail.com>> wrote:
>>>
>>> Hi,
>>> I seem to be having an issue that I would love to be able to solve with
>>> OIIO incorrectly passing through matte channels embedded into an exr.
>>>
>>> Briefly:
>>> We use Hiero to package up and deliver our EXRs from a timeline
>>> Hiero spawns a oiio process to convert the colorspace of the exr sequence
>>> to the one required by a client
>>>
>>> Sample executable:
>>> oiiotool -a inputname.0001001.exr --colorconvert "ACES - ACEScg" "ACES -
>>> ACES2065-1" -o outputname.0001001.exr
>>>
>>> When it comes to the exrs that also include mattes embedded, OIIO seems to
>>> strip them all out when we do a color conversion and leaves nothing but a
>>> black channel. The name does persist but the content does not.
>>> It converts the standard rgb channels perfectly but it seems to just remove
>>> the other channels (in this case called MATTEA with rgb mattes, MATTEB, etc)
>>>
>>> Consulting the docs shows -a should allow them to be passed through and
>>> subject to the same color conversion or not.
>>> This does indeed work when I don't do any colorspace conversion, however,
>>> as soon as I add
>>> --colorconvert "ACES - ACEScg" "ACES - ACES2065-1"
>>> the resulting exr just contains black in the matte channels.
>>>
>>> I have also tried :subimages=all, subimages=-all and targeting specific
>>> layers as in the docs, but sadly to no avail.
>>> Is there something I'm doing wrong here?
>>>
>>> The exrs are created using Nuke and I'm running v2.3.4 dev on linux. I can
>>> provide a sample exr if you need.
>>>
>>> Many thanks,
>>> Dave
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> Oiio-dev@lists.openimageio.org <mailto:Oiio-dev@lists.openimageio.org>
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>
>> --
>> Larry Gritz
>> l...@larrygritz.com <mailto:l...@larrygritz.com>
>>
>>
>>
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-dev@lists.openimageio.org <mailto:Oiio-dev@lists.openimageio.org>
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-dev@lists.openimageio.org <mailto:Oiio-dev@lists.openimageio.org>
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>
> --
> Larry Gritz
> l...@larrygritz.com <mailto: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
