headers
Michael Hayes | 10 Oct 07:11

Assertion error in line 52 of testQuarSlerp.cpp

Hi guys,

I am trying to compile OpenEXR 1.6.0 on FreeBSD 6.2-STABLE, with no success on 
the testing part. I can complete the build if I take the testing out of the 
make, but otherwise, it exits with the following error:

Testing quaternion spherical linear interpolation
  combinations of 90-degree rotations around x, y and z
Assertion failed: (equalWithAbsError (q1.v.x, q2.v.x, e)), function 
compareQuats, file testQuatSlerp.cpp, line 52.
Abort trap
FAIL: ImathTest
===================
1 of 1 tests failed
===================

I hope someone can help me fix this, as I am rusty on my C++ and I am assuming 
this means that somewhere the function is not coming up with a value that it 
expects. Anyone up to the challenge?

-Michael Hayes
Permalink | Reply | 2 comments |
headers
darby johnston | 10 Oct 18:29
Picon
Favicon

Re: Assertion error in line 52 of testQuarSlerp.cpp

--- Michael Hayes <mike09785 <at> bellsouth.net> wrote:

> I am trying to compile OpenEXR 1.6.0 on FreeBSD
> 6.2-STABLE, with no success on 
> the testing part. I can complete the build if I take
> the testing out of the 
> make, but otherwise, it exits with the following
> error:
> 
> Testing quaternion spherical linear interpolation
>   combinations of 90-degree rotations around x, y
> and z
> Assertion failed: (equalWithAbsError (q1.v.x,
> q2.v.x, e)), function 
> compareQuats, file testQuatSlerp.cpp, line 52.

Just tried this on a P4 running freebsd 6.2 and it
passed all the tests ok...

Out of curiosity, I tried printing out the error
thresholds:

e1 = 7.15256e-06
e2 = 7.15256e-05

Maybe these are different on your machine?

Darby
Permalink | Reply | 0 comments |
headers
Florian Kainz | 10 Oct 19:42

Re: Assertion error in line 52 of testQuarSlerp.cpp

Hi Michael,

if you have an older version of OpenEXR installed, try deleting its
header files (probably in /usr/local/include/OpenEXR) before building
OpenEXR 1.6.0.

The slerp() function was rewritten after the release of 1.4.0 in order
to improve its accuracy.  If testQuatSlerp.cpp somehow picks up an old
version of ImathQuat.h, then the confidence test will fail.  The error
limits in the test are too tight for the original slerp().

If removing older versions of OpenEXR doesn't help, then I'd be interested
in the following:

     - Processor type
     - Stack trace at the point where the assertion fails
     - Values of q1, q2 and e in function compareQuats()
     - Values of q1, q2, m, n and all local variables in testSlerp()

Florian

Michael Hayes wrote:
> Hi guys,
> 
> I am trying to compile OpenEXR 1.6.0 on FreeBSD 6.2-STABLE, with no success on 
> the testing part. I can complete the build if I take the testing out of the 
> make, but otherwise, it exits with the following error:
> 
> Testing quaternion spherical linear interpolation
>   combinations of 90-degree rotations around x, y and z
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michal Vyskocil | 25 Oct 11:56
Picon

Linkikng problem with gcc 4.3

Hi,

I've a problem with compiling OpenEXR using gcc 4.3. OpenEXR version is 1.6.0

g++ -shared -nostdlib /usr/lib64/gcc/x86_64-suse-linux/4.3.0/../../../../lib64/crti.o
/usr/lib64/gcc/x86_64-suse-linux/4.3.0/crtbeginS.o  .libs/ImfAttribute.o
.libs/ImfBoxAttribute.o .libs/ImfCRgbaFile.o .libs/ImfChannelList.o
.libs/ImfChannelListAttribute.o .libs/ImfFloatAttribute.o .libs/ImfFrameBuffer.o
.libs/ImfHeader.o .libs/ImfIO.o .libs/ImfInputFile.o .libs/ImfIntAttribute.o
.libs/ImfLineOrderAttribute.o .libs/ImfMatrixAttribute.o .libs/ImfOpaqueAttribute.o
.libs/ImfOutputFile.o .libs/ImfRgbaFile.o .libs/ImfStringAttribute.o .libs/ImfVecAttribute.o
.libs/ImfHuf.o .libs/ImfThreading.o .libs/ImfWav.o .libs/ImfLut.o .libs/ImfCompressor.o
.libs/ImfRleCompressor.o .libs/ImfZipCompressor.o .libs/ImfPizCompressor.o
.libs/ImfB44Compressor.o .libs/ImfMisc.o .libs/ImfCompressionAttribute.o
.libs/ImfDoubleAttribute.o .libs/ImfConvert.o .libs/ImfPreviewImage.o
.libs/ImfPreviewImageAttribute.o .libs/ImfVersion.o .libs/ImfChromaticities.o
.libs/ImfChromaticitiesAttribute.o .libs/ImfKeyCode.o .libs/ImfKeyCodeAttribute.o
.libs/ImfTimeCode.o .libs/ImfTimeCodeAttribute.o .libs/ImfRational.o
.libs/ImfRationalAttribute.o .libs/ImfFramesPerSecond.o .libs/ImfStandardAttributes.o
.libs/ImfStdIO.o .libs/ImfEnvmap.o .libs/ImfEnvmapAttribute.o .libs/ImfScanLineInputFile.o
.libs/ImfTiledInputFile.o .libs/ImfTiledMisc.o .libs/ImfTiledOutputFile.o
.libs/ImfTiledRgbaFile.o .libs/ImfTileDescriptionAttribute.o .libs/ImfTileOffsets.o
.libs/ImfRgbaYca.o .libs/ImfPxr24Compressor.o .libs/ImfTestFile.o  -L/usr/lib64 -lz
/usr/lib64/libImath.so /usr/lib64/libHalf.so /usr/lib64/libIex.so /usr/lib64/libIlmThread.so
-lpthread -L/usr/lib64/gcc/x86_64-suse-linux/4.3.0
-L/usr/lib64/gcc/x86_64-suse-linux/4.3.0/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64
-L/usr/lib64/gcc/x86_64-suse-linux/4.3.0/../../../../x86_64-suse-linux/lib
-L/usr/lib64/gcc/x86_64-suse-linux/4.3.0/../../.. -lstdc++ -lm -lc -lgcc_s
/usr/lib64/gcc/x86_64-suse-linux/4.3.0/crtendS.o
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brendan Bolles | 25 Oct 21:09
Favicon

Re: Efficient read of a single image channel, in a multi-channel image

On Jan 24, 2007, at 4:30 PM, Florian Kainz wrote:

> There is no particularly efficient way to read a single channel.
> The channels in the file are interleaved per scan line or per tile.
> This allows efficient random access to individual scan lines or tiles,
> as well as sequential reading of the entire image with no seek
> operations, but it precludes fast extraction of a single image  
> channel.

(saw this older post)

Thanks for clarifying, Florian.  I have a feature request for the  
distant future then: add the ability for files to be stored with  
channels in blocks instead of this interleaved method.  That is, if  
you think there would in fact be a speed advantage for reading a  
single channel this way.

I think for files that have any channels beyond RGBA, it is much more  
common to want to read just one channel at a time.  In fact, for a 50- 
channel file I can't think of anytime I'd want to read all 50  
channels simultaneously.  You generally have input nodes with a few  
channels requested per node.  Each node is getting called  
independently, so there's no way to load all the channels at once and  
then pass them to the different inputs.  At least in the software I'm  
using.

Brendan
Permalink | Reply | 1 comment |
headers
Florian Kainz | 26 Oct 04:00

Re: Efficient read of a single image channel, in a multi-channel image

Brendan Bolles wrote:
> On Jan 24, 2007, at 4:30 PM, Florian Kainz wrote:
> 
>> There is no particularly efficient way to read a single channel.
>> The channels in the file are interleaved per scan line or per tile.
>> This allows efficient random access to individual scan lines or tiles,
>> as well as sequential reading of the entire image with no seek
>> operations, but it precludes fast extraction of a single image  channel.
> 
> 
> (saw this older post)
> 
> Thanks for clarifying, Florian.  I have a feature request for the  
> distant future then: add the ability for files to be stored with  
> channels in blocks instead of this interleaved method.  That is, if  you 
> think there would in fact be a speed advantage for reading a  single 
> channel this way.
> 
> 
> I think for files that have any channels beyond RGBA, it is much more  
> common to want to read just one channel at a time.  In fact, for a 50- 
> channel file I can't think of anytime I'd want to read all 50  channels 
> simultaneously.  You generally have input nodes with a few  channels 
> requested per node.  Each node is getting called  independently, so 
> there's no way to load all the channels at once and  then pass them to 
> the different inputs.  At least in the software I'm  using.
> 
> 
> Brendan
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Sharpless | 30 Oct 14:27
Picon

illegal instruction trap in half test on AMD sempron

Building openexr for first time, using MSVC 8 under WinXP home SP2 on 2GB AMD sempron 2500+ box:
HalfTest fails with illegal instruction trap.  Disassembly listing:

    h2 += f1;
00401592  movzx       edx,word ptr [esp+0Ch]
00401597  mov         eax,dword ptr [__imp__toFloat (405008h)]
0040159C  movss       xmm0,dword ptr [eax+edx*4]
004015A1  cvtps2pd    xmm0,xmm0
004015A4  addsd       xmm0,mmword ptr [__real <at> 3ff0000000000000 (405270h)]
004015AC  push        ecx 
004015AD  cvtpd2ps    xmm0,xmm0
004015B1  lea         ecx,[esp+0Eh]
004015B5  movss       dword ptr [esp],xmm0
004015BA  call        half::half (401400h)
004015BF  mov         di,word ptr [eax]
    assert (h2 == 5);

PC points to the cvtpd2ps instruction.

Is there a known fix for this?

Thanks, Tom

_______________________________________________
Openexr-devel mailing list
Openexr-devel <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/openexr-devel
Permalink | Reply | 0 comments |
headers
Thomas Sharpless | 30 Oct 16:43
Picon

illegal instruction trap in IlmImfTest on AMD sempron 2500+

Building  with MSVC8 under WinXP home SP2 on 2GB sempron 2500+
Another illegal instruction trap; disassmbly listing (incl code bytes)...

write (T &out, double v)
{
004227B0 83 EC 14         sub         esp,14h
004227B3 A1 90 27 43 00   mov         eax,dword ptr [___security_cookie (432790h)]
004227B8 33 C4            xor         eax,esp
004227BA 89 44 24 10      mov         dword ptr [esp+10h],eax
    union {Int64 i; double d;} u;
    u.d = v;
004227BE F2 0F 10 44 24 1C movsd       xmm0,mmword ptr [esp+1Ch]
004227C4 56               push        esi  
004227C5 57               push        edi  
004227C6 F2 0F 11 44 24 08 movsd       mmword ptr [esp+8],xmm0

    unsigned char b[8];

PC -> movsd instruction.

HELP!


_______________________________________________
Openexr-devel mailing list
Openexr-devel <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/openexr-devel
Permalink | Reply | 0 comments |
headers
Thomas Sharpless | 30 Oct 19:45
Picon

Illegal instruction traps resolved

It turns out that my old Sempron 2500+ processor is one that does not support SSE2 instructions, and the OpenEXR VC8 projects have compiler flag /arch:SSE2.  Changing that to /arch:SSE fixed the problem.

_______________________________________________
Openexr-devel mailing list
Openexr-devel <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/openexr-devel
Permalink | Reply | 0 comments |

Gmane