Coolscan 4000 is not in the list of supported cameras :)
Generally, files from Scanners should be 3-component, not bayer-pattern. So, camera-targeted NEF-handling code will not work with scanner files because only one per-pixel component is expected.
BTW, if you provide any sample of Coolscan .NEF output, it will be analyzed in depth. May be, it is easy to add support for these files to LibRaw
Could you please provide more details about your working environment:
- what application do you use for decode files?
- what LibRaw version do you use?
I finally can display the image using LibRaw together with OpenCV. However, I found that it is okay to display .CR2 files of 5D Mark III but .CR2 files of 5D Mark II. It gives a error:
"An unhandled exception of type 'System.ArgumentException' occurred in System.Drawing.dll
Additional information: Parameter is not valid."
Is there any difference between the .CR2 files of 5D Mark II and Mark III?
My code is:
int check = Processor1->dcraw_process();
//process the image into memory buffer
libraw_processed_image_t *image = Processor1->dcraw_make_mem_image(&check);
//create a Mat object by data obtained from LibRaw
cv::Mat cvImage(cv::Size(image->width, image->height), CV_8UC3, image->data, cv::Mat::AUTO_STEP);
cv::cvtColor(cvImage, cvImage, CV_RGB2BGR); //Convert RGB to BGR
IntPtr ptr(cvImage.ptr()); //create a pointer based on the Mat object image
//Error occurs in the following statement, the last line with 'ptr'
Bitmap^ b = gcnew Bitmap(cvImage.cols,
cvImage.rows,
cvImage.step,
PixelFormat::Format24bppRgb,
ptr); //bitmap object of the image
I'm trying to open phase one images which have PPM thumbnails. When I extract the thumbnail with dcraw I get PPM. When I use libraw I seem to get just the RGB data, without the PPM header. Am I doing something wrong or is it getting stripped?
LibRaw does not contain any drawing code. You need to implement it yourself.
Histograms are calculated for auto-brightness code, but these histograms are not intended to use in external application:
- histograms calculated before white balance and brightness applied
- the actual pixel value is divided by 8 to make histograms compact.
Could you please specify camera model you use? In most cases thumbnails are JPEG, the RGB case is very rare.
It is possible that somewhat is broken, so I should test with your sample.
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.
Coolscan 4000 is not in the list of supported cameras :)
Generally, files from Scanners should be 3-component, not bayer-pattern. So, camera-targeted NEF-handling code will not work with scanner files because only one per-pixel component is expected.
BTW, if you provide any sample of Coolscan .NEF output, it will be analyzed in depth. May be, it is easy to add support for these files to LibRaw
Could you please provide more details about your working environment:
- what application do you use for decode files?
- what LibRaw version do you use?
I'm not OpenCV specialist, so I cannot help with OpenCV/System.drawing errors.
I finally can display the image using LibRaw together with OpenCV. However, I found that it is okay to display .CR2 files of 5D Mark III but .CR2 files of 5D Mark II. It gives a error:
"An unhandled exception of type 'System.ArgumentException' occurred in System.Drawing.dll
Additional information: Parameter is not valid."
Is there any difference between the .CR2 files of 5D Mark II and Mark III?
My code is:
int check = Processor1->dcraw_process();
//process the image into memory buffer
libraw_processed_image_t *image = Processor1->dcraw_make_mem_image(&check);
//create a Mat object by data obtained from LibRaw
cv::Mat cvImage(cv::Size(image->width, image->height), CV_8UC3, image->data, cv::Mat::AUTO_STEP);
cv::cvtColor(cvImage, cvImage, CV_RGB2BGR); //Convert RGB to BGR
IntPtr ptr(cvImage.ptr()); //create a pointer based on the Mat object image
//Error occurs in the following statement, the last line with 'ptr'
Bitmap^ b = gcnew Bitmap(cvImage.cols,
cvImage.rows,
cvImage.step,
PixelFormat::Format24bppRgb,
ptr); //bitmap object of the image
You may use
LibRaw* processor1;and than use
processor1= new LibRaw;in the constructor of your object
dcraw produces *file*, not in-memory object.
Dcraw file output is emulated in dcraw_emu sample
OK, I see, so that aspect of dcraw output is not emulated and that's intentional?
The PPM header is added by dcraw on file write.
I'm trying to open phase one images which have PPM thumbnails. When I extract the thumbnail with dcraw I get PPM. When I use libraw I seem to get just the RGB data, without the PPM header. Am I doing something wrong or is it getting stripped?
LibRaw does not contain any drawing code. You need to implement it yourself.
Histograms are calculated for auto-brightness code, but these histograms are not intended to use in external application:
- histograms calculated before white balance and brightness applied
- the actual pixel value is divided by 8 to make histograms compact.
Yes, you may simple pack linear 16-bit data (bayer pattern or after demosaic) into DNG
Is the content of the DNG payload a 16bit/sample stream? Or the unpacked data must be packed somehow after the processing?
Could you please specify camera model you use? In most cases thumbnails are JPEG, the RGB case is very rare.
It is possible that somewhat is broken, so I should test with your sample.
dcraw_make_mem_thumb() return thumbnail 'as is', no processing is done.
Most RAW formats stores thumbnail in JPEG format.
The only common way to write RAW files is to write DNG format ones. Adobe DNG SDK can be used for this task.
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:
Pages