Brilliant! Thanks!
It's still slow.
I'll send you a file off list.
On Wed, Nov 10, 2021 at 10:46 PM Larry Gritz <l...@larrygritz.com> wrote:
> oiiotool original.exr --mulc 0.0* --eraseattrib ".*"* -o black.exr
>
> But double check the timing -- just in case it is somehow the metadata
> that is messing with the performance!
>
>
> On Nov 10, 2021, at 1:26 PM, Daniel Flehner Heen <flehnerhee...@gmail.com>
> wrote:
>
> I created the black exr and it is indeed small. Still takes a long time
> extracting the channels, so it's good for testing.
> My only concern is that some of the metadata contains confidential
> information. Is there an easy way of wiping the custom metadata with
> otiotool?
>
> In parallel with writing this email, I'm checking with my supervisors if I
> can send you the image (preferably off list.)
>
> On Wed, Nov 10, 2021 at 9:55 PM Larry Gritz <l...@larrygritz.com> wrote:
>
>> Interesting! As long as there's some easily measurable perf difference
>> (like 2x is fine), I should be able to figure out what's going on. Though
>> it's weird that your original image is more like 30x.
>>
>> Let's try something else. Assuming your original image is not something
>> you can share, what about this:
>>
>> oiiotool original.exr --mulc 0.0 -o black.exr
>>
>> That should make the pixels black, but retain all the metadata, channel
>> names, and data types of the original that had a large performance
>> difference. It should be a small file (black compresses very well) and will
>> obviously contain no imagery that is secret.
>>
>> In one "part" of an exr file, all channels are either deep or flat, so
>> "deep" is all or none of the channels in that part/subimage.
>>
>>
>> On Nov 10, 2021, at 12:30 PM, Daniel Flehner Heen <
>> flehnerhee...@gmail.com> wrote:
>>
>> Hi, Larry!
>>
>> Thanks for looking into this. I created an image with IBA.noise() in 70
>> channels and there still is a performance difference.
>> Not that big though: 2.3 seconds (python) vs 0.9 (oiiotool)
>>
>> Not sure if it makes a difference, but the slow image has a mix of float
>> and half channels and is tiled 64x64.
>> Don't know exactly if any of the channels are deep. Will ImageBuf.deep
>> return True if any channel is deep?
>> a buf.deep call returns False.
>>
>>
>> On Wed, Nov 10, 2021 at 6:16 PM Larry Gritz <l...@larrygritz.com> wrote:
>>
>>> Well that sure is weird! Usually, both the python bindings and the
>>> oiiotool operation are pretty thin wrappers around the corresponding
>>> ImageBufAlgo function which is doing almost all the work. A big perf
>>> difference is not expected.
>>>
>>> Can I assume that this is reproducible by any 70 channel image? Like I
>>> can just use oiiotool to generate a black image and see a big speed
>>> disparity like this? Or is it in any way specific to the particular image?
>>>
>>> Wednesdays are pretty packed, but I'l try to take a look at this today
>>> if I can.
>>>
>>>
>>> On Nov 10, 2021, at 4:08 AM, Daniel Flehner Heen <
>>> flehnerhee...@gmail.com> wrote:
>>>
>>> Hi!
>>>
>>> I'm attempting to extract only the RGBA channels of an EXR with 70+
>>> channels.
>>>
>>> Using:
>>> oiiotool -i:ch=R,G,B,A /path/to/gigantic.exr -o manageable.exr
>>> takes about 8 seconds.
>>>
>>> In python (2.7 !caugh..):
>>> buf = oiio.ImageBuf('/path/to/gigantic.exr')
>>> obuf = oiio.ImageBufAlgo.channels(buf, ('R', 'G', 'B', 'A'))
>>> obuf.write('manageable.exr')
>>> takes 4+ minutes
>>>
>>> I tried only extracting one channel and it took the exact amount of
>>> time. I expect a performance hit using python but this seems a bit off. I
>>> suspect the python bindings are reading all the channels even though I'm
>>> asking for a specific few.
>>> I might of course be going about this completely wrong, in which case a
>>> pointer in the right direction would be highly appreciated :)
>>>
>>> Straight read and write of the same file is done quickly.
>>>
>>> Thanks!
>>>
>>> --
>>> -Daniel
>>> _______________________________________________
>>> 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
>>>
>>
>>
>> --
>> -Daniel
>> _______________________________________________
>> 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
>>
>
>
> --
> -Daniel
> _______________________________________________
> 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
>
--
-Daniel
_______________________________________________
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
