ImfCompressor.h is not installed

[smaragden]

ImfCompressor.h is included in ImfMisc.h but not installed.
It seems to be the case for all 2.* releases.

diff --git a/OpenEXR/IlmImf/CMakeLists.txt b/OpenEXR/IlmImf/CMakeLists.txt
index 165fed7..728c805 100644
--- a/OpenEXR/IlmImf/CMakeLists.txt
+++ b/OpenEXR/IlmImf/CMakeLists.txt
@@ -149,6 +149,7 @@ openexr_define_library(IlmImf
     ImfLut.h
     ImfArray.h
     ImfCompression.h
+    ImfCompressor.h
     ImfLineOrder.h
     ImfName.h
     ImfPixelType.h

[peterhillman]

What's the case for requiring ImfMisc.h?
Most of the functionality in ImfMisc.h is internal to the library and isn't considered part of the stable API. I've no idea why a change was made in 2013 to install ImfMisc anyway, since it already had that include and would always have failed.

Since including ImfMisc.h from user code will fail, a better fix could be to prevent ImfMisc.h being installed. If there's some method in there that would be useful to user code, perhaps it could be transplanted out of ImfMisc.h and made an official part of the OpenEXR API

[smaragden]

It looks like Nuke is the only application having problem reading the file.

I have a library that does auto-cropping. I do these steps:

1. Read in a file
2. Copy the headers
3. Recalculate a new datawindow based on the parts content
4. Copy original pixels from input to outputs new dataWindow.

This is working great, except for a corner case where i have a tiled input with a single part.
The sanity_check in the MultiPartOutputFile constructor will never call header.setChunkCount(getChunkOffsetTableSize(header, true))
because this check
if (_headers[0].hasType() && isImage(_headers[0].type()) == false)
on line 186 in ImfMultiPartOutputFile.cpp will return false.

To solve this I set the chunkSize myself after changing the dataWindow. by calling:

Header h(in.header(part));
h.insert("dataWindow", Box2iAttribute(cropped_dw));
h.setChunkCount(getChunkOffsetTableSize(h, true));

getChunkOffsetTableSize is part of ImfMisc.

I'm not sure if the real problem is that there are cases where setChunkCount is never called or if i'm doing something sketchy here.

If i don't set the chunk size manually. The file wont open in nuke with the error: wrong offset count, not able to read from this array, it opens fine in RV, DJV, Krita.

[peterhillman]

Good find! Have you tried erasing the chunkCount attribute, rather than going to the trouble of setting it correctly?

[smaragden]

Thank you!

Header h(in.header(part));
h.insert("dataWindow", Box2iAttribute(dw));
if(h.hasChunkCount())
    h.erase("chunkCount");

Removing the chunkCount attribute makes all my tests pass.

My issue is resolved by not depending on ImfMisc, but i guess the real solution is to remove IlmImf.h from installed headers rather than adding ImfCompressor.h.

[cary-ilm]

ImfMisc.h is included in exrmaketiled and by several files in IlmImfTest (which are essentially like external application code calling into the library), each to access getChunkOffsetTableSize(). Can/should that function move to another .h? If so, we can switch IlmMisc.h to not be exported.

[peterhillman]

I think the change that @smaragden made would also be appropriate for exrmaketiled, though that would change the output files it generates when the output only has one part. Making that change would mean we can stop exporting ImfMisc.h, but carry on allowing IlmImfTest to use it.

The IlmImfTest examples are using getChunkOffsetTableSize() to do low-level manipulations of files to simulate damaged files, so it's harder to see how to eliminate the code completely.
Moving getChunkOffsetTableSize() wouldn't eliminate dependency of IlmImfTest on non-exported headers, as other non-exported header files are used by various IlmImfTests. It seems fair to me that low-level tests should be able to access private functions to run more isolated unit tests.

I'm not sure whether there are legitimate reasons to call getChunkOffsetTableSize() from user code. The OpenEXR API doesn't really provide low-level access to the file structure.

[cary-ilm]

#605 addresses this, by un-installing ImfMisc.h. The functions defined there are for internal use only, for low-level manipulation of the file structure, not appropriate for application code.