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 > <mailto: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 >> <mailto: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 >> <mailto: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 >>> <mailto: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 <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> >> >> >> -- >> -Daniel >> _______________________________________________ >> 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> > > > -- > -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
