I'm designing an Android app that is now leveraging LibRaw as opposed to dcraw directly and it's been a great improvement. Thank you very much for your effort in this.
Previously I was using 'dcraw -i' to quickly check for actual raw images on a device. I didn't see anything that specifically did the same in LibRaw, but I figured simply opening the file without unpacking and checking the result should suffice and it works fine on all my test devices.
canDecodeFromFile(filePath)
{
LibRaw RawProcessor;
const char *str= env->GetStringUTFChars(filePath,0);
int result = RawProcessor.open_file(str);
env->ReleaseStringUTFChars(filePath, str);
RawProcessor.recycle();
if (result == 0)
return JNI_TRUE;
return JNI_FALSE;
}
However I'm receiving some automated hang reports from users and it traces a read within get2(). I'm not great with c so while I can find where it's hanging I don't have the knowledge to determine why. I apologize for taking your time with my lack of knowledge, but I was hoping you might have an idea why the hangs could be occurring.
Previously I found I could have a similar issue with system files which isn't surprising, but I discard any system files before scanning for the raw images now. A user I'm working with assures me that he's generating these hangs with a folder of only .NEF images.
If there's a simpler way to emulate 'dcraw -i' that's great, or if I could improve upon this method please let me know. Thanks!
Hang report:
#00 pc 0002041c /system/lib/libc.so (read+12)
#01 pc 0003d228 /data/app-lib/app-1/libraw_r.so
#02 pc 0003e01c /data/app-lib/app-1/libraw_r.so
#03 pc 0005f3c8 /data/app-lib/app-1/libraw_r.so
#04 pc 0005f6f4 /data/app-lib/app-1/libraw_r.so
#05 pc 0003d978 /data/app-lib/app-1/libraw_r.so
#06 pc 0005f9f8 /data/app-lib/app-1/libraw_r.so
#07 pc 0003c91d /data/app-lib/app-1/libraw_r.so (LibRaw_file_datastream::read(void*, unsigned int, unsigned int)+52)
#08 pc 0001199d /data/app-lib/app-1/libraw_r.so (LibRaw::get2()+36)
#09 pc 0001bf73 /data/app-lib/app-1/libraw_r.so (LibRaw::parse_tiff_ifd(int)+202)
#10 pc 0001c9e5 /data/app-lib/app-1/libraw_r.so (LibRaw::parse_tiff_ifd(int)+2876)
#11 pc 0001d96d /data/app-lib/app-1/libraw_r.so (LibRaw::parse_tiff(int)+108)
#12 pc 00022e95 /data/app-lib/app-1/libraw_r.so (LibRaw::identify()+1092)
#13 pc 000390a1 /data/app-lib/app-1/libraw_r.so (LibRaw::open_datastream(LibRaw_abstract_datastream*)+68)
at app.dcraw.LibRaw.canDecodeFromFile(Native Method)
at app.dcraw.LibRaw.canDecode(LibRaw.java:84)
at app.framework.LocalImage.canDecode(LocalImage.java:104)
There is no way to help you
There is no way to help you without 'reproducers'. I need sample file (which definitely hang).
To fully emulate dcraw behavior you need to pass second argument (max_buf_size) to LibRaw::open_file(filename, max_buf_size).
By default, small files are processed using C++ buffered streams (faster), while large files use FILE* internal interface similar to dcraw. Default value of max_buf_size is 250M.
Set it to 0 or 1 and you'll use (slower) FILE* interface for all files.
-- Alex Tutubalin @LibRaw LLC
I figured as much. Since I
I figured as much. Since I haven't been able to recreate it on any devices here I was hoping there might be a logical source that I didn't know about.
Since the issue seems to be that opening is hanging I doubt it will help, but I'll create a new build set to force FILE* input for the user to run.
Please drop a note if setting
Please drop a note if setting second open_file() parameter to 0 helps.
This means, that C++ I/O library on your platform is broken, while C FILE* I/O routines works fine.
-- Alex Tutubalin @LibRaw LLC