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 > <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 > 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
