Dynamic version renders a file, but static doesn't #202
Unanswered
sergenikov
asked this question in
Q&A
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I have a DNG 1.4 file shot on Canon EOS R6 (which seems relatively new). Software agent is Adobe Photoshop Camera Raw 14.3. OS is Windows. It's not a single file issue too.
This isn't a file support request, but an odd issue with static vs dynamic builds of IM6.
I use off-the-shelf portable distribution of IM6 6.9.12-66 Q8 x64. This distribution doesn't render or identify the file - I get the "file is not supported error". However, using a built dynamically linked version (VisualDynamicMT) at git tag IM6 6.9.12-66 works fine. I debugged both a dynamically linked version and a portable version (both off-the-shelf and custom built VisualStaticMT) and noticed that in both cases libraw is used, which is expected. However, in the case of the static distribution (VisualStaticMT) LibRaw's identify() function either isn't called or doesn't parse the file's metadata correctly. Thus, it doesn't return correct
imgdata.idata.raw_count
. Since that field is 0 by default, further processing fails and file is marked as "not supported". By contrast, when running the dynamically linked version (VisualDynamicMT) same identify() function executes and populates said field correctly. The file the gets identified and renders correctly. I made no code changes.I was wondering if anyone could offer any hints about why this may be and how I can build a portable distribution of IM so that libraw executes the same way as the dynamic version.
I found somewhat similar behavior with installed versions too. Without explicitly setting
MAGICK_CODER_MODULE_PATH
to the/modules/coders
of the installed folder, the file wouldn't render. Setting said variable would force IM to find the DNG module and process the file correctly. Similarly, static version of installed IM don't work on that file. (I tested this on clean VMs as well.)Thanks in advance.
UPDATE: After debugging a little more, I found that when executing and debugging VisualStaticMT.sln with said DNG,
imgdata.idata.raw_count
gets set to 0 by this code in identify.cppHowever, when executing and debugging dynamic VisualDynamicMT, this block is skipped and the value
imgdata.idata.raw_count
is to 1 in the end. The codebase is the same, the only different is static vs dynamic build produced by configure.exe. LibRaw doc supports if LIBRAW_WARN_NO_JPEGLIB is observed, this leads to an unidentified RAW file.I am happy to debug further later maybe with some guidance (or even patch if this happens to be a bug), but I am failing to understand how static vs dynamic build can affect this behaviour.
Beta Was this translation helpful? Give feedback.
All reactions