On 13/03/12 21:58, fnordware wrote:
I've never heard 1.7 called unstable. It's been out for nearly 2 years
without the need for an update.
I looked and you are right, 1.7 was the first actual release to support
the long file names, although the feature was added to the OpenEXR
repository in
On 13/03/12 21:58, fnordware wrote:
I've never heard 1.7 called unstable. It's been out for nearly 2 years
without the need for an update.
I looked and you are right, 1.7 was the first actual release to support
the long file names, although the feature was added to the OpenEXR
repository in
Right, well I wouldn't call that unstable.
As Nathan said before, nobody is questioning its actual stability. The name
distinction here was only between stable and feature releases. I'm
sorry if you interpreted it that way when I quoted 1.6.1 as being the
latest stable release, but you've
Yes, in openexr even version number=stable and odd=unstable.
-deke
On Wed, Mar 14, 2012 at 06:30, Ivan Busquets ivanbusqu...@gmail.com wrote:
Hi,
I've never heard 1.7 called unstable. It's been out for nearly 2 years
without the need for an update.
Yes, I wasn't implying that 1.7 is
I don’t think anyone’s questioning the actual usability of 1.7... Sounds to me
like that’s just how versioning works in the OpenEXR project.
-Nathan
From: fnordware
Sent: Tuesday, March 13, 2012 6:29 PM
To: nuke-users@support.thefoundry.co.uk
Subject: [Nuke-users] Re: Luminance / Chroma B44
How fantastically interesting! I suppose this explains why there is no B44A
option for compression type in Nuke as well since this was added more
recently as well.
I for one would be very interested in having access to the most recent
OpenEXR library working properly in Nuke.
I sent an email
For what it's worth, I don't think this is due to outdated libraries.
Nuke's exrReader uses OpenEXR 1.6.1. In fact, it's slightly above that.
IIRC from a post to this list a while ago, it's a checkout from somewhere
between 1.6.1 and 1.7 releases, after the addition of StringVector and
MultiView
Thanks for the reply Seth.
I just compressed some test images to OpenEXR B44 4:2:0 using rvio (which
is fantastic btw), and when trying to read these images into Nuke, I get
the same error as with images compressed using ProEXR from After Effects
CS5.5.
I have tried reading 4:2:0 yryby EXR in
You should send a sample file if you could to supp...@thefoundry.co.uk.
Even if it is an example checkerboard. Just something showing the error.
-deke
On Fri, Mar 2, 2012 at 01:05, Jed Smith j...@jedypod.com wrote:
Thanks for the reply Seth.
I just compressed some test images to OpenEXR
Hi
There are sample Luma/Chroma images on the exr repository on the exr project
website; shows exactly what happens.
http://www.openexr.com/downloads.html
Generaly speaking: Nuke doesn't support Luma/Chroma encoded exr files. But
problem is more complicated...
Exr libraries provide 2 ways to
10 matches
Mail list logo
