headers
Florian Kainz | 8 Dec 23:11

OpenEXR source tree reorganization

In preparation for the next development release,
we are rearranging the OpenEXR source tree a bit.
If you have write access to OpenEXR's CVS repository,
please don't check anything in for the next couple
of days.

Florian
Permalink | Reply | 0 comments |
headers
Ton Roosendaal | 11 Dec 11:11
Favicon

Multi-layer multi-pass files

Hi OpenEXR team,

I'm wrapping up work for our next Blender release, which supports  
multi-layer multi-pass rendering now. We will make use of openexr files  
for writing/reading an entire set of layers/passes in a single file.

In May this year I've noticed a bug in the channel naming, which didn't  
suppport longer nested names than 32 characters in total. I didn't get  
an answer to that, is this fixed?

Other question; is there a naming standard for layers/passes in files?  
Or, how can we make sure that such files open nicely in other  
applications that support openexr?

Thanks,

-Ton-

On 12 May, 2006, at 13:06, Ton Roosendaal wrote:

> Hi,
>
> It looks like channel names in files are truncated to be 31 chars  
> (plus trailing zero) maximum. That seems to be defined in ImfName.h.
>
> In Blender we make use of the features as described in  
> ImfChannelList.h, for image files with many channels to group them  
> into nested layers. Unfortunately the maximum of 32 chars seems to be  
> for the total name, not for the individual nexted parts.
>
(Continue reading)

Permalink | Reply | 502 comments |
headers
Piotr Stanczyk | 12 Dec 12:06
Picon

EXIF meta data attributes in headers

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
Permalink | Reply | 9 comments |
headers
Florian Kainz | 13 Dec 00:33

Re: Multi-layer multi-pass files

Hi Ton,

The 32-character limit on channel and attribute names is still in place.
we are just days away from our next OpenEXR release; channel names with
arbitrary length will have to wait until the version after that.
Increasing the maximum length of channel names does break backwards
compatibility.  We'll have to find some way to deal with this problem.

Currently there is no standard naming scheme for layers.  Would you like
to suggest one?

Florian

Ton Roosendaal wrote:
> Hi OpenEXR team,
> 
> I'm wrapping up work for our next Blender release, which supports  
> multi-layer multi-pass rendering now. We will make use of openexr files  
> for writing/reading an entire set of layers/passes in a single file.
> 
> In May this year I've noticed a bug in the channel naming, which didn't  
> suppport longer nested names than 32 characters in total. I didn't get  
> an answer to that, is this fixed?
> 
> Other question; is there a naming standard for layers/passes in files?  
> Or, how can we make sure that such files open nicely in other  
> applications that support openexr?
> 
> Thanks,
>
(Continue reading)

Permalink | Reply | 502 comments |
headers
Lars Borg | 13 Dec 06:10
Picon
Favicon

Re: EXIF meta data attributes in headers

Hi, Piotr,

I believe EXIF metadata lacks copyright, author, etc. There are other 
sets. Maybe you should pick a superset or expandable set?

Lars

At 3:06 AM -0800 12/12/06, 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 implementations out there, but is it 
>worth having a common one?
>
>
>Thanks,
>
>Piotr
>
Permalink | Reply | 0 comments |
headers
Florian Kainz | 13 Dec 07:02

Re: EXIF meta data attributes in headers

Hi Piotr,

what ѕort kind of information do you need to store?
As far as I can tell, there's quite a bit of overlap
between OpenEXR's "optional standard" 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 implementations out there, but is it worth having a common one?
> 
> 
> Thanks,
> 
> Piotr
> 
> 
> _______________________________________________
> Openexr-devel mailing list
> Openexr-devel <at> nongnu.org
> http://lists.nongnu.org/mailman/listinfo/openexr-devel
> 
>
(Continue reading)

Permalink | Reply | 7 comments |
headers
Piotr Stanczyk | 13 Dec 11:30
Picon

Re: EXIF meta data attributes in headers

Hi Florian,

As you point out, the optional standard attributes contain iso,  
exposure time attributes ... I was thinking about whether it would be  
suitable to encapsulate the entire EXIF structure in a single attribute

I was prompted to think about this when noticing that we occasionally  
read in digital camera source images as OpenEXR files into shake, do  
some light processing and write out Jpeg & Tiff files out of shake  
that need to have the Exif data in place.
The current implementation writes out the tags that we want in the  
Exif output file one-by-one. This works fine, but I was wandering if  
its worth keeping the data in the pipeline....

Piotr

On 13 Dec 2006, at 06:02, Florian Kainz wrote:

> Hi Piotr,
>
> what ѕort kind of information do you need to store?
> As far as I can tell, there's quite a bit of overlap
> between OpenEXR's "optional standard" attributes
> and EXIF data.
>
> Are you looking for an OpenEXR attribute that encapsulates
> he entire EXIF header?
>
> Florian
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Wolf | 13 Dec 22:25

Re: EXIF meta data attributes in headers

Hello,

Sorry for being a bit late on the thread...

On Wed, 13 Dec 2006 07:02:26 +0100, Florian Kainz <kainz <at> ilm.com> wrote:

> what ѕort kind of information do you need to store?
> As far as I can tell, there's quite a bit of overlap
> between OpenEXR's "optional standard" attributes
> and EXIF data.
>
> 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 implementations out there, but is it worth having a common one?

Has anybody looked at XMP? http://www.adobe.com/products/xmp/
It may not be as common as EXIF, but it does have Adobe and the W3C behind it.

Cheers,
Mike

--

-- 
db&w GbR
Seyffer Str. 34
70197 Stuttgart

http://www.db-w.com
http://www.infinimap.com
(Continue reading)

Permalink | Reply | 5 comments |
headers
Chris Cox | 13 Dec 23:03
Picon
Favicon

RE: EXIF meta data attributes in headers

And XMP is more or less just a big blob of XML.
(I normally despise XML for the bloat, but in this case, it's the right way to handle metadata interoperability)

Chris

-----Original Message-----
From: openexr-devel-bounces+ccox=adobe.com <at> nongnu.org on behalf of Michael Wolf
Sent: Wed 12/13/2006 1:25 PM
To: Florian Kainz; Piotr Stanczyk
Cc: openexr-devel <at> nongnu.org
Subject: Re: [Openexr-devel] EXIF meta data attributes in headers

Hello,

Sorry for being a bit late on the thread...

On Wed, 13 Dec 2006 07:02:26 +0100, Florian Kainz <kainz <at> ilm.com> wrote:

> what ?ort kind of information do you need to store?
> As far as I can tell, there's quite a bit of overlap
> between OpenEXR's "optional standard" attributes
> and EXIF data.
>
> 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 implementations out there, but is it worth having a common one?

Has anybody looked at XMP? http://www.adobe.com/products/xmp/
(Continue reading)

Permalink | Reply | 2 comments |
headers
Michael Wolf | 13 Dec 23:10

Re: EXIF meta data attributes in headers

On Wed, 13 Dec 2006 23:03:21 +0100, Chris Cox <ccox <at> adobe.com> wrote:

Hi Chris,

> And XMP is more or less just a big blob of XML.
> (I normally despise XML for the bloat, but in this case, it's the right way to handle metadata interoperability)

Lol... now somehow I was expecting you to write somethig like that ;)

> Chris

Cheers,
Mike

--

-- 
db&w GbR
Seyffer Str. 34
70197 Stuttgart

http://www.db-w.com
http://www.infinimap.com
Permalink | Reply | 1 comment |

Gmane