Re: Optimisation code path for reading images

Juri Abramov <[email protected]> Tue, 18 Jun 2013 18:26:14 +0200
Newsgroups gmane.comp.video.openexr.devel,gmane.comp.video.openexr.user
Message-ID <[email protected]>
--===============3817050756272246693==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_D3359C70CFE7484199E06844F5A2185E2723CBD83DDEMAIL01nvidi_"

--_000_D3359C70CFE7484199E06844F5A2185E2723CBD83DDEMAIL01nvidi_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I'm afraid mine are under customer's NDA.
It is rather common though, the corruption was reported for alpha.

Juri

From: Piotr Stanczyk [mailto:[email protected]]
Sent: 18 June, 2013 18:16
To: Juri Abramov; Halfdan Ingvarsson
Cc: [email protected]; [email protected]
Subject: RE: [Openexr-devel] Optimisation code path for reading images

Is this something that was quite deterministic in behaviour?
(Does anyone have an example of a corrupted image?)

- Piotr
________________________________
From: Juri Abramov [[email protected]]
Sent: 18 June 2013 09:13
To: Halfdan Ingvarsson; Piotr Stanczyk
Cc: [email protected]<mailto:[email protected]>; openexr-devel@=
nongnu.org<mailto:[email protected]>
Subject: RE: [Openexr-devel] Optimisation code path for reading images
Hi Halfdan,

Yep, we ran into this one too. Was already the case for OpenEXR 1.6/1.7.
Would be good to know if it is fixed in 4.5.

Juri

From: [email protected]<mailto:openexr=
[email protected]> [mailto:openexr-devel-boun=
[email protected]] On Behalf Of Halfdan Ingvarsson
Sent: 18 June, 2013 18:06
To: Piotr Stanczyk
Cc: [email protected]<mailto:[email protected]>; openexr-devel@=
nongnu.org<mailto:[email protected]>
Subject: Re: [Openexr-devel] Optimisation code path for reading images

Also, compiling the EXR2.0 library using gcc 4.2/4.3/4.4 with -O3 results i=
n the PIZ compression code producing occasional garbage data (-O3 is the de=
fault for cmake release builds). The workaround was to build with -O2. gcc =
4.6 and up seem ok. I didn't test with gcc 4.5.

Unfortunately, I didn't have time to dig any deeper as to whether this was =
an actual optimizer bug, or whether there are some spurious assumptions in =
the code leading to it.

Just something to keep in mind.

 - =BD

On 13-06-17 09:35 PM, Piotr Stanczyk wrote:

Hi,

There have been a few usage cases reported that exercised parts of the opti=
mised reading code path which unfortunately revealed erroneous assumptions =
in the source.

We have a fix for handling these, which also extents to handling more gener=
al cases,  in a separate branch and will be releasing that once we have bui=
lt up more usage cycles.

In the meantime, however, a v2.0.1 release will be available shortly, which=
 disables the optimisation.

- Piotr



_______________________________________________

Openexr-devel mailing list

[email protected]<mailto:[email protected]>

https://lists.nongnu.org/mailman/listinfo/openexr-devel

________________________________
This email message is for the sole use of the intended recipient(s) and may=
 contain confidential information.  Any unauthorized review, use, disclosur=
e or distribution is prohibited.  If you are not the intended recipient, pl=
ease contact the sender by reply email and destroy all copies of the origin=
al message.
________________________________

--_000_D3359C70CFE7484199E06844F5A2185E2723CBD83DDEMAIL01nvidi_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso-8859-=
1">
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><meta name=3DGenerator content=3D"Microso=
ft Word 14 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#defa=
ult#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
	{font-family:PMingLiU;
	panose-1:2 2 5 0 0 0 0 0 0 0;}
@font-face
	{font-family:PMingLiU;
	panose-1:2 2 5 0 0 0 0 0 0 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
	{font-family:"\@PMingLiU";
	panose-1:2 2 5 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";
	color:black;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";
	color:black;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;
	color:black;}
p.msochpdefault, li.msochpdefault, div.msochpdefault
	{mso-style-name:msochpdefault;
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
span.htmlpreformattedchar0
	{mso-style-name:htmlpreformattedchar;
	font-family:Consolas;
	color:black;}
span.emailstyle20
	{mso-style-name:emailstyle20;
	font-family:"Verdana","sans-serif";
	color:#17365D;
	font-weight:bold;}
span.EmailStyle23
	{mso-style-type:personal-reply;
	font-family:"Verdana","sans-serif";
	color:#17365D;
	font-weight:bold;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";
	color:black;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body bgcolor=3Dwhite lang=3DEN-US=
 link=3Dblue vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>=
<b><span style=3D'font-size:10.0pt;font-family:"Verdana","sans-serif";color=
:#17365D'>I&#8217;m afraid mine are under customer&#8217;s NDA. <o:p></o:p>=
</span></b></p><p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font=
-family:"Verdana","sans-serif";color:#17365D'>It is rather common though, t=
he corruption was reported for alpha.<o:p></o:p></span></b></p><p class=3DM=
soNormal><b><span style=3D'font-size:10.0pt;font-family:"Verdana","sans-ser=
if";color:#17365D'><o:p>&nbsp;</o:p></span></b></p><p class=3DMsoNormal><b>=
<span style=3D'font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1=
7365D'>Juri<o:p></o:p></span></b></p><p class=3DMsoNormal><b><span style=3D=
'font-size:10.0pt;font-family:"Verdana","sans-serif";color:#17365D'><o:p>&n=
bsp;</o:p></span></b></p><div><div style=3D'border:none;border-top:solid #B=
5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=3DMsoNormal><b><span style=
=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'>Fr=
om:</span></b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-se=
rif";color:windowtext'> Piotr Stanczyk [mailto:[email protected]] <br><b>Se=
nt:</b> 18 June, 2013 18:16<br><b>To:</b> Juri Abramov; Halfdan Ingvarsson<=
br><b>Cc:</b> [email protected]; [email protected]<br><b>Subje=
ct:</b> RE: [Openexr-devel] Optimisation code path for reading images<o:p><=
/o:p></span></p></div></div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><div>=
<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Tahoma","=
sans-serif"'>Is this something that was quite deterministic in behaviour?<b=
r>(Does anyone have an example of a corrupted image?)<o:p></o:p></span></p>=
<div><p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Taho=
ma","sans-serif"'><o:p>&nbsp;</o:p></span></p><div><p class=3DMsoNormal><sp=
an style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>- Piotr<o:p=
></o:p></span></p></div></div><div><div class=3DMsoNormal align=3Dcenter st=
yle=3D'text-align:center'><hr size=3D3 width=3D"100%" align=3Dcenter></div>=
<div id=3DdivRpF863779><p class=3DMsoNormal style=3D'margin-bottom:12.0pt'>=
<b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:=
</span></b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif=
"'> Juri Abramov [[email protected]]<br><b>Sent:</b> 18 June 2013 09:13<b=
r><b>To:</b> Halfdan Ingvarsson; Piotr Stanczyk<br><b>Cc:</b> <a href=3D"ma=
ilto:[email protected]">[email protected]</a>; <a href=3D"mailt=
o:[email protected]">[email protected]</a><br><b>Subject:</b>=
 RE: [Openexr-devel] Optimisation code path for reading images</span><o:p><=
/o:p></p></div><div><div><p class=3DMsoNormal><b><span style=3D'font-size:1=
0.0pt;font-family:"Verdana","sans-serif";color:#17365D'>Hi Halfdan,</span><=
/b><o:p></o:p></p><p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;f=
ont-family:"Verdana","sans-serif";color:#17365D'>&nbsp;</span></b><o:p></o:=
p></p><p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"=
Verdana","sans-serif";color:#17365D'>Yep, we ran into this one too. Was alr=
eady the case for OpenEXR 1.6/1.7.</span></b><o:p></o:p></p><p class=3DMsoN=
ormal><b><span style=3D'font-size:10.0pt;font-family:"Verdana","sans-serif"=
;color:#17365D'>Would be good to know if it is fixed in 4.5.</span></b><o:p=
></o:p></p><p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-fam=
ily:"Verdana","sans-serif";color:#17365D'>&nbsp;</span></b><o:p></o:p></p><=
p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Verdana=
","sans-serif";color:#17365D'>Juri</span></b><o:p></o:p></p><p class=3DMsoN=
ormal><b><span style=3D'font-size:10.0pt;font-family:"Verdana","sans-serif"=
;color:#17365D'>&nbsp;</span></b><o:p></o:p></p><div><div style=3D'border:n=
one;border-top:solid windowtext 1.0pt;padding:3.0pt 0in 0in 0in;border-colo=
r:-moz-use-text-color -moz-use-text-color;-moz-border-top-colors: none;-moz=
-border-right-colors: none;-moz-border-bottom-colors: none;-moz-border-left=
-colors: none;-moz-border-image: none'><p class=3DMsoNormal><b><span style=
=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'>Fr=
om:</span></b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-se=
rif";color:windowtext'> <a href=3D"mailto:openexr-devel-bounces+gabramov=3D=
[email protected]">[email protected]=
rg</a> [<a href=3D"mailto:openexr-devel-bounces+gabramov=3Dnvidia.com@nongn=
u.org">mailto:[email protected]</a>] <=
b>On Behalf Of </b>Halfdan Ingvarsson<br><b>Sent:</b> 18 June, 2013 18:06<b=
r><b>To:</b> Piotr Stanczyk<br><b>Cc:</b> <a href=3D"mailto:openexr-user@no=
ngnu.org">[email protected]</a>; <a href=3D"mailto:openexr-devel@nong=
nu.org">[email protected]</a><br><b>Subject:</b> Re: [Openexr-devel]=
 Optimisation code path for reading images</span><o:p></o:p></p></div></div=
><p class=3DMsoNormal>&nbsp;<o:p></o:p></p><div><p class=3DMsoNormal>Also, =
compiling the EXR2.0 library using gcc 4.2/4.3/4.4 with -O3 results in the =
PIZ compression code producing occasional garbage data (-O3 is the default =
for cmake release builds). The workaround was to build with -O2. gcc 4.6 an=
d up seem ok. I didn't test with gcc 4.5.<br><br>Unfortunately, I didn't ha=
ve time to dig any deeper as to whether this was an actual optimizer bug, o=
r whether there are some spurious assumptions in the code leading to it.<br=
><br>Just something to keep in mind.<br><br>&nbsp;- =BD<br><br>On 13-06-17 =
09:35 PM, Piotr Stanczyk wrote:<o:p></o:p></p></div><blockquote style=3D'ma=
rgin-top:5.0pt;margin-bottom:5.0pt'><div><p class=3DMsoNormal style=3D'marg=
in-bottom:12.0pt'><span style=3D'font-size:10.0pt;font-family:"Tahoma","san=
s-serif"'><br>Hi, <br><br>There have been a few usage cases reported that e=
xercised parts of the optimised reading code path which unfortunately revea=
led erroneous assumptions in the source. <br><br>We have a fix for handling=
 these, which also extents to handling more general cases,&nbsp; in a separ=
ate branch and will be releasing that once we have built up more usage cycl=
es. <br><br>In the meantime, however, a v2.0.1 release will be available sh=
ortly, which disables the optimisation.</span><o:p></o:p></p><div><p class=
=3DMsoNormal style=3D'margin-bottom:12.0pt'><span style=3D'font-size:10.0pt=
;font-family:"Tahoma","sans-serif"'>&nbsp;</span><o:p></o:p></p><div><p cla=
ss=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-s=
erif"'>- Piotr</span><o:p></o:p></p></div></div></div><p class=3DMsoNormal =
style=3D'margin-bottom:12.0pt'><br><br><o:p></o:p></p><pre>________________=
_______________________________<o:p></o:p></pre><pre>Openexr-devel mailing =
list<o:p></o:p></pre><pre><a href=3D"mailto:[email protected]" targe=
t=3D"_blank">[email protected]</a><o:p></o:p></pre><pre><a href=3D"h=
ttps://lists.nongnu.org/mailman/listinfo/openexr-devel" target=3D"_blank">h=
ttps://lists.nongnu.org/mailman/listinfo/openexr-devel</a><o:p></o:p></pre>=
</blockquote><p class=3DMsoNormal>&nbsp;<o:p></o:p></p></div><div><div clas=
s=3DMsoNormal align=3Dcenter style=3D'text-align:center'><hr size=3D3 width=
=3D"100%" align=3Dcenter></div></div><div><p class=3DMsoNormal>This email m=
essage is for the sole use of the intended recipient(s) and may contain con=
fidential information.&nbsp; Any unauthorized review, use, disclosure or di=
stribution is prohibited.&nbsp; If you are not the intended recipient, plea=
se contact the sender by reply email and destroy all copies of the original=
 message. <o:p></o:p></p></div><div><div class=3DMsoNormal align=3Dcenter s=
tyle=3D'text-align:center'><hr size=3D3 width=3D"100%" align=3Dcenter></div=
></div></div></div></div></div></body></html>=

--_000_D3359C70CFE7484199E06844F5A2185E2723CBD83DDEMAIL01nvidi_--


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

--===============3817050756272246693==--