I've been trying to get FreeImage working with JPEG-XR images on Linux (Ubuntu 18.10, debian buster). I ran into an issue where the process would be unable to open such images.
I've been looking into the cause and this is what I think is happening:
- JPEG-XR uses GUIDs to specify the pixel types of the image
- LibJXR defines a GUID structure to hold such GUIDs
- the definition depends on _WINDOWS_ to select between long and int members
- FreeImage.h defines _WINDOWS_ on all platforms if it isn't already
- the resulting GUID struct is longer than on Windows
- the load process does not populate all bytes as a result
- during open, FreeImage first reads the image pixel type GUID
- the it calls CopyPixels which also reads the image pixel type GUID
- it then compares the GUIDs to see if they are identical
- this comparision uses memcmp
- since there are uninitialized bytes in the GUIDs, they don't match
- LibJXR then goes off looking for a conversion function
- it does not find one and reports the image as being in an unsupported format
If I replace _WINDOWS_ with _WIN32 in LibJXR it gets further. The api test seems to work with this change but fails on one of the memIO tests otherwise.
Notes:
Source\FreeImage.h
Source\LibJXR\common\include\guiddef.h
FreeImage\PluginJXR.cpp
LibJXR\jxrgluelib\JXRGlue.h
debugging
Last edit: Grant Boyle 2019-07-30
fixed in the SVN