use_camera_wb=1 will force to use RAW-embedded color profile for Sony cameras (because use_camera_matrix is set to 1 by default, that means use it with camera-provided WB, but do not use if other WB is set). This may be problem cause if, for example, RAW-embedded profile is bad or damaged.
Could you please provide this specific raw sample for analysis? You may E-mail it to info@libraw.org (our mail server accepts up to 70Mb attachments, so most sony files, except 14-bit uncompressed 40Mpix will pass). Or upload it somewhere (Dropbox, google, WeTransfer) and send link to mail address mentioned above
Supported camera list depends on compilation flags (availability of some decompression libraries), so we do not publish this list statically.
Application can obtain actual list via API Call: https://www.libraw.org/docs/API-CXX.html#cameraList
Also, simple_dcraw example with -L switch will print this list on output.
Unfortunately, we do not have any experience on ARM, all mobile apps uses LibRaw on own risk, we're unable to provide any support for this (no development toolchain, no emulators, nothing).
If you're able to get real file samples that produces repeatable problem (and the problem is reproducible on PC/Mac), please share samples with us (info@libraw.org). Without samples it is very hard to say anything.
We have some (limited) sales of our FastRawViewer (uses LibRaw, of course) to Chinese users and there is no chinese-specific bug reports.
With respect to cinfo.err, the current code does work.
However, if you look at the definition of cinfo.err in libjpeg, it is assumed to be a pointer to a structure that contains function pointers for the error handler, exit handler, etc. The cerr pointer you pass in has that structure as its first part, but then also has a jmp_buf structure following this structure as the second part.
Somehow to my mind it is cleaner to have cinfo.err point to a "pure" function pointers block, and use cinfo.client_data to point to the jmp_buf structure. But to each his own.
JPEG thumbnails are provided as-is, libjpeg is used only to get channels count.
So, even if libjpeg fails, this does not mean bad thumbnail, calling app should test it (again)
Followup:
Input data 'pointer' (in LibRaw_datastream* data pointer passed to callback) is positioned to start of data, pointer is restored after callback called, so you just may use data->read(....) to read tag-pointed data.
You can install your own EXIF-callback and get all EXIF/TIFF tags into your app.
This callback is called:
- EXIF: tag parameter is EXIF tag ID
- Kodak Metadata: tag | 0x20000
- Panasonic metadata: tag | 0x30000
- Tiff/DNG IFDs: tag | ((ifd + 1) << 20)
(tag upper bits are for LibRaw 0.19, in 0.18 ifd# was not passed)
This callback is not called on makernotes value parsing, but will receive complete makernotes record as tag# 0x927c
Thanks for the answer, is there any api to get a sub-sampled version of the image data buffer because I guess it should be enough to calculate an histogram.
use_camera_wb=1 will force to use RAW-embedded color profile for Sony cameras (because use_camera_matrix is set to 1 by default, that means use it with camera-provided WB, but do not use if other WB is set). This may be problem cause if, for example, RAW-embedded profile is bad or damaged.
Could you please provide this specific raw sample for analysis? You may E-mail it to info@libraw.org (our mail server accepts up to 70Mb attachments, so most sony files, except 14-bit uncompressed 40Mpix will pass). Or upload it somewhere (Dropbox, google, WeTransfer) and send link to mail address mentioned above
Thanks.
:Jack
meanwhile, we added list for 0.19 release (now in beta): https://www.libraw.org/supported-cameras#
Supported camera list depends on compilation flags (availability of some decompression libraries), so we do not publish this list statically.
Application can obtain actual list via API Call: https://www.libraw.org/docs/API-CXX.html#cameraList
Also, simple_dcraw example with -L switch will print this list on output.
Hi...
Please accept my apology if this question is answered elsewhere - is there a list of all the digital cameras currently supported by LibRAW?
Thanks.
Hi,
do you mind to share the Mac and Win jni libraries to this community? :-D
Thanks
Thank you for the patch.
Too late for 0.19 (do not want to change ABI), but to be included in master branch (and, so, in next stable release)
Unfortunately, we do not have any experience on ARM, all mobile apps uses LibRaw on own risk, we're unable to provide any support for this (no development toolchain, no emulators, nothing).
If you're able to get real file samples that produces repeatable problem (and the problem is reproducible on PC/Mac), please share samples with us (info@libraw.org). Without samples it is very hard to say anything.
We have some (limited) sales of our FastRawViewer (uses LibRaw, of course) to Chinese users and there is no chinese-specific bug reports.
Thanks -- very helpful!
I agree this is a much better fix and will apply it to my copy. Thanks!
This patch fixes it right way: https://github.com/LibRaw/LibRaw/commit/3d1dba8dcbf8ea533f44cc06354846ed...
And, yes, this points to two-part structure: pointers table + additional jump buffer.
I do not see anything bad here.
Agree, it may fail in bad loop here. To be fixed in beta2
return definitely needed here, also error should be indicated by
T.tformat = LIBRAW_THUMBNAIL_UNKNOWN;
With respect to cinfo.err, the current code does work.
However, if you look at the definition of cinfo.err in libjpeg, it is assumed to be a pointer to a structure that contains function pointers for the error handler, exit handler, etc. The cerr pointer you pass in has that structure as its first part, but then also has a jmp_buf structure following this structure as the second part.
Somehow to my mind it is cleaner to have cinfo.err point to a "pure" function pointers block, and use cinfo.client_data to point to the jmp_buf structure. But to each his own.
You still need the return statement, otherwise if jpeg_create_decompress fails, won't it fail again after the longjmp?
And 1st patch:
cinfo.err is pointer, it does not need to have 'space' for longjump, it just points to already allocated structure.
Standard (no -q N) X-Trans interpolation is 3-pass Markesteijn method. Yes, it is slow (esp. compared with half demosaic)
JPEG thumbnails are provided as-is, libjpeg is used only to get channels count.
So, even if libjpeg fails, this does not mean bad thumbnail, calling app should test it (again)
Followup:
Input data 'pointer' (in LibRaw_datastream* data pointer passed to callback) is positioned to start of data, pointer is restored after callback called, so you just may use data->read(....) to read tag-pointed data.
You can install your own EXIF-callback and get all EXIF/TIFF tags into your app.
This callback is called:
- EXIF: tag parameter is EXIF tag ID
- Kodak Metadata: tag | 0x20000
- Panasonic metadata: tag | 0x30000
- Tiff/DNG IFDs: tag | ((ifd + 1) << 20)
(tag upper bits are for LibRaw 0.19, in 0.18 ifd# was not passed)
This callback is not called on makernotes value parsing, but will receive complete makernotes record as tag# 0x927c
i'd like to see that article too!
Bad cam_mul values issue finally fixed in 0.19-stable branch (preparing 0.19-beta2): https://github.com/LibRaw/LibRaw/commit/d4420a4dac0d1f232629f7f163fb59d7...
Finally: it is fixed in LibRaw 0.19 (now in beta): COLOR() will check xtrans mask for xtrans files.
raw data are stored into imgdata.rawdata.raw_image[] array, available for both read and write.
This 'API' allows easy sampling with any stride, if you need sampled data.
Thanks for the answer, is there any api to get a sub-sampled version of the image data buffer because I guess it should be enough to calculate an histogram.
Pages