openexr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Openexr-devel] Optimisation code path for reading images


From: Juri Abramov
Subject: Re: [Openexr-devel] Optimisation code path for reading images
Date: Tue, 18 Jun 2013 18:26:14 +0200

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:address@hidden
Sent: 18 June, 2013 18:16
To: Juri Abramov; Halfdan Ingvarsson
Cc: address@hidden; address@hidden
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 address@hidden
Sent: 18 June 2013 09:13
To: Halfdan Ingvarsson; Piotr Stanczyk
Cc: address@hidden; address@hidden
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: address@hidden [mailto:address@hidden] On Behalf Of Halfdan Ingvarsson
Sent: 18 June, 2013 18:06
To: Piotr Stanczyk
Cc: address@hidden; address@hidden
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 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 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.

 - ½

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


Hi,

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

We have a fix for handling these, which also extents to handling more general cases,  in a separate branch and will be releasing that once we have built 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
address@hidden
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, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]