On 21/07/14 15:43, Julie Santerre wrote:
> So, in brief, I implemented a library that works perfectly with every
> exr file generated by your organization and by my own software. I do
> have problems with cropped files produced by Nuke (and by other
> software as well). Is there something I'm missing here? Maybe I'm not
> extracting all the information I need from the headers? Is there a
> data alignment I need to consider? Have you ever heard about any
> issues with cropped exr files generated by Nuke?
>
> I hope I gave you enough details about my problem.
Note sure if it is still present, but we've come across issues with
Nuke and storing wrong windows, I believe the Nuke bug our report was
logged against was:
Bug 6865 - AdjBBox - bounding box changing between read/write
operation on exr
What does exrheader say on the files? are they correct? In our case
the files were written incorrectly by Nuke.
Kevin
For those interested with a copy of Nuke, you should see problems with
the following:
set cut_paste_input [stack 0]
CheckerBoard2 {
inputs 0
format "2048 1556 0 0 2048 1556 2 2k_AnamorphicFull"
name CheckerBoard1
selected true
xpos 362
ypos 13
}
Crop {
box {56 0 1896 1572}
crop false
name Crop1
selected true
xpos 362
ypos 85
}
Write {
file /tmp/foo.exr
checkHashOnRead false
version 1
name Write1
selected true
xpos 362
ypos 111
}
Read {
inputs 0
file /tmp/foo.exr
format "2048 1556 0 0 2048 1556 2 2k_AnamorphicFull"
origset true
name Read4
selected true
xpos 362
ypos 142
}
--
Kevin Wheatley
Head of Software Engineering
Head of Colour Management
Cinesite VFX Ltd.
_______________________________________________
Openexr-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/openexr-devel
