When I call the method libraw_dcraw_make_mem_image the return result is a valid image pointer, but the image->data_size is 0, as well as width + height.
The error code is 317061776, and the image is obviously invalid. The previous call to libraw_dcraw_process returns a status code of 0.
When I run the same code with half_size=1 as input, everything works fine. So I guess it's likely an error in memory allocation. The device (Android 7.0 OS) I'm working with has around 1-2 GB RAM (depending what other processes might running), and the image is from a Sony A7RII (42 Megapixels).
Is there any way to avoid this, since it seems like the device memory should be large enough to decode this fine (dcraw standalone works fine).
Same code + file works on an other device (64 Bit Binary), other images (like from Sony RX100 III) also work fine on the same device.
Dcraw does not allocate extra
Dcraw does not allocate extra memory buffer (for mem-image), so the problem may be here.
-- Alex Tutubalin @LibRaw LLC
Well I digged a little into
Well I digged a little into this, and dcraw_process runs without any exception and goes done to the "return 0" properly, but the values it's reporting afterwards (width & height) are just 0. So it seems like dcraw is failing in some kind of decoding stage, but this seems pretty strange since the overall image dimensions should be read at an early stage, shouldn't it? Is there any specific code segment I could may start looking into this more precisely?
Regards Torsten
Yes, sizes.width/height are
Yes, sizes.width/height are set on open_file() stage.
Also, files with height or width less than 22 should be rejected on this stage (identify()'s function tail)
-- Alex Tutubalin @LibRaw LLC
Followup:
Followup:
if recycle() was called somewhere due to error, it will zero imgdata.sizes structure.
Also, dcraw_make_mem_image do not call CHECK_ORDER_* macros to check is processing stage correct or not (to be fixed sometimes).
-- Alex Tutubalin @LibRaw LLC
But if an error occurred,
But if an error occurred, dcraw shouldn't return 0, or does it still continue and does not throw an exception which leads to a different result code? Because the dcraw call returns 0 which seems strange.
Yes, it should not return 0
Yes, it should not return 0
-- Alex Tutubalin @LibRaw LLC
Hmm, do you have any idea
Hmm, do you have any idea where I could start finding out what's causing this problem? dcraw is returning 0 but width+height are zero. May it's possible to fix it in future versions, that woud be great.
Regards
Torste
Is the problem persists under
Is the problem persists under x86, or it is Android-specific?
If I'll able to reproduce it under my common build environment (Windows, OS X, or FreeBSD) it will ease problem fix. Sorry, no Android tools on hands.
-- Alex Tutubalin @LibRaw LLC
I can't tell right now, the
I can't tell right now, the device in question was running an armv7 binaries. I couldn't reproduce the issue on an other device with arm 64 bit binary, but this device also had more memory. I'll try what happens if I run it on android with a x86 binary and report back.
[Edit]: On a x64 device I couldn't reproduce the same behaviour with the same image size, so it's possible that on arm are some other limits may exists. However, since I ported dcraw on arm previously and it works fine on the same device, I guess it has to do with some changes in libraw. May we can debug this, but I have no experience in debugging native code on android, the only way I'm aware of is doing logs in some lines.
Regards Torsten
After studying this problem a
After studying this problem a little more in detail, I noticed that the dcraw result failed if there was some memory fragmentation on the device. This seems to occur earlier with libraw then with dcraw (maybe because some additional allocations are made?). May it would be still possible to report clearer error when dcraw failed because of memory restrictions?
Regard Torsten
It should do so:
It should do so:
LibRaw_memmgr raises exception (LIBRAW_EXCEPTION_ALLOC) if malloc/calloc/realloc fails.
This exception is caught on upper level and error code returned.
This will broke if you compile LibRaw without C++ exceptions support (or if C++ exceptions are broken in your compiler/runtime)
-- Alex Tutubalin @LibRaw LLC