headers
Stewart Dickson | 3 Feb 20:12
Picon
Favicon

Unpacking the multiView attribute?

Dumb question?

When reading the MultiView/* image files in the OpenEXR Sample Images source:
http://download.savannah.nongnu.org/releases/openexr/openexr-images-1.7.0.tar.gz
openexr-images-1.7.0/MultiView/*

One encounters the attribute of type StringVector, which I don't see hooks in the
OpenEXR API to unpack.

Can anyone explain how to do it?

Thanks,

-Stewart Dickson

From: 	Peter Hillman
Subject: 	Re: [Openexr-devel] Camera matrices in sxr files
Date: 	Wed, 04 Feb 2009 10:24:09 +1300
User-agent: 	Thunderbird 2.0.0.19 (X11/20090105)

This came up on the renderman forum last year:
https://renderman.pixar.com/forum/showthread.php?s=&threadid=10209

Florian's suggestion was to use <view>.worldToCamera and <view>.worldToNDC as the attribute names,
except the Default View (the first view listed in the multiView attribute), which remain worldToCamera
and worldToNDC, so that non-sxr aware software (which only loads the default view) would pick up the
corresponding worldToCamera/worldToNDC So if you have left-eye as hero eye you'd have worldToCamera
for the left and right.worldToCamera for the right
Permalink | Reply | 5 comments |
headers
Paul Miller | 3 Feb 20:21
Gravatar

Re: Unpacking the multiView attribute?

On 2/3/2012 1:12 PM, Stewart Dickson wrote:
> Dumb question?
>
> When reading the MultiView/* image files in the OpenEXR Sample Images source:
> http://download.savannah.nongnu.org/releases/openexr/openexr-images-1.7.0.tar.gz
> openexr-images-1.7.0/MultiView/*
>
> One encounters the attribute of type StringVector, which I don't see hooks in the
> OpenEXR API to unpack.
>
> Can anyone explain how to do it?

Here is how I do it:

const StringVectorAttribute *multiView = 
file->header().findTypedAttribute<StringVectorAttribute>("multiView");
if (multiView)
{
    const StringVector &value = multiView->value();
    std::string def_view = defaultViewName(value);
    ...
}
Permalink | Reply | 3 comments |
headers
Stewart Dickson | 3 Feb 21:22
Picon
Favicon

Re: Unpacking the multiView attribute?

Thanks, Paul,

Is this in OpenEXR version 1.7.0?

In openexr-1.6.1, I get:
 error: ISO C++ forbids declaration of ‘StringVectorAttribute’ with no type

I'll try version 1.7.0

Thanks again,

-Stewart

----- Original Message -----
From: "Paul Miller" <paul <at> fxtech.com>
To: openexr-devel <at> nongnu.org
Sent: Friday, February 3, 2012 1:21:50 PM
Subject: Re: [Openexr-devel] Unpacking the multiView attribute?

On 2/3/2012 1:12 PM, Stewart Dickson wrote:
> Dumb question?
>
> When reading the MultiView/* image files in the OpenEXR Sample Images source:
> http://download.savannah.nongnu.org/releases/openexr/openexr-images-1.7.0.tar.gz
> openexr-images-1.7.0/MultiView/*
>
> One encounters the attribute of type StringVector, which I don't see hooks in the
> OpenEXR API to unpack.
>
> Can anyone explain how to do it?
(Continue reading)

Permalink | Reply | 2 comments |
headers
Paul Miller | 3 Feb 22:05
Gravatar

Re: Unpacking the multiView attribute?

On 2/3/2012 2:22 PM, Stewart Dickson wrote:
> Thanks, Paul,
>
> Is this in OpenEXR version 1.7.0?
>
> In openexr-1.6.1, I get:
>   error: ISO C++ forbids declaration of ‘StringVectorAttribute’ with no type

It's probably in the Imf namespace. I have a

using namespace Imf;
using namespace Imath;

at the top of my code. I'm pretty sure it was in 1.6.

_______________________________________________
Openexr-devel mailing list
Openexr-devel <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
Permalink | Reply | 1 comment |
headers
Stewart Dickson | 3 Feb 22:14
Picon
Favicon

Re: Unpacking the multiView attribute?

Nope,

In openexr-1.7.0/IlmImf there exists:
ImfStringVectorAttribute.h
In openexr-1.6.1/IlmImf
no such beast.

Which brings up my next question.

Is there a way to switch
#if defined(OPENEXR_VERSION > 1.6.1)
To turn off reference to StringVectorAttribute
when building against openexr-1.6.1 version of the code?

Thanks,

-Stewart

----- Original Message -----
From: "Paul Miller" <paul <at> fxtech.com>
To: "Stewart Dickson" <sdickson <at> wolfram.com>
Cc: openexr-devel <at> nongnu.org
Sent: Friday, February 3, 2012 3:05:20 PM
Subject: Re: [Openexr-devel] Unpacking the multiView attribute?

On 2/3/2012 2:22 PM, Stewart Dickson wrote:
> Thanks, Paul,
>
> Is this in OpenEXR version 1.7.0?
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Hillman | 4 Feb 00:43
Picon

Re: Unpacking the multiView attribute?

1.7.0 was indeed the first version to ship with that header, although it was in the CVS for some time before 1.7 was released.

Weta back-ported  support for the attribute into our 1.6 build, as did quite a few others. An autoconf type mechanism might be the most robust way of detecting support for that attribute





-------- Original message --------
Subject: Re: [Openexr-devel] Unpacking the multiView attribute?
From: Stewart Dickson <sdickson <at> wolfram.com>
To: Paul Miller <paul <at> fxtech.com>
CC: openexr-devel <at> nongnu.org


 Nope,

In openexr-1.7.0/IlmImf there exists:
ImfStringVectorAttribute.h
In openexr-1.6.1/IlmImf
no such beast.

Which brings up my next question.

Is there a way to switch
#if defined(OPENEXR_VERSION > 1.6.1)
To turn off reference to StringVectorAttribute
when building against openexr-1.6.1 version of the code?

Thanks,

-Stewart

----- Original Message -----
From: "Paul Miller" <paul <at> fxtech.com>
To: "Stewart Dickson" <sdickson <at> wolfram.com>
Cc: openexr-devel <at> nongnu.org
Sent: Friday, February 3, 2012 3:05:20 PM
Subject: Re: [Openexr-devel] Unpacking the multiView attribute?

On 2/3/2012 2:22 PM, Stewart Dickson wrote:
> Thanks, Paul,
>
> Is this in OpenEXR version 1.7.0?
>
> In openexr-1.6.1, I get:
>   error: ISO C++ forbids declaration of ‘StringVectorAttribute’ with no type

It's probably in the Imf namespace. I have a

using namespace Imf;
using namespace Imath;

at the top of my code. I'm pretty sure it was in 1.6.

_______________________________________________
Openexr-devel mailing list
Openexr-devel <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
_______________________________________________
Openexr-devel mailing list
Openexr-devel <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
Permalink | Reply | 0 comments |
headers
Paul Miller | 13 Feb 22:16
Gravatar

how to properly save with data window?

When I specify for example a data window such as (-70,-154)-(649,331) 
for a 720x486 image and then call writePixels(486), the library is 
crashing down in copyFromFrameBuffer().

Perhaps this is the way I am adding Slices to my frame-buffer?

for (int i = 0; i < channels; i++)
{
	const half *pixels = pixPtr + i;
	frameBuffer.insert(chanName, Slice(HALF, (char *)(pixels), sizeof(half) 
* channels, sizeof(half) * width * channels));
}

I am basing this on "3.2 Writing a Cropped Image" in the reading/writing 
document. Though my RGBA pixels are packed into a single buffer.

What am I doing wrong?
Permalink | Reply | 5 comments |
headers
Ciaran Wills | 13 Feb 23:33
Picon
Favicon

Re: how to properly save with data window?


On Feb 13, 2012, at 1:16 PM, Paul Miller wrote:

> When I specify for example a data window such as (-70,-154)-(649,331) for a 720x486 image and then call
writePixels(486), the library is crashing down in copyFromFrameBuffer().
> 
> Perhaps this is the way I am adding Slices to my frame-buffer?
> 
> for (int i = 0; i < channels; i++)
> {
> 	const half *pixels = pixPtr + i;
> 	frameBuffer.insert(chanName, Slice(HALF, (char *)(pixels), sizeof(half) * channels,
sizeof(half) * width * channels));
> }
> 
> I am basing this on "3.2 Writing a Cropped Image" in the reading/writing document. Though my RGBA pixels
are packed into a single buffer.
> 
> What am I doing wrong?

I think you probably need to offset the pixel pointer to point at where pixel (0, 0) would be - section 2.2
explains the pixel pointer math a bit clearer.
Permalink | Reply | 4 comments |
headers
Paul Miller | 13 Feb 23:44
Gravatar

Re: how to properly save with data window?

On 2/13/2012 4:33 PM, Ciaran Wills wrote:
>
> On Feb 13, 2012, at 1:16 PM, Paul Miller wrote:
>
>> When I specify for example a data window such as (-70,-154)-(649,331) for a 720x486 image and then call
writePixels(486), the library is crashing down in copyFromFrameBuffer().
>>
>> Perhaps this is the way I am adding Slices to my frame-buffer?
>>
>> for (int i = 0; i<  channels; i++)
>> {
>> 	const half *pixels = pixPtr + i;
>> 	frameBuffer.insert(chanName, Slice(HALF, (char *)(pixels), sizeof(half) * channels,
sizeof(half) * width * channels));
>> }
>>
>> I am basing this on "3.2 Writing a Cropped Image" in the reading/writing document. Though my RGBA pixels
are packed into a single buffer.
>>
>> What am I doing wrong?
>
> I think you probably need to offset the pixel pointer to point at where pixel (0, 0) would be - section 2.2
explains the pixel pointer math a bit clearer.

I tried that as well:

const half *pixels = pixPtr + chan_index;
pixels = pixels - dataWindow.min.x - (dataWindow.min.y * width);
fb.insert(chanName, Slice(HALF, (char *)(pixels), sizeof(half) * 
channels, sizeof(half) * width * channels));

But I got the same crash in the same place.

Thus my confusion.
Permalink | Reply | 3 comments |
headers
Piotr Stanczyk | 14 Feb 02:13
Gravatar

Re: how to properly save with data window?

Hi Paul

hmm - that sounds about right. let me take a closer look in a mo  ...

Piotr

________________________________________
From: openexr-devel-bounces+pstanczyk=ilm.com <at> nongnu.org
[openexr-devel-bounces+pstanczyk=ilm.com <at> nongnu.org] on behalf of Paul Miller [paul <at> fxtech.com]
Sent: 13 February 2012 14:44
To: Ciaran Wills
Cc: openexr-devel <at> nongnu.org
Subject: Re: [Openexr-devel] how to properly save with data window?

On 2/13/2012 4:33 PM, Ciaran Wills wrote:
>
> On Feb 13, 2012, at 1:16 PM, Paul Miller wrote:
>
>> When I specify for example a data window such as (-70,-154)-(649,331) for a 720x486 image and then call
writePixels(486), the library is crashing down in copyFromFrameBuffer().
>>
>> Perhaps this is the way I am adding Slices to my frame-buffer?
>>
>> for (int i = 0; i<  channels; i++)
>> {
>>      const half *pixels = pixPtr + i;
>>      frameBuffer.insert(chanName, Slice(HALF, (char *)(pixels), sizeof(half) * channels,
sizeof(half) * width * channels));
>> }
>>
>> I am basing this on "3.2 Writing a Cropped Image" in the reading/writing document. Though my RGBA pixels
are packed into a single buffer.
>>
>> What am I doing wrong?
>
> I think you probably need to offset the pixel pointer to point at where pixel (0, 0) would be - section 2.2
explains the pixel pointer math a bit clearer.

I tried that as well:

const half *pixels = pixPtr + chan_index;
pixels = pixels - dataWindow.min.x - (dataWindow.min.y * width);
fb.insert(chanName, Slice(HALF, (char *)(pixels), sizeof(half) *
channels, sizeof(half) * width * channels));

But I got the same crash in the same place.

Thus my confusion.

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

Gmane