headers
Jeff Clifford | 3 Feb 13:56
Favicon
Gravatar

Camera matrices in sxr files

Hi,

I have a question about how best to store the camera matrices in an sxr 
file for the left, right (and maybe mono) cameras.

Is the best way to go to simply add some new attributes to the header like:

    header.insert( "worldToCamera_left", Imf::M44fAttribute (Nl_left) );
    header.insert( "worldToNDC_left", Imf::M44fAttribute (NP_left) );

    header.insert( "worldToCamera_right", Imf::M44fAttribute (Nl_right) );
    header.insert( "worldToNDC_right", Imf::M44fAttribute (NP_right) );

rather than use the stadard attributes of worldToCamera & worldToNDC?

Or is there some smarter way of having the standard attributes as a 
vector attributes in some way to allow for multiple camera matrices?

Thanks,

Jeff Clifford.
Permalink | Reply | 1 comment |
headers
Peter Hillman | 3 Feb 22:24
Picon
Gravatar

Re: Camera matrices in sxr files

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

Jeff Clifford wrote:
> Hi,
>
> I have a question about how best to store the camera matrices in an 
> sxr file for the left, right (and maybe mono) cameras.
>
> Is the best way to go to simply add some new attributes to the header 
> like:
>
>    header.insert( "worldToCamera_left", Imf::M44fAttribute (Nl_left) );
>    header.insert( "worldToNDC_left", Imf::M44fAttribute (NP_left) );
>
>    header.insert( "worldToCamera_right", Imf::M44fAttribute (Nl_right) );
>    header.insert( "worldToNDC_right", Imf::M44fAttribute (NP_right) );
>
> rather than use the stadard attributes of worldToCamera & worldToNDC?
>
> Or is there some smarter way of having the standard attributes as a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Clifford | 12 Feb 17:29
Favicon
Gravatar

Missing includes for building with GCC 4.3.x

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 have as much cross-including of headers it seems as 
previous versions so some small adjustments are required to overcome the 
following compilation errors due to missing includes:

ImathMatrix.h: In constructor 'Imath::Matrix44<T>::Matrix44() [with T = 
float]':
ImfChromaticities.cpp:110:   instantiated from here
ImathMatrix.h:1796: error: 'memset' was not declared in this scope

Just need to add

#include <string.h>

to ImathMatrix.h

to fix.

Similarly this needs adding to

blurImage.cpp

as well.

Cheers,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Piotr Stanczyk | 12 Feb 22:54
Gravatar

Re: Missing includes for building with GCC 4.3.x

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 have as much cross-including of headers it seems as 
> previous versions so some small adjustments are required to overcome 
> the following compilation errors due to missing includes:
>
> ImathMatrix.h: In constructor 'Imath::Matrix44<T>::Matrix44() [with T 
> = float]':
> ImfChromaticities.cpp:110:   instantiated from here
> ImathMatrix.h:1796: error: 'memset' was not declared in this scope
>
> Just need to add
>
> #include <string.h>
>
> to ImathMatrix.h
>
> to fix.
>
>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Richter | 24 Feb 14:23
Picon
Favicon
Gravatar

JPEG-HDR/JPEG 2000/JPEG-XR on OpenEXR images ready

Hi folks,

in case you're interested, I completed the study of floating-point compression algorithms on the OpenEXR
image set, comparing the
compression performance of JPEG-HDR with that of the floating-point JPEG-XR compression and a JPEG 2000
based floating point
compression format. Anyone interested in a pre-print might simply sent me a note.

Short results for the impatient: In almost all cases, JPEG 2000 performs best here. There is one
interesting corner case, namely
the OpenEXR "StillLife" image where JPEG-HDR outperforms all other compression schemes, which is due to
the extreme nature of the
image - here JPEG-HDR profits from its adaptive tone-mapper. JPEG 2000/JPEG-XR use a fixed mapping from
floating point to integer,
offering the advantage of making lossless compression of floats possible.

So long,
	Thomas
Permalink | Reply | 0 comments |
headers
Werner Benger | 3 Mar 22:06
Favicon
Gravatar

Writing a tiled Rgba image file with tiles given

Greetings,

  I found a limitation in the class TiledRgbaOutputFile as provided in the  
IlmImf
library, in that it seems to not allow writing a tile from a buffer that  
only
contains this tile. By default it assumes that the provided pointer is  
relative
to an absolute buffer that contains the entire image. However, the  
underlying
class "Slice" already supports such relative data, and it's straightforward
to just pass this parameter to the creation of such slices.

Here are the modifications I made to the library, as I did not find another
way to achieve the same. These changes seem to be simple and don't break  
any
existing code while it just works for me then.

Best regards,

	Werner

==========================
In file ImgTiledRgbaFile.h : 170

     void		setFrameBuffer (const Rgba *base,
					size_t xStride,
					size_t yStride,
					bool   relativeBase = false);
(Continue reading)

Permalink | Reply | 5 comments |
headers
Florian Kainz | 4 Mar 00:07

Re: Writing a tiled Rgba image file with tiles given

Hi Werner,

Thank you for your mail.

Class TiledRgbaOutputFile can already be used with a single-tile
buffer.  The base pointer in setFrameBuffer always points to the
memory location where pixel (0,0) would be if it existed.  If your
buffer contains only a single tile, and that tile does not include
pixel (0,0), then the base pointer just points outside the buffer.
This may seem weird, but it works.  For a more detailed explanation
please see section 2.2, Writing a Cropped Image, of this document:

     http://www.openexr.com/ReadingAndWritingImageFiles.pdf

Still, your library patch would make it possible to reduce the
number of setFrameBuffer calls when a file is read or written using
a single-tile frame buffer.

In its current form the patch is incomplete: the new flag has no
effect on YA (gray-scale + alpha) files.  Also, in order to be more
useful in conjunction with writeTiles (as opposed to writeTile),
setFrameBuffer should have separate "tile-relative coordinates"
flags for x and y.

Florian

Werner Benger wrote:
> Greetings,
> 
>  I found a limitation in the class TiledRgbaOutputFile as provided in
(Continue reading)

Permalink | Reply | 4 comments |

Gmane