Re: DWAA minimum tile size?

--===============0204344102017965472==
Content-Type: multipart/alternative; boundary="0000000000004e496c057b2dcb05"

--0000000000004e496c057b2dcb05
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey Larry -

What is the single channel named?

For tiled files, dwaa =3D=3D dwab, so you should hit the same issue with ei=
ther
case. There=E2=80=99s a couple of paths that lead to hitting zlib, and the =
channel
naming should tell us which that is.

My guess is there=E2=80=99s some degenerate case in the buffer sizing logic=
.

Karl

On Tue, Nov 20, 2018 at 9:49 PM Larry Gritz <[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 combinatio=
n
> 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
> [email protected]
>
>
>
>
>
> _______________________________________________
> Openexr-devel mailing list
> [email protected]
> https://lists.nongnu.org/mailman/listinfo/openexr-devel
>

--0000000000004e496c057b2dcb05
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div><div dir=3D"auto">Hey Larry -</div></div><div dir=3D"auto"><br></div><=
div dir=3D"auto">What is the single channel named?=C2=A0</div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">For tiled files, dwaa =3D=3D dwab, so you =
should hit the same issue with either case. There=E2=80=99s a couple of pat=
hs that lead to hitting zlib, and the channel naming should tell us which t=
hat is.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">My guess i=
s there=E2=80=99s some degenerate case in the buffer sizing logic.</div><di=
v dir=3D"auto"><br></div><div dir=3D"auto">Karl</div><div><br><div class=3D=
"gmail_quote"><div dir=3D"ltr">On Tue, Nov 20, 2018 at 9:49 PM Larry Gritz =
&lt;<a href=3D"mailto:[email protected]">[email protected]</a>&gt; wrote:<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">Here is a strange behavior (easy to =
repro for those of you who might have a copy of OIIO lying around):<br>
<br>
=C2=A0 =C2=A0 # works<br>
=C2=A0 =C2=A0 oiiotool --pattern checker 512x512 1 -d half -compression dwa=
a -tile 16 16 -o test.exr<br>
<br>
=C2=A0 =C2=A0 # fails<br>
=C2=A0 =C2=A0 oiiotool --pattern checker 512x512 1 -d half -compression dwa=
a -tile 8 8 -o test.exr<br>
<br>
Just writing a simple tiled 1-channel half exr file with dwaa (or dwab) com=
pression. It succeeds with 16x16 tiles but fails with 8x8, wherein writeTil=
es() throws an exception with the following message:<br>
<br>
=C2=A0 =C2=A0 &gt; Failed to write pixel data to image file &quot;test.bb70=
0d14.temp.exr&quot;. Data compression (zlib) failed.<br>
<br>
<br>
Curiously, if I instead make a 3-channel file,<br>
<br>
=C2=A0 =C2=A0 oiiotool --pattern checker 512x512 3 -d half -compression dwa=
a -tile 8 8 -o test.exr<br>
<br>
that succeeds (also fine with 4x4, 2x2, 1x1 tile size). Using zip compressi=
on is fine. I can only make it fail with the specific combination of 1 chan=
nel images + dwaa/dwab compression + tile size &lt; 16.<br>
<br>
Anybody have any insight, or has this bug been reported before?<br>
<br>
Here&#39;s the OIIO issue if anyone wants to follow up there or reference i=
t:<br>
<a href=3D"https://github.com/OpenImageIO/oiio/issues/1844" rel=3D"noreferr=
er" target=3D"_blank">https://github.com/OpenImageIO/oiio/issues/1844</a><b=
r>
<br>
--<br>
Larry Gritz<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a=
><br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Openexr-devel mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">Openexr-devel=
@nongnu.org</a><br>
<a href=3D"https://lists.nongnu.org/mailman/listinfo/openexr-devel" rel=3D"=
noreferrer" target=3D"_blank">https://lists.nongnu.org/mailman/listinfo/ope=
nexr-devel</a><br>
</blockquote></div></div>

--0000000000004e496c057b2dcb05--


--===============0204344102017965472==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Openexr-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/openexr-devel

--===============0204344102017965472==--