My code works for Nikon DSLR cameras via imgdata.rawdata (albeit the images seem to be under-exposed) but images from Canon DSLRs are showing bad data near the top of each image. I've been reading various forum posts and it seems that I need to call raw2image() in order to get data that only contains visible (active pixels) pixels but I am struggling to get unbayered data.
It is my understanding that after calling raw2image() and without calling dcraw_process() I should have an undebayered dataset in imgdata.image[][] which only contains visible pixels, is that correct?
What I need to do is to copy data from imgdata.image[][] to a one dimensional 16-bit integer array (size is width * height) that gets saved as a FITS or a TIFF file which can then be debayered later by my post-processing application.
Here is a code example of what I am currently doing:
if ((ret = m_raw_proc->open_buffer(data, size)) != 0)
{
// Handle error
}
if ((ret = m_raw_proc->unpack() != 0))
{
// Handle error
}
if ((ret = m_raw_proc->raw2image()) != 0)
{
// Handle error
}
m_width = m_raw_proc->imgdata.sizes.iwidth;
m_height = m_raw_proc->imgdata.sizes.iheight;
for (int n = 0; n < m_width * m_height; n++)
{
buffer[n] = m_raw_proc->imgdata.image[n][0];
}
However, when I try to debayer the image in an external application, the code above is heavily bias to a specific primary colour. How do I correctly access the undebayered data from imgdata.image[][]?
Followup:
1) colors are in imdata.idata.cdesc string ('RGBG" in most cases, "CMYG" for some very old cameras, etc)
2) For RGBG (modern bayer), values returned by COLOR():
0 - Red
1 - Green
2 - Blue
3 - Green (for some cameras greens are different by black level/amplification/even color response)
Of course, this colors are repeatable in rows/columns (in 2x2 pattern for normal bayer and in 6x6 for X-Trans), so you do not need to call it on each pixel
Thank you Alex, this is exactly what I wanted. I can now get a raw undebayered buffer from LibRaw and display it on my image preview screen as a greyscale image. Of course, I see the bayer pattern on the preview display. Ultimately, I would like to be able to debayer the buffer using a nearest neighbour algorithm purely for the live preview screen and save a undebayered TIFF files.
This leads me onto my final question. Is it possible for LibRaw to return the camera bayer pattern, for example, RGGB, BGGR, GBGR or GRGB or is this not possible?
Original RAW data (after LibRaw::unpack) is available via imgdata.rawdata. arrays (raw_image - for bayer, X-Trans or monochrome, color3_image for 3-color non-bayer files, color4_image for 4-color ones; Only one of these pointers is non-NULL after unpack() call).
Note: this array(s) contains unpacked RAW pixels without any adustment/cropping:
- masked (black area) pixels are in place, pixel array size is imgdata.sizes.raw_width x raw_height
- black level not subtracted
Hi!
I found the 100 MP sensor is included in LibRaw supported camera list but for different camera models from Phase One. I was working with Phase One iXG 100 MP, and thought give a try how the output look like after default demosaicing. The output is more greenish (which is not correct) in output tiff ( dcraw_emu -v -dcbe -T input.IIQ ).
Any good suggestion on this unsupported camera issue? I have attached the output.
Beyond the core library, you also provide a few command line tools with your installation package.
Could you add support for reporting header details per included raw image if a file contains more than one frame? I hope this way I can find a way to discover if there are differences in the attributes of both contained images, to tell apart "High Resolution" from "Dynamic Range" dual capture raw image files by comparing their attributes.
I believe hardly any software at all is aware of raw image files possibly containing more than one image frame.
from RGB to sRGB is a two step conversation process, first RGB to XYZ,as you mentioned. But as it is a linear conversation process the conversion matrix (3*3) should be appropriate for the camera model and lighting condition (e.g. D65). from XYZ to sRGB could be another conversation matrix.
Further to my original post.
My code works for Nikon DSLR cameras via imgdata.rawdata (albeit the images seem to be under-exposed) but images from Canon DSLRs are showing bad data near the top of each image. I've been reading various forum posts and it seems that I need to call raw2image() in order to get data that only contains visible (active pixels) pixels but I am struggling to get unbayered data.
It is my understanding that after calling raw2image() and without calling dcraw_process() I should have an undebayered dataset in imgdata.image[][] which only contains visible pixels, is that correct?
What I need to do is to copy data from imgdata.image[][] to a one dimensional 16-bit integer array (size is width * height) that gets saved as a FITS or a TIFF file which can then be debayered later by my post-processing application.
Here is a code example of what I am currently doing:
if ((ret = m_raw_proc->open_buffer(data, size)) != 0) { // Handle error } if ((ret = m_raw_proc->unpack() != 0)) { // Handle error } if ((ret = m_raw_proc->raw2image()) != 0) { // Handle error } m_width = m_raw_proc->imgdata.sizes.iwidth; m_height = m_raw_proc->imgdata.sizes.iheight; for (int n = 0; n < m_width * m_height; n++) { buffer[n] = m_raw_proc->imgdata.image[n][0]; }However, when I try to debayer the image in an external application, the code above is heavily bias to a specific primary colour. How do I correctly access the undebayered data from imgdata.image[][]?
Thanks
Amanda
Thanks Alex,
I now have my application working perfectly.
Amanda
Followup:
1) colors are in imdata.idata.cdesc string ('RGBG" in most cases, "CMYG" for some very old cameras, etc)
2) For RGBG (modern bayer), values returned by COLOR():
0 - Red
1 - Green
2 - Blue
3 - Green (for some cameras greens are different by black level/amplification/even color response)
https://www.libraw.org/docs/API-CXX.html#COLOR will return pixel color for (row,col).
Of course, this colors are repeatable in rows/columns (in 2x2 pattern for normal bayer and in 6x6 for X-Trans), so you do not need to call it on each pixel
Thank you Alex, this is exactly what I wanted. I can now get a raw undebayered buffer from LibRaw and display it on my image preview screen as a greyscale image. Of course, I see the bayer pattern on the preview display. Ultimately, I would like to be able to debayer the buffer using a nearest neighbour algorithm purely for the live preview screen and save a undebayered TIFF files.
This leads me onto my final question. Is it possible for LibRaw to return the camera bayer pattern, for example, RGGB, BGGR, GBGR or GRGB or is this not possible?
Once again, thank you.
Amanda
Thank you very much!
dcraw_emu sample supports both TIFF output and cropping.
Original RAW data (after LibRaw::unpack) is available via imgdata.rawdata. arrays (raw_image - for bayer, X-Trans or monochrome, color3_image for 3-color non-bayer files, color4_image for 4-color ones; Only one of these pointers is non-NULL after unpack() call).
Note: this array(s) contains unpacked RAW pixels without any adustment/cropping:
- masked (black area) pixels are in place, pixel array size is imgdata.sizes.raw_width x raw_height
- black level not subtracted
Please wait until public snapshot.
Is the code with CR3 support available in some private branch? I would like to test if it is available.
Could you please provide image sample?
Answered in another sub-thread: https://www.libraw.org/comment/5396#comment-5396
Dear Sir:
could you please share image sample (e.g. upload it to Dropbox/WeTransfer/Mega.NZ/etc and send link to info@libraw.org)
Also, as shot/automatic white balance (-w or -a switch for dcraw_emu) most likely will work.
Hi!
I found the 100 MP sensor is included in LibRaw supported camera list but for different camera models from Phase One. I was working with Phase One iXG 100 MP, and thought give a try how the output look like after default demosaicing. The output is more greenish (which is not correct) in output tiff ( dcraw_emu -v -dcbe -T input.IIQ ).
Any good suggestion on this unsupported camera issue? I have attached the output.
In next public snapshot (this Fall)
Hi,
any idea of when you plan to suport these cameras ?
Thank you.
Best Regards,
Well, one more question...
Beyond the core library, you also provide a few command line tools with your installation package.
Could you add support for reporting header details per included raw image if a file contains more than one frame? I hope this way I can find a way to discover if there are differences in the attributes of both contained images, to tell apart "High Resolution" from "Dynamic Range" dual capture raw image files by comparing their attributes.
I believe hardly any software at all is aware of raw image files possibly containing more than one image frame.
Thanks, problem soved.
Thanks Alex, it's working smoothly what I needed. unprocessed_raw -T Image.CR2
There is no direct alternative to dcraw -d/-D in LibRaw's dcraw_emu
Use unprocessed_raw and/or 4channels samples to dump unaltered raw data.
Usually a matrix link is calculated first, to keep things happening in one step.
from RGB to sRGB is a two step conversation process, first RGB to XYZ,as you mentioned. But as it is a linear conversation process the conversion matrix (3*3) should be appropriate for the camera model and lighting condition (e.g. D65). from XYZ to sRGB could be another conversation matrix.
CR3 support is expected in next public snapshot this Fall
Hey there! Thanks for your work! Will you add CR3 support to LibRaw?
OK understood, thanks
Pages