Will do, Cheers On Wed, 26 Feb 2020 at 6:25 PM, Larry Gritz <l...@larrygritz.com> wrote:
> 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> 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 > > > -- > 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
