headers
Lauralea Otis | 5 Apr 20:25
Picon

size of exr header

Hi.  Is there a way to get the size of an exr header for a particular file.

Or a place to find information on it?

Thanks.

Lauralea

_______________________________________________
Openexr-devel mailing list
Openexr-devel <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/openexr-devel
Permalink | Reply | 1 comment |
headers
Florian Kainz | 6 Apr 18:47

Re: size of exr header

Hi Lauralea,

The size of the header is variable; the API of the IlmImf library
does not currently include a function that queries the size of the
header.

http://www.openexr.com/openexrfilelayout.pdf describes the on-disk
layout of OpenEXR files, including the header.

Why do you need to know the size of the header?

Florian

Lauralea Otis wrote:
> Hi.  Is there a way to get the size of an exr header for a particular file.
> 
> Or a place to find information on it?
> 
> Thanks.
> 
> Lauralea
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Openexr-devel mailing list
> Openexr-devel <at> nongnu.org
> http://lists.nongnu.org/mailman/listinfo/openexr-devel
Permalink | Reply | 0 comments |
headers
Pavel Ledin | 11 Apr 18:10
Picon
Favicon

Re: static EXR and dynamic stdc++ under linux

Hello Pavel,

Friday, March 16, 2007, 6:15:59 PM, you wrote:

Anyone can help with this?

>  I have OpenEXR saver (mental ray output shader) and I have a problem
>  with static link OpenEXR 1.4.0 library under linux.
>  I need static link OpenEXR and shared stdc++ (or all static).
>  Or is it possible to remove stdc++ dependency for link all library as static?

>  Maybe it is not so OpenEXR question as linux, but nevertheless...

>  For example my Makefile looks like.

> CC = g++
> INC = -I../include -I../include/exr
> LIB = -shared -export-dynamic -L/usr/aw/maya8.0/lib -lstdc++
> -static -L../libs/exr -lIlmImf -lIlmThread
> CFLAGS = -O2 -fPIC 
>  
> shaders_p.so : p_OpenEXR_saver.cpp p_maya_shadingengine.cpp
> p_MegaTK_pass.cpp p_scatter_wrap.cpp p_fur.cpp p_occlusion.cpp
> p_reflect_refract.cpp p_SpotTK.cpp p_PointTK.cpp p_DirectTK.cpp
> p_MegaTK.cpp p_bake_read.cpp p_fg_light.cpp p_ray_type.cpp
> p_buffer_writer.cpp p_fg_no_light.cpp p_saturation.cpp
> p_color_plus_alpha.cpp p_fisheye.cpp p_shadow.cpp p_color_to_float.cpp
> p_irradiance.cpp p_shadow_transparency.cpp p_constant.cpp
> p_math_output.cpp p_z.cpp p_facing_ratio.cpp p_motion_to_rgb.cpp
> p_CSG.cpp p_environment.cpp

>         $(CC) $(INC) $(LIB) $(CFLAGS) -o shaders_p.so
> p_OpenEXR_saver.cpp p_maya_shadingengine.cpp p_MegaTK_pass.cpp
> p_scatter_wrap.cpp p_fur.cpp p_occlusion.cpp p_reflect_refract.cpp
> p_SpotTK.cpp p_PointTK.cpp p_DirectTK.cpp p_MegaTK.cpp
> p_bake_read.cpp p_fg_light.cpp p_ray_type.cpp p_buffer_writer.cpp
> p_fg_no_light.cpp p_saturation.cpp p_color_plus_alpha.cpp
> p_fisheye.cpp p_shadow.cpp p_color_to_float.cpp p_irradiance.cpp
> p_shadow_transparency.cpp p_constant.cpp p_math_output.cpp
> p_z.cpp p_facing_ratio.cpp p_motion_to_rgb.cpp p_CSG.cpp p_environment.cpp

> local: shaders_p.so

> What's wrong?

--

-- 
Best regards,
 Pavel Ledin aka Puppet                            mailto:puppet <at> rambler.ru
 Moscow, Russia
Permalink | Reply | 4 comments |
headers
Florian Kainz | 12 Apr 04:22

Re: static EXR and dynamic stdc++ under linux

Hi Pavel,

what is the problem you have with static linking?
Do you get unresolved symbols?  Are the libraries
missing?

Anyway, as far as I know mental has built-in support
for OpenEXR output.

Florian

Pavel Ledin wrote:
> Hello Pavel,
> 
> Friday, March 16, 2007, 6:15:59 PM, you wrote:
> 
> Anyone can help with this?
> 
>> I have OpenEXR saver (mental ray output shader) and I have a problem
>> with static link OpenEXR 1.4.0 library under linux.
>> I need static link OpenEXR and shared stdc++ (or all static).
>> Or is it possible to remove stdc++ dependency for link all library as static?
> 
>> Maybe it is not so OpenEXR question as linux, but nevertheless...
> 
>> For example my Makefile looks like.
> 
>>CC = g++
>>INC = -I../include -I../include/exr
>>LIB = -shared -export-dynamic -L/usr/aw/maya8.0/lib -lstdc++
>>-static -L../libs/exr -lIlmImf -lIlmThread
>>CFLAGS = -O2 -fPIC 
>> 
>>shaders_p.so : p_OpenEXR_saver.cpp p_maya_shadingengine.cpp
>>p_MegaTK_pass.cpp p_scatter_wrap.cpp p_fur.cpp p_occlusion.cpp
>>p_reflect_refract.cpp p_SpotTK.cpp p_PointTK.cpp p_DirectTK.cpp
>>p_MegaTK.cpp p_bake_read.cpp p_fg_light.cpp p_ray_type.cpp
>>p_buffer_writer.cpp p_fg_no_light.cpp p_saturation.cpp
>>p_color_plus_alpha.cpp p_fisheye.cpp p_shadow.cpp p_color_to_float.cpp
>>p_irradiance.cpp p_shadow_transparency.cpp p_constant.cpp
>>p_math_output.cpp p_z.cpp p_facing_ratio.cpp p_motion_to_rgb.cpp
>>p_CSG.cpp p_environment.cpp
> 
>>        $(CC) $(INC) $(LIB) $(CFLAGS) -o shaders_p.so
>>p_OpenEXR_saver.cpp p_maya_shadingengine.cpp p_MegaTK_pass.cpp
>>p_scatter_wrap.cpp p_fur.cpp p_occlusion.cpp p_reflect_refract.cpp
>>p_SpotTK.cpp p_PointTK.cpp p_DirectTK.cpp p_MegaTK.cpp
>>p_bake_read.cpp p_fg_light.cpp p_ray_type.cpp p_buffer_writer.cpp
>>p_fg_no_light.cpp p_saturation.cpp p_color_plus_alpha.cpp
>>p_fisheye.cpp p_shadow.cpp p_color_to_float.cpp p_irradiance.cpp
>>p_shadow_transparency.cpp p_constant.cpp p_math_output.cpp
>>p_z.cpp p_facing_ratio.cpp p_motion_to_rgb.cpp p_CSG.cpp p_environment.cpp
> 
>>local: shaders_p.so
> 
>>What's wrong?
> 
> 
> 
>
Permalink | Reply | 3 comments |
headers
Pavel Ledin | 12 Apr 09:55
Picon
Favicon

Re[2]: static EXR and dynamic stdc++ under linux

Hello Florian,

Thursday, April 12, 2007, 6:22:50 AM, you wrote:

> what is the problem you have with static linking?
> Do you get unresolved symbols?  Are the libraries
> missing?

Thanks for your reply...

No problem with compiling, no errors, no warnings, and I have all libs
and headers.
But it's not compiled as static, it compiled as shared. In other words if I view my
shaders_p.so(output compiled file) I can see link to
libstdc++.so.6 and libIlmThread.so.4 (no problem with libstdc++.so.6 it's normal).

And of course it will crash during render, because I have installed
only old 1.2.2 OpenEXR on my machine.
1.4 is contained only locally in my project (../libs/exr).

I need static link OpenEXR.
What's wrong?

LIB = -L/usr/aw/maya8.0/lib -shared -export-dynamic -lstdc++ -static -L../libs/exr -lIlmImf -lIlmThread

> Anyway, as far as I know mental has built-in support
> for OpenEXR output.

Yes, but I need my own EXR saver that will save multichannel file with
many passes like:
RGBA, n, z, coverage, label, diffuse, shadow, specular, reflections,
refraction and many more,.. that supported by my p_MegaTK shader
http://www.puppet.cgtalk.ru/download/megatk_e.shtml
http://www.puppet.cgtalk.ru/tutorials/howtomegatk_e.shtml

I also need different compressions and data types, like 32unint.
I suppose it's not possible with build-in OpenEXR.

--

-- 
Best regards,
 Pavel Ledin aka Puppet                            mailto:puppet <at> rambler.ru
 Moscow, Russia
Permalink | Reply | 2 comments |
headers
Florian Kainz | 13 Apr 03:38

Re: static EXR and dynamic stdc++ under linux

You may want to try explicitly listing the static libraries
on the link line.  For example:

	../libs/exr/libILmImf.a ../libs/exr/libIlmThread.a

instead of

	-L../libs/exr -lIlmImf -lIlmThread

Pavel Ledin wrote:
> Hello Florian,
> 
> Thursday, April 12, 2007, 6:22:50 AM, you wrote:
> 
>>what is the problem you have with static linking?
>>Do you get unresolved symbols?  Are the libraries
>>missing?
> 
> Thanks for your reply...
> 
> No problem with compiling, no errors, no warnings, and I have all libs
> and headers.
> But it's not compiled as static, it compiled as shared. In other words if I view my
> shaders_p.so(output compiled file) I can see link to
> libstdc++.so.6 and libIlmThread.so.4 (no problem with libstdc++.so.6 it's normal).
> 
> And of course it will crash during render, because I have installed
> only old 1.2.2 OpenEXR on my machine.
> 1.4 is contained only locally in my project (../libs/exr).
> 
> I need static link OpenEXR.
> What's wrong?
> 
> LIB = -L/usr/aw/maya8.0/lib -shared -export-dynamic -lstdc++ -static -L../libs/exr -lIlmImf -lIlmThread
> 
> 
>>Anyway, as far as I know mental has built-in support
>>for OpenEXR output.
> 
> Yes, but I need my own EXR saver that will save multichannel file with
> many passes like:
> RGBA, n, z, coverage, label, diffuse, shadow, specular, reflections,
> refraction and many more,.. that supported by my p_MegaTK shader
> http://www.puppet.cgtalk.ru/download/megatk_e.shtml
> http://www.puppet.cgtalk.ru/tutorials/howtomegatk_e.shtml
> 
> I also need different compressions and data types, like 32unint.
> I suppose it's not possible with build-in OpenEXR.
> 
> 
> 
>
Permalink | Reply | 1 comment |
headers
Pavel Ledin | 13 Apr 13:29
Picon
Favicon

Re[2]: static EXR and dynamic stdc++ under linux

Hello Florian,

Friday, April 13, 2007, 5:38:29 AM, you wrote:

> You may want to try explicitly listing the static libraries
> on the link line.  For example:

>         ../libs/exr/libILmImf.a ../libs/exr/libIlmThread.a

> instead of

>         -L../libs/exr -lIlmImf -lIlmThread

It could not find library in this case.
Now I had put exr libraries to maya/lib dir and now it compiled fine,
looks like it compiled as static (no links to ".so" inside my
shaders_p.so).
But maya still crash during call my shader:

/usr/autodesk/maya8.5/bin/maya.bin: symbol lookup error:
/usr/autodesk/maya8.5/mentalray/lib/shaders_p.so: undefined symbol: _ZN3Imf5SliceC1ENS_9PixelTypeEPcjjiidbb

LIB = -L/usr/autodesk/maya8.5/lib -shared -export-dynamic -lstdc++ -static -lIlmImf -lIlmThread
-lHalf -lIex -lImath -lzlib

--

-- 
Best regards,
 Pavel Ledin aka Puppet                            mailto:puppet <at> rambler.ru
 Moscow, Russia
Permalink | Reply | 0 comments |
headers
Brendan Bolles | 23 Apr 07:39
Favicon

CTL not working with exrdisplay

Hey all, has anyone gotten CTL working with exrdisplay?  I'm working  
in OS X (Xcode) and have gotten it all compiled and running with CTL  
included and turned on.  Marching through the debugger, I can see  
that the .ctl file is being found and it looks like transforms are  
being applied.  But the view on screen never looks any different -  
nearly the same as when you use no CTL at all (with the -T flag).   
I've been testing with the two included files that seem to work,  
transform_RRT.ctl and transform_EXR_DPX.ctl, but nothing happens with  
either of them.

It gets pretty confusing down deep in all that C++.  Is there  
anything I can look for that would verify that nothing is actually  
happening and try to maybe figure out why?

I'm using all the latest stuff.  Everything appears normal  
otherwise.  Here's what I've got in my shell:

[fnord:mac/build/Release] mrb% ./exrdisplay -C transform_RRT ~/ 
Development/sample_images/openexr-images-1.5.0/Tiles/GoldenGate.exr
Warning: Environment variable CTL_DISPLAY_CHROMATICITIES is not set;  
using default value (chromaticities according to Rec. ITU-R BT.709).
Warning: Environment variable CTL_DISPLAY_WHITE_LUMINANCE  is is not  
set; using default value (120 candelas per square meter).
Warning: Environment variable CTL_DISPLAY_SURROUND_LUMINANCE  is is  
not set; using default value (12 candelas per square meter).
Warning: Environment variable EXR_DISPLAY_VIDEO_GAMMA is not set;  
using default value (2.2).
[fnord:mac/build/Release] mrb%

Brendan
Permalink | Reply | 2 comments |
headers
Florian Kainz | 23 Apr 21:03

Re: CTL not working with exrdisplay

Hi Brendan,

your command line should either read

     exrdisplay -C transform_RRT -C transform_display_video GoldenGate.exr

or just

     exrdisplay GoldenGate.exr

In the second case the default transforms, transform_RRT and
transform_display_video, will automatically be applied.

The transform_RRT relies on transform_display_video to produce
the pixels that will actually be displayed.  Without the second
transform the output of transform_RRT will be discarded.  In this
case exrdisplay shows you the original image because it is re-using
a buffer that initially contained the original image from the file.
The buffer should get overwritten by the CTL transforms.  I guess
it would be better to display a black image if the CTL transforms
fail to produce any output.

The effect of the CTL transforms on the GoldenGate.exr image are
rather subtle; to get a more obvious effect, save the following CTL
program in file foo.ctl:

     void
     foo (output varying half displayR,
          output varying half displayG,
          output varying half displayB,
          varying half R,
          varying half G,
          varying half B)
     {
         displayR = B;
         displayG = R;
         displayB = G;
     }

Then run

     exrdisplay -C foo GoldenGate.exr

This should swap the R, G and B channels of the image.  You should
get a red sky and greenish city lights.

Florian

Brendan Bolles wrote:
> Hey all, has anyone gotten CTL working with exrdisplay?  I'm working  in 
> OS X (Xcode) and have gotten it all compiled and running with CTL  
> included and turned on.  Marching through the debugger, I can see  that 
> the .ctl file is being found and it looks like transforms are  being 
> applied.  But the view on screen never looks any different -  nearly the 
> same as when you use no CTL at all (with the -T flag).   I've been 
> testing with the two included files that seem to work,  
> transform_RRT.ctl and transform_EXR_DPX.ctl, but nothing happens with  
> either of them.
> 
> It gets pretty confusing down deep in all that C++.  Is there  anything 
> I can look for that would verify that nothing is actually  happening and 
> try to maybe figure out why?
> 
> I'm using all the latest stuff.  Everything appears normal  otherwise.  
> Here's what I've got in my shell:
> 
> 
> [fnord:mac/build/Release] mrb% ./exrdisplay -C transform_RRT ~/ 
> Development/sample_images/openexr-images-1.5.0/Tiles/GoldenGate.exr
> Warning: Environment variable CTL_DISPLAY_CHROMATICITIES is not set;  
> using default value (chromaticities according to Rec. ITU-R BT.709).
> Warning: Environment variable CTL_DISPLAY_WHITE_LUMINANCE  is is not  
> set; using default value (120 candelas per square meter).
> Warning: Environment variable CTL_DISPLAY_SURROUND_LUMINANCE  is is  not 
> set; using default value (12 candelas per square meter).
> Warning: Environment variable EXR_DISPLAY_VIDEO_GAMMA is not set;  using 
> default value (2.2).
> [fnord:mac/build/Release] mrb%
> 
> 
> Brendan
> 
> 
> 
> _______________________________________________
> Openexr-devel mailing list
> Openexr-devel <at> nongnu.org
> http://lists.nongnu.org/mailman/listinfo/openexr-devel
> 
>
Permalink | Reply | 1 comment |
headers
Brendan Bolles | 23 Apr 22:03
Favicon

Re: CTL not working with exrdisplay

Ahh, ok.  Nice.  That's a good test case to have.  Apparently CTL is  
working for me after all.

Seems like there are a lot of ways for a chain of CTL files to fail.   
It would be good to someday see a program that makes it a bit more  
idiot-proof.

In the meantime, I guess I have some learning to do.

Thanks!

Brendan

On Apr 23, 2007, at 12:03 PM, Florian Kainz wrote:

>     void
>     foo (output varying half displayR,
>          output varying half displayG,
>          output varying half displayB,
>          varying half R,
>          varying half G,
>          varying half B)
>     {
>         displayR = B;
>         displayG = R;
>         displayB = G;
>     }
>
> Then run
>
>     exrdisplay -C foo GoldenGate.exr
>
> This should swap the R, G and B channels of the image.  You should
> get a red sky and greenish city lights.
>
Permalink | Reply | 0 comments |

Gmane