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