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.
RawSpeed team is focused mostly on code rewrite and cleanup and on correct handling of corner cases (e.g. fuzzer testing, etc). This is very important work, but in reality users of RAW processing software usually feeds it by files created by cameras, but not random crap generated by fuzzer.
So, I'm somewhat skeptical about current RawSpeed state. It has very strong features (e.g. LJPEG decoder is really ~30% faster on Canon 5Ds files, this is vital for apps build for speed /like our FastRawViewer/), but focusing on 'pure software development process' (code cleanup, modern C++ rewrite, fuzzer testing) instead of handling real issues is, at least, questionable from my point of view.
Most likely, we'll support 'RawSpeed devel' (do not know exact version is it v3 or v4 now) in LibRaw after 0.19 release (so, this year).
Very probable, that support will use some 'whitelisting', so only known/tested camera files to be passed to RawSpeed decoder (and, sure, this list will be empty by default).
P.S. RawSpeed has imported our (LibRaw) compressed fuji decoder and provided feedback was very useful, we fixed two (or so) corner cases based on it.
RawSpeed is maintained here now: https://github.com/darktable-org/rawspeed There have been new versions and changes to the code. Is this something LibRaw supports currently? If not, does it make sense to add support?
Yes, camera profiles are already camera-RGB-to-sRGB, so matrix mentioned does not matter in color space conversion. It is used only in output profile calculations (this profile is embedded into TIFF files recorded by dcraw_ppm_tiff_writer())
To match camera JPEG colors you need to use same (in-camera) color profile and tonal (contrast) curve.
Hi Alex,
Nice to know you and glad to know you had a team to handle the growing up of Libraw. I have some questions about Libraw team's operation and further update plan. If you don't mind, can you share your E-mail for having more detail discussion? Or you can contact me through "josephlintw@icloud.com", thx.
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.
Histogram is built during postprocessing stage if auto-exposure is used.
Raw data are accessible after LibRaw::unpack() call, so histogram calculation is trivial single loop over all pixels.
RawSpeed team is focused mostly on code rewrite and cleanup and on correct handling of corner cases (e.g. fuzzer testing, etc). This is very important work, but in reality users of RAW processing software usually feeds it by files created by cameras, but not random crap generated by fuzzer.
On the other side, the real issue with real files created by real camera is not fixed for 10 months: https://github.com/darktable-org/rawspeed/issues/100 (is this library really *maintained* ?)
So, I'm somewhat skeptical about current RawSpeed state. It has very strong features (e.g. LJPEG decoder is really ~30% faster on Canon 5Ds files, this is vital for apps build for speed /like our FastRawViewer/), but focusing on 'pure software development process' (code cleanup, modern C++ rewrite, fuzzer testing) instead of handling real issues is, at least, questionable from my point of view.
Most likely, we'll support 'RawSpeed devel' (do not know exact version is it v3 or v4 now) in LibRaw after 0.19 release (so, this year).
Very probable, that support will use some 'whitelisting', so only known/tested camera files to be passed to RawSpeed decoder (and, sure, this list will be empty by default).
P.S. RawSpeed has imported our (LibRaw) compressed fuji decoder and provided feedback was very useful, we fixed two (or so) corner cases based on it.
RawSpeed is maintained here now: https://github.com/darktable-org/rawspeed There have been new versions and changes to the code. Is this something LibRaw supports currently? If not, does it make sense to add support?
Yes, camera profiles are already camera-RGB-to-sRGB, so matrix mentioned does not matter in color space conversion. It is used only in output profile calculations (this profile is embedded into TIFF files recorded by dcraw_ppm_tiff_writer())
To match camera JPEG colors you need to use same (in-camera) color profile and tonal (contrast) curve.
No. Only full-size and half-size (for bayer). Or cropped.
Does dcraw_emu have any option to resize the output other than -h, with the caveats as you described?
You can contact us via info@libraw.org, or via this site Feedback form (https://www.libraw.org/contact )
Hi Alex,
Nice to know you and glad to know you had a team to handle the growing up of Libraw. I have some questions about Libraw team's operation and further update plan. If you don't mind, can you share your E-mail for having more detail discussion? Or you can contact me through "josephlintw@icloud.com", thx.
That worked like a charm! : )
Thank you.
Pages