| 2019-10-26 17:26:39 |
Fabian Wiesel |
description |
1) Ubuntu 18.04.3 LTS
2) libfreeimage-dev=3.17.0+ds1-5build2, libjxr-dev=1.1-6build1
3) Loading a Jpeg XR file over the api should work, as it is reported as supported.
4) It fails with "unsupported format", because the conversion fails in the libfreeimage library, while the target image is not defined.
In essence, the JXR loading functionality is broken.
In FreeImage.h:132 _WINDOWS_ is defined, leaking over to any other include file.
Injxrlib/guiddef.h:45, the field Data1 is "unsigned long" for windows and 32-bit systems, as the windows abi defaults to 32-bit "unsigned int", while it should be 32-bit.
By becoming 64-bit, the GUID is now 4 bytes longer, which are filled then with "random" data.
Undefining "_WINDOWS_" before including "JXRGlue.h" in PluginJXR.cpp should fix the behaviour.
Better would probably to not leak the definition in the first place, but that seems a more involved task.
Find enclosed the code attempt to load a j |
1) Ubuntu 18.04.3 LTS
2) libfreeimage-dev=3.17.0+ds1-5build2, libjxr-dev=1.1-6build1
3) Loading a Jpeg XR file over the api should work, as it is reported as supported.
4) It fails with "unsupported format", because the conversion fails in the libfreeimage library, while the target image is not defined.
In essence, the JXR loading functionality is broken.
In FreeImage.h:132 _WINDOWS_ is defined, leaking over to any other include file.
Injxrlib/guiddef.h:45, the field Data1 is "unsigned long" for windows and 32-bit systems, as the windows abi defaults to 32-bit "unsigned int", while it should be 32-bit.
By becoming 64-bit, the GUID is now 4 bytes longer, which are filled then with "random" data.
Undefining "_WINDOWS_" before including "JXRGlue.h" in PluginJXR.cpp should fix the behaviour.
Better would probably to not leak the definition in the first place, but that seems a more involved task.
Find enclosed the code to attempt to load a jpeg-xr, once directly with jxr, and then with the freeimage library. |
|
