Ah, might be the release I’m on then. I’m on 1.8. Probably a good time to just fully update.
On Wed, 26 Feb 2020 at 6:21 PM, Larry Gritz <l...@larrygritz.com> wrote: > I'm not seeing that behavior. Using the file you originally attached, > > $ oiiotool -info -v utils_test_input.1001.exr > Reading utils_test_input.1001.exr > utils_test_input.1001.exr : 2163 x 1141, 4 channel, half openexr > 7 subimages: 2163x1141 [h,h,h,h], 2163x1141 [f], 2163x1141 [f,f,f], > 2163x1141 [h,h,h], 2163x1141 [h,h,h], 2163x1141 [h,h,h], 2163x1141 [h,h,h] > ... > > $ oiiotool -a --autotrim utils_test_input.1001.exr -o out.exr > $ iinfo -v out.exr > out.exr : 2163 x 1141, 4 channel, half openexr > 7 subimages: 2163x1141 [h,h,h,h], 2163x1141 [f], 2163x1141 [f,f,f], > 2163x1141 [h,h,h], 2163x1141 [h,h,h], 2163x1141 [h,h,h], 2163x1141 [h,h,h] > > > So I'm getting the original set of data types in the output subimages as > well. > I tested against the current master. Haven't looked at old releases yet. > > > > On Feb 25, 2020, at 11:08 PM, Orion Holder-Monk <orionholderm...@gmail.com> > wrote: > > 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 > > > -- > 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
