Is there going to be one of these this year? Can't seem to find any
information on this as yet. Thanks
Piotr
Dr Piotr Stanczyk
R&D Digital Film
The Moving Picture Company
London, UK
___
Openexr-devel mailing list
Openexr-devel@nongnu
Hi all,
Just wandering what, if any, thoughts people have on having a standard EXIF
typed attribute.
I'm sure there are various implementations out there, but is it worth having a
common one?
Thanks,
Piotr
___
Openexr-devel mailing list
Openexr-d
ard" attributes
and EXIF data.
Are you looking for an OpenEXR attribute that encapsulates
he entire EXIF header?
Florian
Piotr Stanczyk wrote:
Hi all,
Just wandering what, if any, thoughts people have on having a
standard EXIF typed attribute. I'm sure there are various
impleme
u may have on the future
direction of OpenEXR.
Thanks,
Piotr
Florian Kainz wrote:
I would like to announce that Piotr Stanczyk is taking over the role
of project lead for OpenEXR. Starting today, Piotr will be responsible
for official releases of OpenEXR, maintaining the open-source code bas
Ger Hobbelt wrote:
I while back (few months) I posted a diff here which defined M_PI_2
for those platforms that haven't got it in the standard run-time lib.
Today I checked the current CVS state and I found I had forgotten to
report one additional line that needed fixing: see the diff below.
--
Thanks for the updates.
Piotr
Florian Kainz wrote:
ImfAcesFile.cpp has been updated.
Joseph Goldstone wrote:
The existing IlmImf/ImfAcesFile.cpp source contains:
const Chromaticities &
acesChromaticities ()
{
static const Chromaticities acesChr (V2f (0.7347,
0.2653),// red
Thanks for that Ger,
Nick and I will try to get this into the next release all being well.
Piotr
Ger Hobbelt wrote:
Erm, not really, but I can see what I can do regarding that. Isn't
that hard to do really - it just takes time.
Basic trick would be along these lines: get the vcproj files for
Larry Gritz wrote:
(Please excuse if this is a duplicate post. I think my previous one
bounced because I didn't send from the same email I use to subscribe
to the list.)
Using OpenEXR 1.6.1, I've had errors where the last few scanlines or
tiles don't seem to make it to the file I'm writing.
tile sizes except 512, but I thought
yesterday that there were some tile sizes that were okay.
Printfs in my code reveal that all WriteTile is being called for all
the tiles, and there are never any exceptions.
Piotr, I'll send you (off-list) one of the files.
-- lg
Piotr Stanczyk
Borislav Trifonov wrote:
I was moving my projects from Visual Studio 2005 to 2008. Since I had
built all my libraries with link time code generation, I had to
rebuild everything since VS2008 wouldn't take the old binaries.
OpenEXR now now longer works, despite me trying all sorts of changes
Hi Thomas,
Thanks for your interest; I have forwarded your questions to out legal
department for clarification on your points.
Piotr
Thomas Richter wrote:
Dear Sirs,
under which conditions does ILM release the OpenEXR example images
found http://www.openexr.com/downloads.html? Background f
Thanks for catching this one. I don't have ready access to 4.3 at the
mo, but will check this out and add to the repository.
Piotr
Jeff Clifford wrote:
Hi,
Just a small compilation issue to report (I'm using the latest version
of the OpenEXR source from the repository).
gcc 4.3.x doesn't
J.C. Roberts wrote:
Hello,
This is my first post to this mailing list, and I tried to RTFM for the
answer, but was unsuccessful. On neither savannah.nongnu.org nor
openexr.org could I find out the preferred way to submit patches?
If you'd be so kind to drop-kick me towards the docs/faq on this
Hi all,
There has been a recent disk failure at Savannah.
(http://lists.gnu.org/archive/html/savannah-users/2009-05/msg00023.html)
The good news is that it looks like the most recent stable back up is
from May 27th and I have requested that this be used for restoring the
source tree.
I've
An update; the CVS source tree is back up and appears to be working well.
Please let me know if you run into any problems.
Piotr
-Original Message-
From: openexr-devel-bounces+pstanczyk=ilm@nongnu.org on behalf of Piotr
Stanczyk
Sent: Wed 6/3/2009 10:42 AM
To: openexr-devel
Larry Gritz wrote:
Florian Kainz wrote:
I believe you are right, ther is no library version flag in the
header files. The "configure" script should be able to add a
version number to OpenEXRConfig.h.
The scenario is that I have a source package that I'd like other
people to be able to build
Thanks for forwarding ... I'll try it out with the Intel compiler here.
Piotr
Magnus Wrenninge wrote:
We're currently using Imath as our default math library for the
Field3D project (http://code.google.com/p/field3d/). The following was
submitted as a bug to us, so I thought I would forward it
Hi John,
That is indeed the plan, I'd like to have a firmer plan for the release
at the start of next year
In the meantime, would you be so kind as to send me the changes and I
will fold them in to the CVS tree and test out.
Many thanks in advance
Piotr
John Burnett wrote:
Hello,
Is
Let me look into this ...
Piotr
Stephan Menzel wrote:
Hi guys,
I am currently trying to get OpenEXR to run in a multiplatform 32/64
bit Windows and Linux environment. So far I made quite OK progress
with adopting your build system to windows and enabling 64bit support.
There's just a big pro
Good news. Could you mail out the changes you had to make - thanks.
Piotr
Stephan Menzel wrote:
Ger,
Works. Like. A. Charm.
Finally I can link ImageMagick.
Thank you so very much! You've saved me from despair in face of what
Microsoft considers a developer platform. Great stuff.
I strongly e
Hi Paul,
I haven't tried this for a while .. .I'll see if I can track down a test
system
Piotr
Paul Miller wrote:
On 3/12/2010 10:06 AM, Paul Miller wrote:
I can't seem to get IlmBase and OpenEXR to build with -arch x86_64 on OS
X using the 10.5 SDK.
Does anyone have a command-line that w
Paul Miller wrote:
On 3/12/2010 10:06 AM, Paul Miller wrote:
I can't seem to get IlmBase and OpenEXR to build with -arch x86_64 on OS
X using the 10.5 SDK.
Does anyone have a command-line that works for this?
I just downloaded the ilmbase-1.0.1.tar.gz package from the web site
but it won't b
Paul Miller wrote:
A qq for you: what machine are you building this on?
OS X 10.6
Also, in the "configure" file if you remove the following line (~16580)
CXXFLAGS="$CXXFLAGS -Wno-long-double"
and rebuild, does that work for you?
Yes, that DOES work! However, I need to build the 64 bit vers
Hi Jonathan,
The OpenEXR pages have indeed been static of late. Regarding CTL, this
is the link to the Academy pages:
http://www.oscars.org/science-technology/council/projects/ctl.html
which really is a gateway to (after reviewing license agreements):
http://sourceforge.net/projects/ampasctl/
T
has been used extensively in production and core
functionality has been in CVS for some time, we welcome any bug reports.
The aim is to make an official stable release, 1.7.1, once any
outstanding issues have been resolved.
The www.openexr.org pages will be updated shortly.
Regards
Piotr
Hi Rex,
Thanks for catching this ... I'm not sure I will be able to track down
an i686 machine in any reasonable time frame, anyone else have one
around they could verify / give it a spin in gdb?
Thanks
Piotr
On 08/11/2010 07:08 AM, Rex Dieter wrote:
building ilmbase-1.0.2 on fedora, and
this scope
make[2]: *** [testExtractEuler.o] Error 1
make[2]: Leaving directory `/home/sm/devel/ilmbase-1.0.2/ImathTest'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/home/sm/devel/ilmbase-1.0.2/ImathTest'
make: *** [check-recursive] Error 1
Does this help?
Cheers,
Stepha
gotcha ... I thought we had this one done too, good to catch these. If
you take that option out does it build and pass the tests?
Thanks
Piotr
On 08/13/2010 04:59 AM, Wesley Smith wrote:
Hi,
I just tried to build ilmbase on OSX. Make fails immediately with the
following message. Below is t
Thanks for those,
We made a recent scrub for 4.4 and 4.5 include checks and the fixes are
in the CVS head. These will be folded into 1.7.1.
Piotr
On 08/22/2010 10:47 AM, Campbell Barton wrote:
Hi, I got this error when building OpenEXR 1.7 on linux with GCC4.5.1
blurImage.cpp: In functi
Sounds like something we might get into 1.7.1 ... I'll add it to the list.
Thanks for highlighting this one.
Piotr
On 08/23/2010 10:23 AM, Benoit Leveau wrote:
I was thinking the same, as right now the safest way for us to use the
new version is to do that change in the library.
Basically my
1.7.1 is planned to be released?
Thanks!
Benoit
Piotr Stanczyk wrote:
Sounds like something we might get into 1.7.1 ... I'll add it to the
list.
Thanks for highlighting this one.
Piotr
On 08/23/2010 10:23 AM, Benoit Leveau wrote:
I was thinking the same, as right now the safest way for us
Moving this across to the developer list ...
Interesting that you do not have access rights ... what configure options did
you use? I take it IlmBase and OpenEXR built fine...
thanks
Piotr
From: openexr-user-bounces+pstanczyk=ilm@nongnu.org
[op
Hi Jospeh,
Thanks for the lowdown. I have heard something similar to the issue you
describe with building for 10.5 on 10.6. I will need to take a closer look at
this.
re -Wno-long-double, I thought we had tracked that one down, alas, I'll check
that.
There are a few other missing includes tha
Hi Nicholas,
I don't believe there is an API method to encrypt the pixel data in any way.
Piotr
From: openexr-devel-bounces+pstanczyk=ilm@nongnu.org
[openexr-devel-bounces+pstanczyk=ilm@nongnu.org] on behalf of Nicholas Yue
[yue.nicho...@
Hi,
I think Larry put in a request for this one; it is on the list for 1.7.1.
Piotr
From: openexr-devel-bounces+pstanczyk=ilm@nongnu.org
[openexr-devel-bounces+pstanczyk=ilm@nongnu.org] on behalf of James Bowman
[jamesb-...@excamera.com]
Sent: 20 Octobe
yes, I think that seems sensible. we'll fix this in time for 1.7.1
Piotr
From: openexr-devel-bounces+pstanczyk=ilm@nongnu.org
[openexr-devel-bounces+pstanczyk=ilm@nongnu.org] on behalf of Brendan
Bolles [bren...@fnordware.com]
Sent: 09 November 2
We have been thinking about similar ideas .. I would like to move off CVS for a
start.
re patches ... if you have a moment could you shoot me a quick email and let me
know which ones and I'll do a sweep - thanks
Piotr
From: openexr-devel-bounces+pstan
>From the Adobe website ...
"The supplemental OpenEXR Alpha plug-in provides an alternate method for
handling ‘A’ channel data when opening an OpenEXR file. Instead of directly
converting ‘A’ channel data to transparency (as the old OpenEXR plug-in does),
OpenEXR Alpha opens ‘A’ channel data as
Hi Daniel,
Thanks for the spot, all patched in.
Sending out a separate email re SC
Cheers
Piotr
From: openexr-devel-bounces+pstanczyk=ilm@nongnu.org
[openexr-devel-bounces+pstanczyk=ilm@nongnu.org] on behalf of Daniel
Kaneider [kaneiderdan...@gmail
Hi,
A little while ago the topic of CVS, and how to move past it, came up.
I am leaning towards git as the replacement, mainly over Hg. I'd like to hear
any potential pitfalls of either before we commit. Thanks.
Piotr
___
Openexr-devel mailing list
O
to perception of the wider acceptance of git over
Hg, but then perhaps this reflects my *nix centric view of the world :)
Piotr
From: Bob Friesenhahn [bfrie...@simple.dallas.tx.us]
Sent: 19 May 2011 14:50
To: Piotr Stanczyk
Cc: openexr-devel@nongnu.org
let me take a look at this today - thanks for including the patch
Piotr
From: openexr-devel-bounces+pstanczyk=ilm@nongnu.org
[openexr-devel-bounces+pstanczyk=ilm@nongnu.org] on behalf of Daniel
Kaneider [kaneiderdan...@gmail.com]
Sent: 20 June 2011 14:01
Open Source VFX "Beer of a Feather" at SIGGRAPH 2011
Informal meet-up for developers, contributors, and users of VFX-related open
source projects, including Alembic, Coretex, Field3D, OpenColorIO, OpenEXR,
OpenImageIO, Partio, Ptex, SeExpr, and more. Relax in Vancouver, enjoy a beer,
match fac
Hi Gresham,
Sorry for the long silence on this one...
The general story is that Weta have very kindly contributed their work on the
ODZ file format they developed with the intent of extending OpenEXR.
A number of parties have provided support in extending the current code base to
encompass th
hmm .. don't have a lion machine to test this on locally. Anyone else?
Could you post the log?
From: openexr-devel-bounces+pstanczyk=ilm@nongnu.org
[openexr-devel-bounces+pstanczyk=ilm@nongnu.org] on behalf of Nicholas Yue
[yue.nicho...@gmail.co
Hi Sebastian,
Not really. This is something we are exploring at the moment ...
Savannah is the official location of the code base:
http://savannah.nongnu.org/projects/openexr/
Thanks
Piotr
From: openexr-devel-bounces+pstanczyk=ilm@nongnu.org
[op
Thanks.
Those are fixed in the latest src tree; we have plans for 1.7.1 to include
those fixes as well as providing python bindings for Imath. I'll send out an
email once all is cleared.
We're also going to move over to git hub for code hosting; we'll be snapshoting
to the CVS repository on re
Hi Paul
hmm - that sounds about right. let me take a closer look in a mo ...
Piotr
From: openexr-devel-bounces+pstanczyk=ilm@nongnu.org
[openexr-devel-bounces+pstanczyk=ilm@nongnu.org] on behalf of Paul Miller
[p...@fxtech.com]
Sent: 13 Februa
Hi Sam,
We're very close to entering a (private) alpha stage.
At this point, the API is pretty solid, and we are starting to look
for a wider exposure to flush out any issues with the code base.
We've been talking to various third parties regarding their timeframes
and are optimistic about commitm
Hi Paul,
Would storing the depth samples in a 'Z' layer be sufficient for you needs?
If you have a number of them you wish to have in one file you could use the
layer functionality to distinguish between them, something along the lines of
"light1.z", "light2.z" etc
Piotr
___
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)
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@nongnu.org
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
___
18th June 2012
We're pleased to announce that the OpenEXR source code is moving to github.com.
You can browse, download and branch the code at www.github.com/openexr/openexr.
We're looking forward to taking advantage of the collaborative features
presented by git and github.com and of cour
18th June 2012
We're pleased to announce the first public Beta release of OpenEXR v2.
Development of OpenEXR v2 has been undertaken in a collaborative environment
(cf. previous github announcement) comprised of Industrial Light and Magic,
Weta Digital as well as a number of other contributo
enexr-devel-bounces+pstanczyk=ilm@nongnu.org
[openexr-devel-bounces+pstanczyk=ilm@nongnu.org] on behalf of Rex Dieter
[rdie...@math.unl.edu]
Sent: 19 June 2012 07:39
To: openexr-devel@nongnu.org
Subject: Re: [Openexr-devel] OpenEXR v2 news
Piotr Stanczyk wrote:
> We're pleased to
nongnu.org
Subject: Re: [Openexr-devel] OpenEXR v2 news
Piotr Stanczyk wrote:
> Hi,
>
> they should be there... I'll make explicit downloads today, but in the
> meantime, if select the tags, you should be able to see the .zip and
> .tar.gz options highlighted:
>
> https:
...@fnordware.com]
Sent: 19 June 2012 12:16
To: openexr-devel@nongnu.org
Cc: Piotr Stanczyk
Subject: Re: [Openexr-devel] OpenEXR v2 news
On Jun 18, 2012, at 10:07 AM, Piotr Stanczyk wrote:
> OpenEXR v2Beta.1 can be found at:
> https://github.com/openexr/openexr/tree/v2_beta.1
>
Cool!
And
Hi All,
Just a quick note to say that I received confirmation that the OpenEXR BOF will
be on Tuesday, August 7th at 2.30-4.00 in Room 507.
As always, there may be last minute changes and I'll send out notification
beforehand to confirm.
Hope to see you there.
Piotr
_
Certainly, the .exr extension is a valid one. The v2.0 library will read 1.x
images just fine; and if only the 1.x subset of features is used then the files
written will be identical to those written by 1.7.
It is worth bearing in mind that v2 is capable of writing multi-part images;
in such sc
For those of you attending SIGGRAPH 2012 in Los Angeles in August, we are
throwing a get-together for developers and users of VFX-specific open source
projects. This was a big hit last year, and a great way to put faces to the
names you see on the developer mail lists in a relaxing venue.
When
Hi,
The v2 branch in github has been tagged with v2.0.0.beta.2.
Most of the code changes centre around the introduction of the namespacing
mechanism to IlmBase libraries.
There are also a number of other small additions and fixes.
The corresponding tarballs will be uploaded shortly; github ge
Hi Andreas,
Thanks for the patches. I had a quick look at them and noticed that the '=='
operator has been replaced by '=' one. Could you provide a little more
information as to the rationale behind this.
Thanks again
Piotr
From: openexr-devel-boun
Tuesday, July 31st, 2012
OpenEXR v1.7.1 has been released and is available for download.
Tarballs can be obtained from the downloads section on github:
https://github.com/openexr/openexr/downloads
This release includes the following components:
OpenEXR: v1.7.1
IlmBase: v1.0.3
PyIlmBase: v
From: openexr-devel-bounces+pstanczyk=ilm@nongnu.org
[openexr-devel-bounces+pstanczyk=ilm@nongnu.org] on behalf of Piotr
Stanczyk [pstanc...@ilm.com]
Sent: 31 July 2012 15:36
To: openexr-devel@nongnu.org; openexr-annou...@nongnu.org
Subject: [Openexr-devel] OpenEXR 1.7.1 release
Tuesday
k=ilm@nongnu.org] on behalf of Rex Dieter
[rdie...@math.unl.edu]
Sent: 05 August 2012 19:20
To: openexr-devel@nongnu.org
Subject: Re: [Openexr-devel] OpenEXR 1.7.1 release
Piotr Stanczyk wrote:
> Tuesday, July 31st, 2012
>
> OpenEXR v1.7.1 has been released and is available for download.
>
Hi
sorry about that... It looks like an oversight on our part. I'll fix that.
From: openexr-devel-bounces+pstanczyk=ilm@nongnu.org
[openexr-devel-bounces+pstanczyk=ilm@nongnu.org] on behalf of Michal
Vyskocil [mvysko...@suse.cz]
Sent: 06 August 2
I'll take a look in a mo in the meantime, did you issue a bootstrap
command to regenerate the Makefiles?
Piotr
From: openexr-devel-bounces+pstanczyk=ilm@nongnu.org
[openexr-devel-bounces+pstanczyk=ilm@nongnu.org] on behalf of Larry Gritz
[l
2012 14:04
To: Piotr Stanczyk
Cc: openexr-devel@nongnu.org
Subject: Re: [Openexr-devel] Building custom OpenEXR
I just did
./configure --prefix=blah --with-ilmbase-prefix=blah
Is that not enough?
On Aug 14, 2012, at 10:33 AM, Piotr Stanczyk wrote:
> I'll take a look in a mo ...
I'll reproduce your steps in a moment. In the meantime, could I ask to see if
running bootstrap before the configure 'fixes' the installation issue?
Piotr
From: Larry Gritz [l...@larrygritz.com]
Sent: 14 August 2012 15:02
To: Piotr Stanc
Gritz [l...@larrygritz.com]
Sent: 14 August 2012 17:12
To: Piotr Stanczyk
Cc: openexr-devel@nongnu.org
Subject: Re: [Openexr-devel] Building custom OpenEXR
Yes, that did seem to fix it.
Is 'bootstrap' supposed to be the first step to building, after unpacking the
tarball or checking o
x27;s also prudent to do this if you are switching branches)
If you get the tarballs then you can omit the bootstrap command.
Piotr
From: Nick Rasmussen [nick.rasmus...@gmail.com]
Sent: 14 August 2012 19:02
To: Larry Gritz
Cc: Piotr Stanczyk; openexr-devel@nongn
interesting stuff there is a rudimentary support for Cmake already in the
v2 code base ... anyone having luck with that?
From: openexr-devel-bounces+pstanczyk=ilm@nongnu.org
[openexr-devel-bounces+pstanczyk=ilm@nongnu.org] on behalf of Boudew
Hi,
Out of interest, what boost version are people using most commonly? Anyone
hitting the dizzy heights of 1.50?
Cheers,
Piotr
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
Interesting ... what's the bug you mention?
I suspect that boost python is the rationale for many a projects dependency on
it.
Piotr
From: openexr-devel-bounces+pstanczyk=ilm@nongnu.org
[openexr-devel-bounces+pstanczyk=ilm@nongnu.org] on behalf of Richa
Hi Yogesh,
For more information about contributing please take a look at:
https://github.com/openexr/openexr/wiki/Developer-Information
Many thanks
Piotr
From: openexr-devel-bounces+pstanczyk=ilm@nongnu.org
[openexr-devel-bounces+pstanczyk=ilm...
Hey - I've not seen that before ... I'll see if I can replicate that at our end.
Are you writing scanlines or tiles?
From: openexr-devel-bounces+pstanczyk=ilm@nongnu.org
[openexr-devel-bounces+pstanczyk=ilm@nongnu.org] on behalf of Paul Miller
[p
: Re: [Openexr-devel] tips for maximizing write speed?
On 10/30/2012 4:29 PM, Paul Miller wrote:
> On 10/30/2012 3:57 PM, Piotr Stanczyk wrote:
>> Hey - I've not seen that before ... I'll see if I can replicate that
>> at our end.
>>
>> Are you writing scanlines
Hi Gerhard,
I've never had problems with writing files line by line, would you be able to
post a code snippet?
Thanks
Piotr
BTW - What OS are you running?
From: openexr-devel-bounces+pstanczyk=ilm@nongnu.org
[openexr-devel-bounces+pstanczyk=ilm@nongn
I presume this is with a v1 branch. Alas, there is not too much that can be
done.
V2 has support for multiparts so grouping those channels into separate parts
would be the way to go. In such a case the library can simply skip over the
parts that you are not requesting.
Piotr
___
Hi,
+1 on what Peter mentioned.
You can do one more thing with the --enable-namespaceversioning flag, it can
take an optional value.
For example, you may want to pass --enable-namespaceversioning=DNeg, in which
case the DNeg suffix will be used for the internal namespaces. (That should b
Hi All,
I've recently pushed a new branch of the v1.x code base that includes
optimisations for the reading of RGB(A) pixel data; many thanks to the folks at
Autodesk for this contribution. You can find the changes in the branch :
'iif-optimisations'
I'll be applying the deltas to the v2 code
Hi Chris,
I am working with the PM here to work that out as we speak. I should have date
by the end of the week.
The only question that is outstanding is whether there will be enough time to
integrate the speed up changes into the v2 code base.
Piotr
From: o
Hi Franco,
Hard to say without seeing more of the code/coontext, but if you wish to
changes the compression schemes, then you will first have to load+uncompress
the data into a intermediate buffer and then recompress with the new scheme of
your liking.
Other attributes, chromaticities for exam
Is this a plugin that is linked against a different version than the host app?
From: openexr-devel-bounces+pstanczyk=ilm@nongnu.org
[openexr-devel-bounces+pstanczyk=ilm@nongnu.org] on behalf of Paul Miller
[p...@fxtech.com]
Sent: 01 March 2013 05:
...@fxtech.com]
Sent: 01 March 2013 08:57
To: openexr-devel@nongnu.org
Subject: Re: [Openexr-devel] undefined symbol: _ZN9IlmThread5MutexD1Ev on exit
On 3/1/2013 10:45 AM, Piotr Stanczyk wrote:
> Is this a plugin that is linked against a different version than the host app?
No, the host app is linked w
Hi,
We have merged the optimisation work into the develop branch. As of right now,
I don't see any other tickets that we will tackle for the 2.0 release unless
they are real show stoppers; I haven't heard any off line as yet so please
holler now.
With that in mind, I'll be doing the last round
Hey Al,
Are you grabbing code from the develop branch?
There should be a input file method :
//---
// Check if SSE optimization is enabled
//
// Call after setFrameBuffer() to query whether optimized file decoding
/
hance, try timing just around the actual
read to isolate from the rest of work needed.
On 20/03/13 15:51, Piotr Stanczyk wrote:
Hey Al,
Are you grabbing code from the develop branch?
There should be a input f
Hi,
A quick update on the state of things in reference to the release of v2 code
base.
We have the tarballs of ilmbase, ilmimf, pyilmbase and viewers all good to go
and uploaded to the downloads area.
The openexr.com website updates are ready to go and I have the git tags
(v2.0.0_GM) ready to
Hey Al,
Is that on reading?
Piotr
From: openexr-devel-bounces+pstanczyk=ilm@nongnu.org
[openexr-devel-bounces+pstanczyk=ilm@nongnu.org] on behalf of Al Crate
[a...@dneg.com]
Sent: 02 April 2013 04:57
To: openexr-devel@nongnu.org
Subject: Re: [O
Hi Al,
I had a look and I can't seem to find any issues, which worries me as you may
be bumping into something not quite seen yet.
Could you give me an idea as to what you were doing to prompt the failure? Are
you reading existing imagery with a tool linked against v2.0?
Or are you writing ou
I was just having the same conversation yesterday...
I think I would like to see an abstraction where you can sub in your own
implementation with a fallback to the current one.
Anyone have strong thoughts / opinions on this? Is this something that people
would like to be able to configure at bu
the optimised path. That might
>> help debug the problem:
>>
>> // TODO-pk this disables optimization
>> // _data->optimizationMode._destination._format =
>> Imf::OptimizationMode::PIXELFORMAT_OTHER;
>>
>> Peter
>>
>>
>> On 04/03/2013 03:1
be a viable default option?
Piotr
From: Christopher Horvath [blackenc...@gmail.com]
Sent: 03 April 2013 09:17
To: Piotr Stanczyk
Cc: Peter Hillman; openexr-devel@nongnu.org
Subject: Re: [Openexr-devel] Thread safety
I think it should be a config-level dec
Hi,
You can rebuild the sources with the --enable-namespaceversioning=no which
will revert to the old behaviour. However, whilst the classes are indeed in
Imf_2_0, they should be visible in Imf also.
The file ImfNamespace.h contains the details of the mechanism
// The purpose of this file i
Hi,
That's great news; is GIMP all HDR these days?
A good place to start is with the documentation. The two documents to consider
are "The Technical Introduction" and "Reading and Writing Image Files". Both
are available as part of the distro www.github.com/openexr/openexr and on the
project w
Thanks for checking Peter, I'll follow this up.
Piotr
From: openexr-devel-bounces+pstanczyk=ilm@nongnu.org
[openexr-devel-bounces+pstanczyk=ilm@nongnu.org] on behalf of Peter Hillman
[pet...@wetafx.co.nz]
Sent: 10 April 2013 14:17
To: openexr-dev
Hey
Looks odd that it is looking for libIex.la here
libtool: link: cannot find the library `/usr/local/lib/libIex.la' or unhandled
argument `/usr/local/lib/libIex.la':
Do you see anything odd from running configure?
Also. it normally defaults to looking for .so's are there any other options you
Hi All,
I'd like to move to a model where developing new features or fixing bugs will
take place on separate branches. These will then be merged into "develop" once
the implementation is stable and approved.
Currently, we have the following feature branches:
* cmake-fixes
* export-fixes
* zippe
1 - 100 of 206 matches
Mail list logo
