So, if you run oiiotool -i multipart_input.exr -a --autotrim -o multipart_output.exr with that exr and inspect the normals channel in both images you will see that the input.exr pixel data format is float, whereas the output becomes half. Basically all the subimages in this case are being converted to 'half' even if they were originally 'float'.
On Wed, Feb 26, 2020 at 7:04 AM Larry Gritz <l...@larrygritz.com> wrote: > What do you mean by change data format? > > > On Feb 25, 2020, at 10:58 PM, Orion Holder-Monk <orionholderm...@gmail.com> > wrote: > > Thanks Larry, > > That all looks good for the behavior of the autotrim argument. In my case, > I *may* actually get away with some of these subimages being cropped to > the first images non-zero pixels (although obviously not completely > desirable), but having them change data format through the oiiotool is > actually what causes issues for me. Is that the expected behavior with the > tool? Fine if it is, as I can work around that and is more out of interest. > > Apart from that, thanks again, really appreciate it. > Cheers > Orion > > > On Wed, 26 Feb 2020 at 5:23 AM, Larry Gritz <l...@larrygritz.com> wrote: > >> Proposed autotrim fix here: https://github.com/OpenImageIO/oiio/pull/2497 >> >> For now, I'm keeping the --trim and --autotrim behavior to only trim to >> the union of nonzero regions of all the parts, since several apps that may >> read the exrs later have trouble with differing data windows per pert. >> >> It is possible for me to make an optional argument to --trim (off by >> default) that would allow it to make separate, tightest possible data >> windows, on a per-part basis. This would only be safe to do if you were >> absolutely sure that the only readers consuming the resulting files were ok >> with it. If this is important to anybody, let me know and I can add this >> feature. >> >> -- lg >> >> >> On Feb 24, 2020, at 2:52 PM, Jonathan Egstad <jegs...@earthlink.net> >> wrote: >> >> For reference here’s the check code in OpenEXR which verifies matching >> displayWindows when you author a MultiPart file: >> >> MultiPartOutputFile::Data::checkSharedAttributesValues() line 408: >> >> https://github.com/AcademySoftwareFoundation/openexr/blob/master/OpenEXR/IlmImf/ImfMultiPartOutputFile.cpp >> >> As others have said there’s no similar restriction on dataWindows >> matching and it’s the apps reading MultiPart exrs that choke. >> >> -j >> >> On Feb 24, 2020, at 1:13 PM, Orion Holder-Monk <orionholderm...@gmail.com> >> wrote: >> >> 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 >> >> >> _______________________________________________ >> 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
