gmane.comp.video.openexr.devel

Re: ilmbase 1.0.2 Assertion `b.min == min && b.max ==?max' failed.

Andreas Metzler — 2012-04-15T06:10:41

[...]


Good morning,

libc6 2.11.3-3
linux-image-2.6.32-5-amd64 2.6.32-41squeeze2

I am running AMD64-kernel with 32bit userland, ilmbase has been
configured with --build=i486-linux-gnu.

thanks, cu andreas

Re: ilmbase 1.0.2 Assertion `b.min == min && b.max==?max' failed.

Andreas Metzler — 2012-04-14T16:40:36

[...]

FWIW Github does not build:
[...]
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../config -I.. -I../Iex -I../config
 -pipe -g -O2 -pthread -c IexMathFpu.cpp  -fPIC -DPIC -o .libs/IexMathFpu.o
IexMathFpu.cpp:116:15: error: 'uint16_t' does not name a type
IexMathFpu.cpp:125:8: error: variable or field 'setCw' declared void
IexMathFpu.cpp:125:8: error: 'uint16_t' was not declared in this scope

Adding '#include <stdint.h>' yields a new error:
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../config -I.. -I../Iex -I../config -pipe -g -O2 -pthread -c IexMathFpu.cpp  -fPIC -DPIC -o .libs/IexMathFpu.o
IexMathFpu.cpp: In function 'void Iex::FpuControl::restoreControlRegs(const ucontext_t&, bool)':
IexMathFpu.cpp:231:38: error: 'struct _libc_fpstate' has no member named 'cwd'
IexMathFpu.cpp:232:40: error: 'struct _libc_fpstate' has no member named 'mxcsr'

cu andreas

ilmbase 1.0.2 Assertion `b.min == min && b.max ==max' failed.

Andreas Metzler — 2012-04-14T12:01:13

Hello,

trying to build ilmbase 1.0.2 (with "#include <string.h>" added to
Imath/ImathMatrix.h) on current Debian sid produces this error on make check:

----------------------------
Testing box methods
    constructors for type V2s
    constructors for type V2i
[...]
    extendBy() point for type V2i
    extendBy() point for type V2f
lt-ImathTest: testBox.cpp:241: void {anonymous}::testExtendByPoint(const char*) [with T = Imath::Vec2<float>]: Assertion `b.min == min && b.max == max' failed.
/bin/bash: line 5:  2201 Aborted                 ${dir}$tst
FAIL: ImathTest
----------------------------
cvs head shows the same error.

cu andreas

Re: latest release?

Andreas Metzler — 2012-04-09T16:14:33

[...]

Thank you for the quick status update.

cu andreas

Re: latest release?

Piotr Stanczyk — 2012-04-09T15:20:34

Hi Andreas, 

That is still the plan. We were hoping to get python bindings for Imath bundled in 1.7.1, but we've run into some issues on the Windows side that are causing delays. Failing a successful outcome, we'll release those separately later on ...

Piotr




________________________________________
From: openexr-devel-bounces+pstanczyk=ilm.com< at >nongnu.org [openexr-devel-bounces+pstanczyk=ilm.com< at >nongnu.org] on behalf of Andreas Metzler [ametzler< at >downhill.at.eu.org]
Sent: 09 April 2012 06:10
To: Openexr-devel< at >nongnu.org
Subject: [Openexr-devel] latest release?

Hello,

I have been browsing over www.openexr.com. It curently states that
1.6.1 is the current stable release. The release announcement for 1.7.0
in 2010 said: "The aim is to make an official stable release, 1.7.1,
once any outstanding issues have been resolved."

Is this still planned? I see that e.g. Fedora or Suse are shipping
1.7.0.

thnks, cu andreas

--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to yo

latest release?

Andreas Metzler — 2012-04-09T13:10:23

Hello,

I have been browsing over www.openexr.com. It curently states that
1.6.1 is the current stable release. The release announcement for 1.7.0
in 2010 said: "The aim is to make an official stable release, 1.7.1,
once any outstanding issues have been resolved."

Is this still planned? I see that e.g. Fedora or Suse are shipping
1.7.0.

thnks, cu andreas

Re: Pre-compiled version for Window, MacOS and iOS

Piotr Stanczyk — 2012-03-26T16:43:03

Hi.

Currently we don't ship with any binaries for OS X, but I have build them regularily for 10.5 & 10.6.
There was also a recent thread regarding building for iOS that you might find useful.

Best

Piotr

________________________________
From: openexr-devel-bounces+pstanczyk=ilm.com< at >nongnu.org [openexr-devel-bounces+pstanczyk=ilm.com< at >nongnu.org] on behalf of Martin Côté [martin< at >triademedia.ca]
Sent: 26 March 2012 09:37
To: openexr-devel< at >nongnu.org
Subject: [Openexr-devel] Pre-compiled version for Window, MacOS and iOS

Hi,

I’m looking to use OpenEXR library through Adobe AIR Application. I saw within the download section that some pre-compiled version are there for Windows. Is there any “pre-compiled” for MacOS. I ask because I plan to create application that will work also on MacOS and iOS (iPad), but actually I’m programming in Windows environment and I don’t directly have access to a Mac Computer.

Thanks for your help.

Martin Côté, M. Arch.

TRIADE MEDIA INC.
2208, rue de l'Équateur |

Pre-compiled version for Window, MacOS and iOS

Martin Côté — 2012-03-26T16:37:21

Hi,

 

Im looking to use OpenEXR library through Adobe AIR Application. I saw
within the download section that some pre-compiled version are there for
Windows. Is there any pre-compiled for MacOS. I ask because I plan to
create application that will work also on MacOS and iOS (iPad), but actually
Im programming in Windows environment and I dont directly have access to a
Mac Computer.

 

Thanks for your help.

 

Martin Côté, M. Arch.

 

TRIADE MEDIA INC.

2208, rue de l'Équateur | Montréal | Québec | H4R 0H4

www.triademedia.ca

 

Ce courriel est confidentiel. Toute diffusion, utilisation ou copie de ce
message ou des renseignements qu'il contient par une personne autre que les
destinataires désignés est interdite. Si vous recevez ce courriel par
erreur, s.v.p. en aviser le plus rapidement possible l'expéditeur. Pensez à
l'environnement avant dimprimer ce courriel.

 

_______________________________________________
Openexr-devel mailing list
Openexr-devel< at >nongnu.org
https://lists.no

Re: Installing IlmBase,Zlib libraries for building OpenEXR in Visual Studio 2010?

James Burgess — 2012-03-23T21:48:29

The Deploy directory gets created up one level from the toplevel ilm-base and OpenEXR  folder, did you look there? Confused me the first time. Otherwise VS2010 worked as advertised for me.

- James

On Mar 23, 2012, at 2:39 PM, Stewart Dickson wrote:

Installing IlmBase,Zlib libraries for building OpenEXR in Visual Studio 2010?

Stewart Dickson — 2012-03-23T21:39:56

Hi,

I used Visual Studio 6/7 briefly, but am basically a n00b when it comes to developing on Windows.  (I come from Unix-land.)

In the OpenEXR source distribution, my Visual Studio 2010 converts the vc/vc8/OpenEXR/OpenEXR.sln to Visual Studio 2010
compatibility, but the resulting project directory structure doesn't seem to resemble that described in openexr-1.7.0/README.win32
E.g., I don't get directories called Deploy/bin/*, Deploy/include/*, Deploy/lib/*, I just see directories vc/vc8/OpenEXR/debug and
vc/vc8/OpenEXR/release, which are empty.  To make the IlmBase and ZLib libraries that I built available to Visual Studio 2010 for
building OpenEXR, can somebody please provide the missing instructions to translate README.win32 from vc7/8 to Visual Studio 2010?

Thanks,

-Stewart Dickson, http://us.imdb.com/Name?Stewart+Dickson

Re: C-API to setGlobalThreadCount();

Florian Kainz — 2012-03-19T21:43:51

There is no C API for setGlobalThreadCount().  If you are building
the IlmImf library yourself then you should be able to add a C
wrapper for the function yourself by modifying ImfCRgbaFile.cpp
and ImfCRgbaFile.h

Володя Володя wrote:

_______________________________________________
Openexr-devel mailing list
Openexr-devel< at >nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel

C-API to setGlobalThreadCount();

Володя Володя — 2012-03-16T00:32:44

Hi,
I'm just wandering if there is c-api to set up number go threads, or
how to call setGlobalThreadCount(); from c code?
Cheers,
Vlad

Re: "standard" for storing a depth map?

Paul Miller — 2012-03-14T22:19:57

Well, yeah. <sheepish grin>

We're creating depth "from nothing" here (think 2D->3D conversion) so 
the actual range is not based on any real world values. But I suppose it 
could. Let me think about that.

Re: Cross-compiling problem for iOS

Piotr Stanczyk — 2012-03-14T22:12:59

hmm interesting ... this is the first post I've seen on iOS deployment. 

I presume lines 58 and 59  of half.cpp looks like this to you:

58 HALF_EXPORT_CONST unsigned short half::_eLut[1 << 9] =
59 #include "eLut.h"

HALF_EXPORT_CONST should be defined in half.h as 


#if defined(OPENEXR_DLL)
    #if defined(HALF_EXPORTS)
#define HALF_EXPORT __declspec(dllexport)
    #else
#define HALF_EXPORT __declspec(dllimport)
    #endif
    #define HALF_EXPORT_CONST
#else
    #define HALF_EXPORT
    #define HALF_EXPORT_CONST const
#endif


Are you able to check to see if your code is in the right part of this macro expansion?

Piotr


________________________________________
From: openexr-devel-bounces+pstanczyk=ilm.com< at >nongnu.org [openexr-devel-bounces+pstanczyk=ilm.com< at >nongnu.org] on behalf of vd [vovik.revik< at >gmail.com]
Sent: 14 March 2012 14:33
To: openexr-devel< at >nongnu.org
Subject: [Openexr-devel] Cross-compiling problem for iOS

Hi,
I have a problem cross-compiling IlmBase with Xcode 4.31 for iOS i can build for

Re: "standard" for storing a depth map?

Florian Kainz — 2012-03-14T22:05:18

The two files in the OpenEXR sample images collection use 32-bit floats
for the Z channel and store world-space Z distances.  All Z values are
positive.  For pixels that are infinitely far away the Z channel contains
a positive floating-point infinity.

Paul Miller wrote:

Re: "standard" for storing a depth map?

Christian Bloch — 2012-03-14T21:56:36

I agree with Christopher. Normalizing is a bad idea, because it may not be consistent throughout the entire sequence. When you have a distant object travel through frame, or simply pan from an empty sky area to a cityscape the Z buffer will pump back and forth.
It's also unnecessary with 32-bit float.

We're saving the straight distance values. For the sake of a good default I configured our own pipeline with a factor of 0.1, just so a distance of 10 meters becomes a value of 1. So far that seems to be working great for most scenes.

I did setup Normalizing in an alternative pipeline (where Z is rendered separately for better AA control), but that requires the artists to visually pick the near and far values using OpenGL fog, and those values are kept consistent across the sequence.

.Christian Bloch

On Mar 14, 2012, at 2:41 PM, Christopher Horvath wrote:


_______________________________________________
Openexr-devel mailing list
Openexr-devel< at >nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-de

Re: "standard" for storing a depth map?

Christopher Horvath — 2012-03-14T21:41:04

If you're using 32-bit float for depth, why do you need to normalize at
all? Doesn't that defeat the purpose?

On Wed, Mar 14, 2012 at 2:38 PM, Paul Miller <paul< at >fxtech.com> wrote:

Re: "standard" for storing a depth map?

Paul Miller — 2012-03-14T21:38:29

Oh good idea. I'll be normalizing my values, but everything is float.

Cross-compiling problem for iOS

vd — 2012-03-14T21:33:32

Hi,
I have a problem cross-compiling IlmBase with Xcode 4.31 for iOS i can build for 
i386 emulator but i 
have following error on arm:
Please advise.

make  all-am
/bin/sh ../libtool --tag=CXX   --mode=compile 
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer
/usr/bin/g++ 
-DHAVE_CONFIG_H -I. -I../config -I../config   -pipe -arch armv7 -pipe 
-no-cpp-precomp 
-isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/
Developer/SDKs/
iPhoneOS5.
1.sdk -miphoneos-version-min=4.0 -D_THREAD_SAFE  -MT half.lo -MD -MP 
-MF .deps/half.Tpo 
-c -o 
half.lo half.cpp
libtool: compile:  
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/
Developer
/usr/bin/g++ 
-DHAVE_CONFIG_H -I. -I../config -I../config -pipe -arch armv7 -pipe 
-no-cpp-precomp
-isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/
Developer/SDKs/
iPhoneOS5.
1.sdk -miphoneos-version-min=4.0 -D_THREAD_SAFE -MT half.lo -MD -MP 
-MF .deps/half.Tpo 
-c

Re: "standard" for storing a depth map?

Christopher Horvath — 2012-03-14T20:46:35

If the depths are floating point values, they can simply be in "real world"
units, and do not need to be normalized.

However, 16-bit floats are not really sufficient for "real-world" depth
data, with units in feet, meters, or centimeters. When used as an input to
something like a depth-based fogging node in Nuke or Shake, you'll see
noticeable banding for a scene of the scale of a building or larger.

If you can make it so that the 'z' plane is 32-bit float, with the rest
being whatever precision you need for R,G,B,A - it will improve the
"depth-based fog in comp" kind of usage considerably.

If you do want to normalize the depths, you could put the near & far values
into the header's metadata.


On Wed, Mar 14, 2012 at 1:40 PM, Paul Miller <paul< at >fxtech.com> wrote:

Re: "standard" for storing a depth map?

Paul Miller — 2012-03-14T20:40:50

Thanks. Already have it hooked up in my I/O module. I don't suppose 
there is any standard to the depth range? Or is it common to have a 
scale/bias somewhere in each application?