I have setup an exif parser callback. I correctly receive the copyright tag. I assume I have to read his value using passed ifp argument (The pointer to LibRaw_abstract_datastream input stream, positioned to start of data). But how can I do that using the C API?
Context: My program is written with Delphi which can use any C-API from DLL, but Delphi can't use C++ objects.
That is not suitable because I'm searching for "copyright" and all pages contain that word so there are no result related to message forum containing that word.
We are happy to accept additions if they do not violate the general ideology of the library and solve a problem of interest to more than one user.
Please use github pull requests for such a contributions.
Delphi/other language wrappers are out of our interest because we'll unable to support such improvements.
OK, I understand. Sorry, I'm new to LibRaw.
If I do the changes/additions, will it be merged in the distribution for next revision?
My current work is to create a Delphi wrapper so that LibRaw can be easily used by Delphi developers. This wrapper will be open-source and made available in a GitHub repository (Or even better - if it is possible directly - in the LibRaw repository).
The problem is that I use the LibRaw.dll and his C API (My code is written with Delphi). And there is no access [as far as I can see] to the data structure required to implement a tiff writer. So I have to implement it is C++ and expose the function in the C API dll. The final effect is that my application will have to use a special DLL. I don't like the idea.
IMO LibRaw should expose a complete unicode API which is standard nowadays.
LibRaw::open_file(wchar_t *) has to be used to open a file having Unicode filename. But LibRaw::dcraw_ppm_tiff_writer has no unicode version. Am I supposed to write my own or is there a work around?
BTW: I am working under Windows and all filenames are Unicode.
Address sanitizer is still on. I need to find ways to disable it in the RawSpeed3 source code (not sure how right now).
Do you see speed improvements with RAWSpeed 3 in general? Is it faster than the original RAWSpeed or does it simply offer more RAW file decode for different camera brands?
1) Sorry, we do not offer advice on building RawSpeed3 as mentioned in the provided README
It is definitely possible to build it w/o address sanitizer.
We're not Cmake users, so I do not know what is 'target_sources(rawspeed_get_number_of_processor_cores....' message
2) LIBRAW_DECODER_TRYRAWSPEED3 bit is set in get_decoder_info() code. There is no way to change it from your app and no need for that.
LIBRAW_DECODER_TRYRAWSPEED3 bit is set only for decoders that are definitely faster in RawSpeed3, not for all decoders provided by the library (for example, it is mostly useless to decode unpacked/uncompressed data via RawSpeed3: it uses additional memory buffer for the decoded file with little or no benefit)
3) If you compile LibRaw with USE_RAWSPEED_BITS define, you need to set LIBRAW_RAWSPEEDV3_USE bit in imgdata.rawparams.use_rawspeed
If you compile LibRaw with just USE_RAWSPEED3 define, imgdata.rawparams.use_rawspeed=1 is enough.
I have setup an exif parser callback. I correctly receive the copyright tag. I assume I have to read his value using passed ifp argument (The pointer to LibRaw_abstract_datastream input stream, positioned to start of data). But how can I do that using the C API?
Context: My program is written with Delphi which can use any C-API from DLL, but Delphi can't use C++ objects.
That is not suitable because I'm searching for "copyright" and all pages contain that word so there are no result related to message forum containing that word.
Thanks. I will try using EXIF callback. I come here again if I can't make it work.
Regards
Followup: but one may use exif callback and parse/retrieve all EXIF tags: https://www.libraw.org/docs/API-datastruct-eng.html#libraw_callbacks_t
Exif tag 0x8298 is not parsed by LibRaw
Please use google with site: specifier
Thanks.
:Jack
Thanks - this was a helpful clue. I tried compiling it using a slightly less old version of Visual Studio - VS 2013 - and it worked perfectly.
Thanks for your help and for your excellent library. Stay safe.
:Jack
return this->operator[](_fpos - _bstart);
We compile 32-bit libraw for 32-bit RawDigger using MSVC 2010 with no such problem.
data() member is listed for std::vector since C++11
We are happy to accept additions if they do not violate the general ideology of the library and solve a problem of interest to more than one user.
Please use github pull requests for such a contributions.
Delphi/other language wrappers are out of our interest because we'll unable to support such improvements.
OK, I understand. Sorry, I'm new to LibRaw.
If I do the changes/additions, will it be merged in the distribution for next revision?
My current work is to create a Delphi wrapper so that LibRaw can be easily used by Delphi developers. This wrapper will be open-source and made available in a GitHub repository (Or even better - if it is possible directly - in the LibRaw repository).
> LibRaw should....
LibRaw is open-source, we welcome contributions from other developers
The problem is that I use the LibRaw.dll and his C API (My code is written with Delphi). And there is no access [as far as I can see] to the data structure required to implement a tiff writer. So I have to implement it is C++ and expose the function in the C API dll. The final effect is that my application will have to use a special DLL. I don't like the idea.
IMO LibRaw should expose a complete unicode API which is standard nowadays.
Yes, ppm_tiff_writer is a sample code only to allow LibRaw samples to write output files.
You may re-implement it, or use dcraw_mem_image() to create in-memory bitmap and save it using your own code.
LibRaw::open_file(wchar_t *) has to be used to open a file having Unicode filename. But LibRaw::dcraw_ppm_tiff_writer has no unicode version. Am I supposed to write my own or is there a work around?
BTW: I am working under Windows and all filenames are Unicode.
Thank you.
Windows: use LibRaw::open_file(wchar_t *)
macOS: LibRaw::open_file(char*) accepts UTF-8 filenames.
Other operating system: do not know :), you probably may need to implement own LibRaw datastream.
Yes, this is expected speed-up for huffman compressed files.
Managed to turned off sanitizer and RawSpeed 3 is about 20-40+% faster than RawSpeed v1. Sony A7RM4 RAW decode speed is like 2x.
Huffman decoder is faster.
Address sanitizer is still on. I need to find ways to disable it in the RawSpeed3 source code (not sure how right now).
Do you see speed improvements with RAWSpeed 3 in general? Is it faster than the original RAWSpeed or does it simply offer more RAW file decode for different camera brands?
I'm also unsure. Do you still use address sanitizer?
I recompiled without USE_RAWSPEED_BITS and RawSpeed3 appeared to have been called when I decode a certain Sony ARW images.
But performance is terrible. Like 4.5x slower.
Not sure what is going on.
1) Sorry, we do not offer advice on building RawSpeed3 as mentioned in the provided README
It is definitely possible to build it w/o address sanitizer.
We're not Cmake users, so I do not know what is 'target_sources(rawspeed_get_number_of_processor_cores....' message
2) LIBRAW_DECODER_TRYRAWSPEED3 bit is set in get_decoder_info() code. There is no way to change it from your app and no need for that.
LIBRAW_DECODER_TRYRAWSPEED3 bit is set only for decoders that are definitely faster in RawSpeed3, not for all decoders provided by the library (for example, it is mostly useless to decode unpacked/uncompressed data via RawSpeed3: it uses additional memory buffer for the decoded file with little or no benefit)
3) If you compile LibRaw with USE_RAWSPEED_BITS define, you need to set LIBRAW_RAWSPEEDV3_USE bit in imgdata.rawparams.use_rawspeed
If you compile LibRaw with just USE_RAWSPEED3 define, imgdata.rawparams.use_rawspeed=1 is enough.
Pages