That's pretty old, yeah. At least a couple years. Try the current supported release, 2.1, and see if that makes things better.
> On Feb 25, 2020, at 11:23 PM, Orion Holder-Monk <orionholderm...@gmail.com> > wrote: > > 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 > <mailto: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 >> <mailto: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 >> <mailto: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 >>> <mailto: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 >>> <mailto:l...@larrygritz.com>> wrote: >>> Proposed autotrim fix here: https://github.com/OpenImageIO/oiio/pull/2497 >>> <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 >>>> <mailto: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 >>>> >>>> <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 >>>>> <mailto: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 >>>>> <mailto: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 >>>>>> <mailto: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 >>>>>> >>>>>> <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 <mailto: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 <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> >>>>>> _______________________________________________ >>>>>> 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> >>>>> _______________________________________________ >>>>> 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> >>>> >>>> _______________________________________________ >>>> 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> >>> _______________________________________________ >>> 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> >> _______________________________________________ >> 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> > _______________________________________________ > 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
