| 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.
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 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
--
Larry Gritz
address@hidden
_______________________________________________
Openexr-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/openexr-devel
|