Thanks for the responses. Appreciate the insight. For now with the python code, I will look to implement in a similar way to the trim, and possibly move similar sized images into their own multipart image. I can also post it to the Foundry and Autodesk and see what they say, but also check some other apps I use gets tripped up by the different display windows.
Thanks again, Orion On Tue, 25 Feb 2020 at 8:00 AM, Larry Gritz <l...@larrygritz.com> wrote: > It's entirely possible that the reason I implemented oiiotool --trim as > the union across parts is because I knew or discovered at the time that > there were widely-used apps out there that would get gummed up if the > windows didn't match on all the parts. > > The --autotrim issue of only considering the first image is separate and > is a true bug, I will fix that right away. > > -- lg > > > On Feb 24, 2020, at 12:55 PM, Marco Meyer <m...@marcomeyer-vfx.de> wrote: > > Had a silimar observation when trying creating autotrimmed multiparts and > ultimately stuck with creating a union data window for all subimages so > every app is happy with it. > > An interesting thing I noticed was that Beachball multipart example from > openexr ( > https://github.com/AcademySoftwareFoundation/openexr-images/tree/master/Beachball > ) > also can't be read in nuke and throws the 'Reader did not set bounding > box' error, because it includes one subimage "whitebarmask.mask" that has a > different data window. > So I while I think openexr itself encourages datawindows per subimage, > some of the apps unfortunately don't know how to handle it. > > One could assume the app developers use the official exr examples for the > most basic compatibility testing... but here we are :) > > > On Sun, 2020-02-23 at 23:09 -0800, Larry Gritz wrote: > > Aha, I see, I believe that oiiotool --autotrim sets the trim based on the > first subimage (which is definitely wrong and I will fix right away), and > --trim seems to trim all subimages to the union of the nonzero regions of > all subimages (suboptimal, see below). > > It seems as if my assumption on --trim was that the different parts (what > we call subimages) had to share the same data windows. In rereading the > openexr docs now, it looks like that is not the case. Does anybody more > familiar with OpenEXR want to comment? > > I'm really not sure what's up with RV and Nuke, though, but I wonder if > they, too, are assuming that the data window will always be the same for > all parts? (Is anybody from Autodesk or Foundry reading and can check?) > > Fixing --autotrim to work the same as --trim, rather than incorrectly trim > all parts to the nonzero portion of the first part, is a no-brainer. > > However, fixing --trim/--autotrim to trim each part individually... I do > worry that this might result in files that are unreadable by other apps. > > -- lg > > > On Feb 23, 2020, at 7:01 PM, Orion Holder-Monk <orionholderm...@gmail.com> > wrote: > > Hi Dev team > > I've just been trying to implement the auto-trim tool for multi-part exrs > from oiiotool in a python set of tools. > Reason I'm doing it is currently if I was to use oiiotool -i > multipart_input.exr -a --autotrim -o multipart_output.exr, it will change > all my parts to match the spec of the first part (so cropping to the first > images visible pixels and change the data format etc). > > My implementation (below) is not raising any errors from oiio, but what > happens is that I'm getting an 'incomplete image' warning in RV (although > can see each image correctly) and a 'Reader did not set bounding box' error > in Nuke. > > If I set the crop roi to be consistent for every part instead of unique > per part, it creates the image fine and no warnings come up. > > Any help or suggestions would be greatly appreciated. (and if there's a > simple oiiotool command that I could use as an alternative, please do say) > And in terms of build, I am using 1.8.7.3, but have tested with 2.1 as > well and get the same result. > The below code if ran as a file will run with `python autotrim.py --input > multipart_input.exr --output multipart_output.exr` > I've also attempted to attach an example file to run it on, but it may be > too big. > Thanks! > Orion > > Code below: > > import OpenImageIO as oiio > import argparse > # Current build is OpenImageIO-1.8.7.3 > > parser = argparse.ArgumentParser(description='Autotrim multi-part exrs') > parser.add_argument('--input', default='', help='Input filepath') > parser.add_argument('--output', default='', help='Output filepath') > args = parser.parse_args() > > def write_multipart_exr(out_image_path, buf_list, spec_list): > """ > With an ordered list of ImageBuf's and correlating list of spec's this > will go through and write to the out_image_path. > """ > out_img = oiio.ImageOutput.create(out_image_path) > out_img.open(out_image_path, tuple(spec_list)) > > for s in range(len(spec_list)): > img_buf = buf_list[s] > if s > 0: > > append_success = out_img.open(out_image_path, spec_list[s], > oiio.ImageOutputOpenMode.AppendSubimage) #"AppendSubImage" > for 2.1 > if not append_success: print out_img.geterror() > > pixels = img_buf.get_pixels(oiio.FLOAT) > > write_result = out_img.write_image(pixels) > if not write_result: print out_img.geterror() > out_img.close() > > def _autotrim_buffer(image_buffer): > new_spec = image_buffer.nativespec() > > roi = oiio.get_roi(new_spec) > > # If all the parts get given the same ROI to crop, the exr works fine > new_roi = oiio.ImageBufAlgo.nonzero_region(image_buffer, roi) > > if new_roi.npixels == 0: > > new_roi = oiio.ROI(roi.xbegin, roi.xbegin + 1, roi.ybegin, roi.ybegin + 1, > roi.zbegin, roi.zbegin + 1, > roi.chbegin, roi.chend) > > new_buffer = oiio.ImageBuf(new_spec) > > result = oiio.ImageBufAlgo.crop(new_buffer, image_buffer, new_roi) > > if not result: raise OpenImageIOException(new_buffer.geterror()) > return new_buffer > > def autotrim(image_path, output_image_path): > image_path = str(image_path) > output_image_path = str(output_image_path) > image_buffer = oiio.ImageBuf(image_path) > > buffer_list = [] > spec_list = [] > nsubimages = image_buffer.nsubimages > for n in range(nsubimages): > img_buff = oiio.ImageBuf(image_path, n, 0) > > new_buff = _autotrim_buffer(img_buff) > > spec = new_buff.spec() > > buffer_list.append(new_buff) > > spec_list.append(spec) > > write_multipart_exr(output_image_path, buffer_list, spec_list) > > autotrim(args.input, args.output) > > Cheers! > Orion > > This e-mail and any attachments are intended only for use by the > addressee(s) named herein and may contain confidential information. If you > are not the intended recipient of this e-mail, you are hereby notified any > dissemination, distribution or copying of this email and any attachments is > strictly prohibited. If you receive this email in error, please immediately > notify the sender by return email and permanently delete the original, any > copy and any printout thereof. The integrity and security of e-mail cannot > be guaranteed. > <utils_test_input.1001.exr>_______________________________________________ > 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
