issues/0190 adds support to ctlrender for reading exr files with non-trival dataWindow

[michaeldsmith]

• adds support for reading exr files with non-trival dataWindow
• fixes issue ctlrender crashes with test image t08.exr, data window min is (30,40) not (0,0) #190
• update Ubuntu and CodeQL CI

[michaeldsmith]

@ThomasWilshaw please let us know if you have any feedback on this PR

[ThomasWilshaw]

Looking at the exr info you shared in issue #190 I wonder if round trippping those files through ctlrender loses some information? I've not tested this and could be wrong but a couple of thoughts:

t08.exr has a display window larger than its data a window and should therefore be displayed with a black border, however the current code only reads the data window, essentially cropping the display window. Would it be worth adding some attributes to dpx::fb that explicitly store both the data and display windows so they can be properly re set when exporting an exr after processing?

Blobbies.exr has a smaller display window than data window but this data isn't carried through when we write out a new exr at the end. If you view the original and processed exrs side by side in a viewer that respects the display window attribute they will have different crops.

[michaeldsmith]

@ThomasWilshaw thanks for the feedback, I have submitted a new PR #192 to replace this one, which preserves the EXR standard attribute metadata but not everything that may be present (like chromaticities, copyright, etc).

I'm wondering if there is a more standard approach to preserving all EXR metadata that may exist in the input EXR.