That sure feels like a bug, and I can't think of any reason why doing the
forced read would make any difference.
> On Jan 31, 2022, at 12:10 PM, Nathan Rusch <nathanru...@gmail.com> wrote:
>
> Hello all,
>
> I think I may have found a bug with the ImageBufAlgo::nonzero_region under
> some specific circumstances, but I wanted to lay it out here before opening a
> Github issue, just in case this is (or would be) considered a known bug or
> “wontfix” edge-case.
>
> To start with, let's manufacture an EXR with mixed channel formats:
>
> oiiotool --pattern black 640x480 3 --chnames "R,G,B" --pattern
> fill:left=0.1,0.1,0.1:right=0,0.75,0 640x480 3 --chnames "foo.R,foo.G,foo.B"
> --chappend -d half -d foo.R=float -d foo.G=float -d foo.B=float -o
> multi_dtype.exr
>
> From there, I use the Python bindings to read the image and compute the
> non-zero ROI:
>
> buf = OpenImageIO.ImageBuf('multi_dtype.exr')
> nonzeroROI = OpenImageIO.ImageBufAlgo.nonzero_region(buf)
> print(nonzeroROI)
> This prints the expected result: 0 640 0 480 0 1 0 6
>
> However, if I do the same thing but force a read of the image before
> computing the non-zero region, I get an incorrect result:
>
> buf = OpenImageIO.ImageBuf('multi_dtype.exr')
> buf.read(force=True)
> nonzeroROI = OpenImageIO.ImageBufAlgo.nonzero_region(buf)
> print(nonzeroROI)
> In this case, the printed result is: 0 640 0 360 0 1 0 6
>
> Now, I understand that ImageBuf.read is most likely promoting the half
> channels to float so they can all be stored in a single buffer, which is
> fine, but the fact that the subsequent nonzero_region returns an incorrect
> result definitely seems like a bug (e.g. the IBA function doesn’t “know” that
> the underlying data for the half channels has been promoted to float).
>
> Other notes:
>
> This is using OIIO 2.2.19.0. I looked at the 2.3.11.0 source for ImageBuf,
> and it didn’t seem like the forced-reading code had changed significantly,
> but there’s a chance this is hitting a corner-case that has been addressed
> already in newer versions.
> I don’t have a build of 2.3 handy to test, so I need to try to get one built,
> but I’m wondering if maybe you can confirm whether something might have
> changed that could affect this in the meantime.
> I’m not sure whether this issue is specific to the file structure and pixel
> data in my example (half-float black RGB channels, with additional non-zero
> float channels).
> I’m not sure if this is just a bug with ImageBufAlgo::nonzero_region, or if
> this could point to a more widespread source of unexpected behaviors when
> using ImageBufAlgo on ImageBufs with “local” storage.
> Let me know if this is in fact a bug and I'll open a proper issue for it.
>
> Thanks for any insights.
>
> -Nathan
>
> _______________________________________________
> 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
