Found out this is an issue with <=0.14-7 and is fixed since 0.15-alpha1 because of using the 9.17th version of dcraw..
Also kind of fixed my mingw compiling issue with 0.15-beta2: MinGw also defines the WIN32 flag resulting in using the not existing wchar_t type. I had to throw out theese defines in like 5 source files to fix this but now it works.. so what i basically would advice is to change the check if WIN32 is defined into ( WIN32 && !MINGW ).. then it should compile without issues..
I investigated the issue further and dumped the raw bayer values from .imgdata.rawdata.raw_image. The issue i described above is already present in the bayer data itself, so i assume the problem lies in the unpack function and not in the furthor processing.
Fixed everything and it was completely user error. The calls were threaded and hence the logging was misleading as to where the crashing occurred.
Taught myself coding mainly in Java/C#, so memory issues in c are over my head. Sorry to bother you with silly issues.
Now that it's working however I just wanted to say it's running great and extremely fast. Previously I was running threads off separate dcraw library builds (ghetto, but it let me thread). This is much much cleaner and faster to boot. Thanks!!!
Thanks for the quick response. In the case of the second segment of code, I was trying to create a "canDecode" method to test with. I was still getting the memory error there. Is there anything I must do to clean up after an open_buffer call fails?
For non-image file LibRaw will return LIBRAW_FILE_UNSUPPORTED return code.
This error is not 'fatal', so LIBRAW_FATAL_ERROR is 'false' for this return code.
It is better to compare return code with LIBRAW_SUCCESS.
dcraw_make_mem_thumb() will return NULL pointer to image variable, so image->data_size will result to memory access error.
And it is now in 0.15-Beta2: return type of subtract_black() is changed to int, returns according to LibRaw convention (0 on success, error code on error)
LibRaw::raw2image() allocates imgdata.image[] array and copies data from internal storage (different for Bayer and non-bayer images) to this array.
No demosaic, no black subtration, this is for developers who want to do processing by hand.
So, three ways exists:
- unpack() + raw2image() - this produce internal data compatible with old LibRaw (0.9-0.13)
- unpack + dcraw_process() - for full processing
- only unpack() but you need to know LibRaw internals, because different data types (bayer vs non-bayer) are stored in different way.
Sure, internals may change in future LibRaw releases, so it is safer to use unpack() + raw2image, although it requires extra RAM.
1) Black should be subtracted before demosaic
2) Look into convert_to_rgb code:
to get output matrix, the rgb_cam matrix is multiplied to color space matrix. The rgb_cam is produced by cam_xyz_coeff() call
File seems ok. It was a subtle synchronization problem in my code. I was just surprised it occured in the same method all the time. Thanks for the quick reply!
This issue should be fixed in 0.15-Beta2 and later:
#if defined(WIN32) && !defined(__MINGW32__) virtual const wchar_t* wfname(){ return NULL;}; virtual int subfile_open(const wchar_t*) { return -1;} #endifLightRoom 'fast load' DNGs are supported only in LibRaw 0.15
Found out this is an issue with <=0.14-7 and is fixed since 0.15-alpha1 because of using the 9.17th version of dcraw..
Also kind of fixed my mingw compiling issue with 0.15-beta2: MinGw also defines the WIN32 flag resulting in using the not existing wchar_t type. I had to throw out theese defines in like 5 source files to fix this but now it works.. so what i basically would advice is to change the check if WIN32 is defined into ( WIN32 && !MINGW ).. then it should compile without issues..
I investigated the issue further and dumped the raw bayer values from .imgdata.rawdata.raw_image. The issue i described above is already present in the bayer data itself, so i assume the problem lies in the unpack function and not in the furthor processing.
These parameters are accessible via
imgdata.idatasub-structure.Fixed everything and it was completely user error. The calls were threaded and hence the logging was misleading as to where the crashing occurred.
Taught myself coding mainly in Java/C#, so memory issues in c are over my head. Sorry to bother you with silly issues.
Now that it's working however I just wanted to say it's running great and extremely fast. Previously I was running threads off separate dcraw library builds (ghetto, but it let me thread). This is much much cleaner and faster to boot. Thanks!!!
You may call LibRaw::recycle()
You don't *need* to do this because recycle() is called in the beginning of each open_buffer().
Thanks for the quick response. In the case of the second segment of code, I was trying to create a "canDecode" method to test with. I was still getting the memory error there. Is there anything I must do to clean up after an open_buffer call fails?
For non-image file LibRaw will return LIBRAW_FILE_UNSUPPORTED return code.
This error is not 'fatal', so LIBRAW_FATAL_ERROR is 'false' for this return code.
It is better to compare return code with LIBRAW_SUCCESS.
dcraw_make_mem_thumb() will return NULL pointer to image variable, so image->data_size will result to memory access error.
I've also created a test with various releases for the byte array data, but always the same error on non image files:
wchar_t* interface is disabled for MinGW in 0.15 Beta2
And it is now in 0.15-Beta2: return type of subtract_black() is changed to int, returns according to LibRaw convention (0 on success, error code on error)
BTW, thanks for bugreport. I'll add new processing stage to internals and subtract_black() will check that raw2image is called.
LibRaw::raw2image() allocates imgdata.image[] array and copies data from internal storage (different for Bayer and non-bayer images) to this array.
No demosaic, no black subtration, this is for developers who want to do processing by hand.
So, three ways exists:
- unpack() + raw2image() - this produce internal data compatible with old LibRaw (0.9-0.13)
- unpack + dcraw_process() - for full processing
- only unpack() but you need to know LibRaw internals, because different data types (bayer vs non-bayer) are stored in different way.
Sure, internals may change in future LibRaw releases, so it is safer to use unpack() + raw2image, although it requires extra RAM.
No, I try only call unpack(), the application works directly over raw data.
substract_black() works only over demosaicing data ?
Thank's a lot.
It looks like wchar_t strings are not supported in MinGW's libstdc++. I'll try to reproduce before next beta wiil be released.
This is LibRaw calls. So, it looks like you do not properly link with LibRaw
1) Black should be subtracted before demosaic
2) Look into convert_to_rgb code:
to get output matrix, the rgb_cam matrix is multiplied to color space matrix. The rgb_cam is produced by cam_xyz_coeff() call
Thank you for your proposal, sure it is possible
Do you called raw2image() before calling subtract_black() ?
Thanks! I'll check it out.
libraw_open_wfile/open_wfile_ex added in 0.15-Beta1
File seems ok. It was a subtle synchronization problem in my code. I was just surprised it occured in the same method all the time. Thanks for the quick reply!
Could you please check this file with dcraw_emu sample?
Both 0.14.7 and 0.15-Alpha4 (both - Windows version) works OK.
I use dcraw_emu sample for testing.
Pages