Funny you should ask.
As it turns out, in that original example I posted, a 3-channel image will be
default be named R,G,B and a 1-channel image will default to "Y".
Right after I send the message, I remembered that certain channel names get a
different treatment under dwaa, and tried naming the one channel "R":
# still fails, even with channel name "R"
oiiotool --pattern checker 512x512 1 -d half -chnames R -compression dwaa
-tile 8 8 -o test.exr
# still passes, even with a channel named "Y"
oiiotool --pattern checker 512x512 3 -d half -chnames Y,G,B -compression
dwaa -tile 8 8 -o test.exr
Also, remember that even with one "Y" channel, it worked fine for 16x16 tiles,
but hit the assertion when smaller.
Oh, but wait, I just tried one more combination!
# 3 channel fails! But only if all at least 2 channels are non-RGB? Still
works with 16x16 tiles.
oiiotool --pattern checker 512x512 3 -d half -chnames Y,X,B -compression
dwaa -tile 8 8 -o test.exr
I can transfer this to a GI "Issue" if you prefer. I tried the mail list first
thinking that maybe somebody was going to tell me it's a known problem or that
I'm obviously doing something wrong rather than it being a bug.
> On Nov 21, 2018, at 6:44 AM, Karl Rasche <[email protected]> wrote:
>
> Hey Larry -
>
> What is the single channel named?
>
> For tiled files, dwaa == dwab, so you should hit the same issue with either
> case. There’s a couple of paths that lead to hitting zlib, and the channel
> naming should tell us which that is.
>
> My guess is there’s some degenerate case in the buffer sizing logic.
>
> Karl
>
> On Tue, Nov 20, 2018 at 9:49 PM Larry Gritz <[email protected]
> <mailto:[email protected]>> wrote:
> Here is a strange behavior (easy to repro for those of you who might have a
> copy of OIIO lying around):
>
> # works
> oiiotool --pattern checker 512x512 1 -d half -compression dwaa -tile 16
> 16 -o test.exr
>
> # fails
> oiiotool --pattern checker 512x512 1 -d half -compression dwaa -tile 8 8
> -o test.exr
>
> Just writing a simple tiled 1-channel half exr file with dwaa (or dwab)
> compression. It succeeds with 16x16 tiles but fails with 8x8, wherein
> writeTiles() throws an exception with the following message:
>
> > Failed to write pixel data to image file "test.bb700d14.temp.exr". Data
> compression (zlib) failed.
>
>
> Curiously, if I instead make a 3-channel file,
>
> oiiotool --pattern checker 512x512 3 -d half -compression dwaa -tile 8 8
> -o test.exr
>
> that succeeds (also fine with 4x4, 2x2, 1x1 tile size). Using zip compression
> is fine. I can only make it fail with the specific combination of 1 channel
> images + dwaa/dwab compression + tile size < 16.
>
> Anybody have any insight, or has this bug been reported before?
>
> Here's the OIIO issue if anyone wants to follow up there or reference it:
> https://github.com/OpenImageIO/oiio/issues/1844
> <https://github.com/OpenImageIO/oiio/issues/1844>
>
> --
> Larry Gritz
> [email protected] <mailto:[email protected]>
>
>
>
>
>
> _______________________________________________
> Openexr-devel mailing list
> [email protected] <mailto:[email protected]>
> https://lists.nongnu.org/mailman/listinfo/openexr-devel
> <https://lists.nongnu.org/mailman/listinfo/openexr-devel>
--
Larry Gritz
[email protected]
_______________________________________________
Openexr-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/openexr-devel
