OpenEXR developer list

Re: forgotten to submit one additional fix for M_PI_2 support for platforms that don't have this in std headers

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.
>
> --- ../../1original/OpenEXR/src/IlmBase/ImathTest/testQuat.cpp
> 2007-10-20 03:05:41.000000000 +0200
> +++ IlmBase/ImathTest/testQuat.cpp      2008-06-17 08:27:13.000000000 +0200
> @@ -38,6 +38,7 @@
>  #include "ImathMatrixAlgo.h"
>  #include "ImathFun.h"
>  #include "ImathLimits.h"
> +#include "ImathPlatform.h" /* [i_a] M_PI_2 */
>  #include <iostream>
>  #include <cassert>
>  #include <cmath>
>
>
>
>   
Hi Ger,

I'll add that in.

Thanks,

Piotr

(Continue reading)

headers

Ger Hobbelt | 2 Aug 00:36

Re: forgotten to submit one additional fix for M_PI_2 support for platforms that don't have this in std headers

> I'll add that in.

Great!

Next thing that's on my list is MSVC2005 OpenEXR builds for Win64
(64-bit AMD64 / Itanium), but that'll take several (4 to 8) weeks more
as I am still testing the DLLs and the patched CreateDLL tool in those
64-bit environments, which have a few quirks. Are you interested in
that sort of stuff when it's gone past the current alpha stage over
here? If yes, CreateDLL has seen some significant changes which might
not be all that easy to see with a regular 'diff -u': if you like to
see it, can you give me a hint of what you'd like to see
(tech-)documentation- or other-wise to come with that? I ask now
because I've the option to include that in the overall planning at
this early stage. 

--

-- 
Met vriendelijke groeten / Best regards,

Ger Hobbelt

--------------------------------------------------
web: http://www.hobbelt.com/
 http://www.hebbut.net/
mail: ger <at> hobbelt.com
mobile: +31-6-11 120 978
--------------------------------------------------

headers

Ger Hobbelt | 2 Aug 02:17

Re: forgotten to submit one additional fix for M_PI_2support for platforms that don't have this in std headers

On Sat, Aug 2, 2008 at 12:57 AM, Nick Porcino <nporcino <at> ilm.com> wrote:
> If you like I'd be happy to review the code changes to CreateDLL. Just
> the code (no diff please) would be fine at first.

Good! I'll make a note to add a wee bit of info on what I did to it
and why / what for. I'll include that bit of (ahem) documentation with
the code when the Win32+Win64 tests here turn out 'stable'. No use in
bothering you with multiple versions and subtle bugs which I need to
fix anyhow.

Given the priorities and issues over here, please forgive me for
taking several weeks before posting the goods. This bit is kinda
'lurking in between'.

Thanks for OpenEXR (and the CreateDLL idea: saves me a bundle of
hassle with some of my other DLLs here, some of which were starting to
become a maintenance nightmare without it  )

Take care,

Ger

--

-- 
Met vriendelijke groeten / Best regards,

Ger Hobbelt

--------------------------------------------------
web: http://www.hobbelt.com/
 http://www.hebbut.net/

(Continue reading)

headers

Nicholas Yue | 26 Aug 15:13

Adding/updating attribute to existing OpenEXR file

Hi,

    I am writing a tool to add custom attributes a collection of 
existing OpenEXR files.

    Looking at the API, I have found methods to retrieve the headers 
from the ImfRgbaFile object but they are const.

    What are the best practice way of updating/adding attributes to 
existing OpenEXR files?

Regards

headers

Ken McGaugh | 26 Aug 16:46

Re: Adding/updating attribute to existing OpenEXR file

The exrstdattr tool that comes with openexr does a similar thing, so you 
could look at how it is done there.  In short it does the following:

   InputFile in (inFileName);
   Header header = in.header();
   // insert additional attributes to header here
   OutputFile out (outFileName, header);
   out.copyPixels(in);

--Ken

Nicholas Yue wrote:
> Hi,
>
>    I am writing a tool to add custom attributes a collection of 
> existing OpenEXR files.
>
>    Looking at the API, I have found methods to retrieve the headers 
> from the ImfRgbaFile object but they are const.
>
>    What are the best practice way of updating/adding attributes to 
> existing OpenEXR files?
>
> Regards
>

headers

Nicholas Yue | 26 Aug 22:07

Re: Adding/updating attribute to existing OpenEXR file

Ken McGaugh wrote:
> The exrstdattr tool that comes with openexr does a similar thing, so 
> you could look at how it is done there.  In short it does the following:
>
>    InputFile in (inFileName);
>    Header header = in.header();
>    // insert additional attributes to header here
>    OutputFile out (outFileName, header);
>    out.copyPixels(in);
>
> --Ken
 From the help message of exrstdattr

        'the program cannot edit an image file "in place" '

I am trying to avoid another copy as I am writing a small app to update 
comments and other production specific attributes on lots of rendered 
sequences.

I'll hunt around further.

Thanks Ken.

Regards

headers

Florian Kainz | 26 Aug 23:20

Re: Adding/updating attribute to existing OpenEXR file

The attributes in an OpenEXR file are tightly packed.  Any edit
that adds or removes an attribute or that changes the size of
an attribute requires copying the file.  In principle changing
the value of an attribute without changing its size can be done
in place, but the IlmImf library does not currently support this.

The copyPixels() operation in Ken's example is pretty fast because
it directly copies the pixels in compressed form without expanding
and recompressing the data.

Florian

headers

Joseph Goldstone | 26 Aug 22:55

Bringing IlmAcesFile.cpp into accord with recent events

The existing IlmImf/ImfAcesFile.cpp source contains:

const Chromaticities & acesChromaticities () { static const Chromaticities acesChr (V2f (0.7347, 0.2653), // red V2f (0.0000, 1.0000), // green V2f (0.0001, -0.0770), // blue V2f (0.3200, 0.3350)); // white return acesChr; }but these were revised as the ACES document was finalized (http://stcatp.org/, join, and when accepted go to the Downloads folder). The new ACES neutral chromaticity is now x = 0.32168, y = 0.33767; and for what it's worth, the primaries are spec'd to five places to the right of the decimal, matching the precision of the neutrals.{ static const Chromaticities acesChr (V2f (0.73470, 0.26530), // red V2f (0.00000, 1.00000), // green V2f (0.00010, -0.07700), // blue V2f (0.32168, 0.33767)); // white return acesChr; }

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

headers

Ger Hobbelt | 26 Aug 23:23

Re: Adding/updating attribute to existing OpenEXR file

I don't believe there's a possibility to add to your OpenEXR headers
and NOT have to rewrite your files.
And then rewriting (having to move the pixel data in each file) in
file is probably as costly as writing to another file, then 'mv'
moving it over the old one, unless you use memory mapped I/O -- which
I don't know if it is supported by the OpenEXR lib; it might or it
might not.

Reasoning:

Given the OpenEXR file format (headers are at start of file; see also
file layout PDF documentation) 'in-file' adding of extra attributes
would mean enlarging the header.
(I can safely assume you're not working on a platform which supports
'record insertion' in regular files   (VMS/RMS can IIRC,
UNIX/Windows definitely can not))

Enlarging the header size would mean you'll have to rewrite the file
anyway and it doesn't matter all that much if it's done by your
run-time library code or by your own (though a straight binary copy of
the pixel data _will_ be the fastest when using memory mapped I/O, but
I haven't dug that deep in the OpenEXR lib to know if you can get it
to spit out byte offsets to find the 'end-of-header' ==
'start-of-pixel-data' and just memmove() that pixel data on your own.)

My EUR 0.02, hope it helps,

Ger

On Tue, Aug 26, 2008 at 10:07 PM, Nicholas Yue <yue.nicholas <at> gmail.com> wrote:
> From the help message of exrstdattr
>
>       'the program cannot edit an image file "in place" '
>
> I am trying to avoid another copy as I am writing a small app to update
> comments and other production specific attributes on lots of rendered
> sequences.
>
> I'll hunt around further.
>
> Thanks Ken.
>
> Regards
>
>
>
> _______________________________________________
> Openexr-devel mailing list
> Openexr-devel <at> nongnu.org
> http://lists.nongnu.org/mailman/listinfo/openexr-devel
>
>

--

-- 
Met vriendelijke groeten / Best regards,

Ger Hobbelt

--------------------------------------------------
web: http://www.hobbelt.com/
 http://www.hebbut.net/
mail: ger <at> hobbelt.com
mobile: +31-6-11 120 978
--------------------------------------------------

headers

Florian Kainz | 26 Aug 23:43

Re: Bringing IlmAcesFile.cpp into accord with recent events

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
> 	     V2f (0.0000,  1.0000),	// green
> 	     V2f (0.0001, -0.0770),	// blue
> 	     V2f (0.3200,  0.3350));	// white
> 
>     return acesChr;
> }
> 
> but these were revised as the ACES document was finalized (http://stcatp.org/, join, and when accepted
go to the Downloads folder). The new ACES neutral chromaticity is now x = 0.32168, y = 0.33767; and for what
it's worth, the primaries are spec'd to five places to the right of the decimal, matching the precision of
the neutrals.
> 
> {
>     static const Chromaticities acesChr 
> 	    (V2f (0.73470,  0.26530),	// red
> 	     V2f (0.00000,  1.00000),	// green
> 	     V2f (0.00010, -0.07700),	// blue
> 	     V2f (0.32168,  0.33767));	// white
> 
>     return acesChr;
> }
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Openexr-devel mailing list
> Openexr-devel <at> nongnu.org
> http://lists.nongnu.org/mailman/listinfo/openexr-devel

6	February 2012
2	January 2012
2	November 2011
8	September 2011
12	August 2011
5	July 2011
2	June 2011
18	May 2011
15	April 2011
15	January 2011
9	November 2010
9	October 2010
6	September 2010
34	August 2010
4	June 2010
6	May 2010
31	March 2010
5	February 2010
12	December 2009
2	November 2009
2	October 2009
11	September 2009
11	July 2009
18	June 2009
4	May 2009
23	March 2009
5	February 2009
7	January 2009
4	December 2008
6	November 2008
18	October 2008
10	September 2008
11	August 2008
4	July 2008
19	June 2008
9	May 2008
8	April 2008
11	March 2008
12	February 2008
11	January 2008
30	December 2007
13	November 2007
9	October 2007
3	September 2007
26	August 2007
2	July 2007
11	June 2007
33	May 2007
11	April 2007
47	March 2007
9	February 2007
35	January 2007
49	December 2006
22	October 2006
23	September 2006
19	August 2006
17	July 2006
27	June 2006
11	May 2006
15	April 2006
29	March 2006
23	February 2006
55	January 2006
22	December 2005
17	November 2005
17	October 2005
10	September 2005
15	August 2005
48	July 2005
18	June 2005
14	May 2005
20	April 2005
91	March 2005
51	February 2005
27	January 2005
13	December 2004
54	November 2004
45	October 2004
57	September 2004
74	August 2004
17	July 2004
52	June 2004
58	May 2004
21	April 2004
35	March 2004
34	February 2004
112	January 2004
39	December 2003
31	November 2003
45	October 2003
9	September 2003
25	August 2003
25	July 2003
18	June 2003
16	May 2003
57	April 2003
116	March 2003
16	February 2003
58	January 2003
2	March 2002

Mon	Tue	Wed	Thu	Fri	Sat	Sun

				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	31