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> wrote:
>
> Hi Larry,
>
> I sent this message yesterday to your 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
> 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
