Alex,
This API call appears to only impact the output width/height. Do we treat this to be the visible dimensions (height/width) to just extract the visible portion of the RAW data?
Does this mean the COLOR(r, c) does not work for these formats?
To reiterate, what I am trying to do is extract the Visible Portion of the RAW Image and implement the pipeline myself? Will calling raw2image() on this image only give me the visible portion of the CFA? If so, what dimensions should I assume the resulting buffer has
So, is there a way to identify if the file is from a Super-CCD sensor such that I can branch my code to handle it separately.
Alex,
Thanks for that. I will read up on Fuji Super CCD images and go over the dcraw code.
Does that mean that some of the properties in the sizes field such as width, height are incorrect/invalid for these files? I was just trying to just read out the visible part of the raw image for me to apply my own camera pipeline.
Also, how do I identify if a file has Super-CCD sensor?
This is the way how Fuji Super-CCD files are processed (this method borrowed from dcraw.c):
- raw data is not 2:3 but stretched in one dimension (different for different cameras)
- color order is not rg/gb, but green columns and r/b columns
On processing:
- entire image is rotated 45 deg to get normal bayer pattern with diagonal greens (it is also unstretched to get 2:3 aspect ratio)
- standard debayering is used
- output rotated back and cropped
Matrix conversion is not gamut limited (unless you cut negative values in some intermediate steps)
ccm is 'camera matrix parsed from metadata. period', it is preserved as is (w/ possible value normalization). Usually it 'just some color data with not known camera/vendor specific meaning'.
That makes perfect sense. So, the matrix to convert from camera space to XYZ becomes xyz_rgb*rgb_cam. Does that impact the gamut of colors that can be represented as Camera Space -> sRGB is a narrowing conversion?
But, what exactly is ccm? I know in your earlier comment you mentioned
"ccm is also 'camera color matrix' retireved from RAW in 'as is' (excl. normalizing) form."
Alex,
A quick follow up. So based on your descriptions, cmatrix is the transformation from Camera Space to sRGB.
Is ccm similar to cam_xyz i.e. transformation between Camera Space and XYZ?
I have a DNG file shot from a Google Pixel 3 that has all-zeros for cam_xyz and ccm. The rgb_cam and cmatrix have the same values. The profile is also not available.
For such files, how do I convert from input space/camera space to XYZ?
I'm not sure, that margins are also multiple of 6 in 0.19. Extra effort is needed to analyze (source inspection, may be debugger session), so I won’t do it,
If not, xtrans[][] is for visible area, xtrans_abs[][] is for entire sensor (make sure you use LibRaw-provided margins).
0 is 'channel #0', 1 is 'channel #1', etc. Index to name mapping is in imgdata.idata.cdesc[] string.
LibRaw provided margins (left_margin, top_margin) are multiple of 6 (at least in 0.20 beta and in latest snapshots), so xtrans and xtrans_abs are the same.
Thanks for the quick reply. Then I think I will need to do heavy processing for useful data.
Can I ask your opinion on this matter:
-I am currently working on "image matching with stereo camera". I am looking for away to match the same pixel between left image and right image.
-With the 8 bit data in jpg, sometimes the matching will not be so correct, for example: (pixel of 112.02 will become 112) and (pixel of 111.8 will also become 112). Therefore, they might be considered as a match but it is not true.
Do you think by taking the raw data for processing I can get better matching result? or Raw data are just too noisy for the matching task?
Thanks
Short answer: No
RAW values unpacked from RAW file are:
- in linear gamma
- white balance not applied
- black level not subtracted (for most cases; some cameras do black subtraction).
Hi Alex,
Now I am looking for a way to get the process data where you have subtracted the black level, w/ white balance and demosaic, can you please help to explain the procedure? Thanks!
So, to my knowledge, bayer image would be greyscale (but with 10/12/or 14 bit depending on your camera raw image). Is it correct?
If yes, them if I map those Bayer values into (int)(0 -255), would it be similar to the greyscale.jpg (8 bit) file?
Thanks
Hi Alex,
I use the prebuilt library for win 64 and successfully embedded into visual studio. I would like to share my method as following:
1. Extract the binaries for x64.
2. Go into visual project. Open Project Properties, In Configuration Properties:
a. /Debugging/Enviornment: add the path to LibRaw-xxx\bin
b. /C/C++/General/Additional Include Directories: add the path to LibRaw-xxx\
c. /Linker/General/Additional Library Directories: add the path to LibRaw-xxx\lib
/Linker/Input/Additional Dependencies: add libraw.lib and libraw_static.lib
My testing code is following:
int main() {
// Let us create an image processor
LibRaw iProcessor;
// Open the file and read the metadata
iProcessor.open_file("D:/[01]Luan_van_thac_si/PROJECT/Non_Cuda/SLIC/SLICSuperPixel/DSC01042.ARW");
// The metadata are accessible through data fields of the class
cout << "Image width = " << static_cast(iProcessor.imgdata.sizes.width)
<< ", Image height = " << static_cast(iProcessor.imgdata.sizes.height) << endl;
waitKey();
return 0;
}
Results: Image width = 6024, Image height = 4024
I hope this answer will help other users and thanks for wonderful library!
I think its because of the exiftool. The original IIQ image metadata seems different. Do you know an easy way to tell if its in the exif or xmp ? I will ask my coworker to see if we can create a IIQ with gps and no sensitive info but it may take several days.
Alex,
This API call appears to only impact the output width/height. Do we treat this to be the visible dimensions (height/width) to just extract the visible portion of the RAW data?
Does this mean the COLOR(r, c) does not work for these formats?
To reiterate, what I am trying to do is extract the Visible Portion of the RAW Image and implement the pipeline myself? Will calling raw2image() on this image only give me the visible portion of the CFA? If so, what dimensions should I assume the resulting buffer has
So, is there a way to identify if the file is from a Super-CCD sensor such that I can branch my code to handle it separately.
Dinesh
https://www.libraw.org/docs/API-CXX.html#adjust_sizes_info_only
Alex,
Thanks for that. I will read up on Fuji Super CCD images and go over the dcraw code.
Does that mean that some of the properties in the sizes field such as width, height are incorrect/invalid for these files? I was just trying to just read out the visible part of the raw image for me to apply my own camera pipeline.
Also, how do I identify if a file has Super-CCD sensor?
This is the way how Fuji Super-CCD files are processed (this method borrowed from dcraw.c):
- raw data is not 2:3 but stretched in one dimension (different for different cameras)
- color order is not rg/gb, but green columns and r/b columns
On processing:
- entire image is rotated 45 deg to get normal bayer pattern with diagonal greens (it is also unstretched to get 2:3 aspect ratio)
- standard debayering is used
- output rotated back and cropped
Matrix conversion is not gamut limited (unless you cut negative values in some intermediate steps)
ccm is 'camera matrix parsed from metadata. period', it is preserved as is (w/ possible value normalization). Usually it 'just some color data with not known camera/vendor specific meaning'.
That makes perfect sense. So, the matrix to convert from camera space to XYZ becomes xyz_rgb*rgb_cam. Does that impact the gamut of colors that can be represented as Camera Space -> sRGB is a narrowing conversion?
But, what exactly is ccm? I know in your earlier comment you mentioned
"ccm is also 'camera color matrix' retireved from RAW in 'as is' (excl. normalizing) form."
but could you provide more details?
Thanks,
Dinesh
ccm is not similar to cmatrix.
To convert to XYZ use cmatrix or rgb_cam, multiplied by srgb2xyz conversion matrix, see convert_to_rgb() source for details.
Alex,
A quick follow up. So based on your descriptions, cmatrix is the transformation from Camera Space to sRGB.
Is ccm similar to cam_xyz i.e. transformation between Camera Space and XYZ?
I have a DNG file shot from a Google Pixel 3 that has all-zeros for cam_xyz and ccm. The rgb_cam and cmatrix have the same values. The profile is also not available.
For such files, how do I convert from input space/camera space to XYZ?
I'm not sure, that margins are also multiple of 6 in 0.19. Extra effort is needed to analyze (source inspection, may be debugger session), so I won’t do it,
If not, xtrans[][] is for visible area, xtrans_abs[][] is for entire sensor (make sure you use LibRaw-provided margins).
0 is 'channel #0', 1 is 'channel #1', etc. Index to name mapping is in imgdata.idata.cdesc[] string.
Alex,
Thanks for the clarification. I am currently on 0.19.5 and so wanted to know if the information about margins still holds.
Also, is my understanding of what xtrans represents i.e. 0 -> R, 1 -> G, 2->B correct?
LibRaw provided margins (left_margin, top_margin) are multiple of 6 (at least in 0.20 beta and in latest snapshots), so xtrans and xtrans_abs are the same.
I have had trouble with this for years
Not there
Not where if is suppose to be
Permission problems
Different versions
In the end it is so much easier to use a different compile
Like mingw
I think that matching pixel by exact values will not work well due to value differences (because of noise, for example).
Thanks for the quick reply. Then I think I will need to do heavy processing for useful data.
Can I ask your opinion on this matter:
-I am currently working on "image matching with stereo camera". I am looking for away to match the same pixel between left image and right image.
-With the 8 bit data in jpg, sometimes the matching will not be so correct, for example: (pixel of 112.02 will become 112) and (pixel of 111.8 will also become 112). Therefore, they might be considered as a match but it is not true.
Do you think by taking the raw data for processing I can get better matching result? or Raw data are just too noisy for the matching task?
Thanks
Ok. Now we are sure. Thanks for looking into it.
Thank you for the sample.
In this sample:
- there is no EXIF/GPS records
- all location information is contained in XMP block
So, LibRaw does not read it
I just sent you a link to the above address. The image was taken directly from the camera this time so it was not modified by exiftool.
LibRaw postprocessing is very similar to dcraw.c's one, so excellent 'dcraw annotated and outlined' site (https://ninedegreesbelow.com/files/dcraw-c-code-annotated-code.html ) may be useful.
Short answer: No
RAW values unpacked from RAW file are:
- in linear gamma
- white balance not applied
- black level not subtracted (for most cases; some cameras do black subtraction).
Hi Alex,
Now I am looking for a way to get the process data where you have subtracted the black level, w/ white balance and demosaic, can you please help to explain the procedure? Thanks!
So, to my knowledge, bayer image would be greyscale (but with 10/12/or 14 bit depending on your camera raw image). Is it correct?
If yes, them if I map those Bayer values into (int)(0 -255), would it be similar to the greyscale.jpg (8 bit) file?
Thanks
Hi Alex,
I use the prebuilt library for win 64 and successfully embedded into visual studio. I would like to share my method as following:
1. Extract the binaries for x64.
2. Go into visual project. Open Project Properties, In Configuration Properties:
a. /Debugging/Enviornment: add the path to LibRaw-xxx\bin
b. /C/C++/General/Additional Include Directories: add the path to LibRaw-xxx\
c. /Linker/General/Additional Library Directories: add the path to LibRaw-xxx\lib
/Linker/Input/Additional Dependencies: add libraw.lib and libraw_static.lib
My testing code is following:
#include "libraw/libraw.h"
#include "opencv2/highgui/highgui.hpp"
#include "iostream"
#include "stdio.h"
using namespace std;
using namespace cv;
int main() {
// Let us create an image processor
LibRaw iProcessor;
// Open the file and read the metadata
iProcessor.open_file("D:/[01]Luan_van_thac_si/PROJECT/Non_Cuda/SLIC/SLICSuperPixel/DSC01042.ARW");
// The metadata are accessible through data fields of the class
cout << "Image width = " << static_cast(iProcessor.imgdata.sizes.width)
<< ", Image height = " << static_cast(iProcessor.imgdata.sizes.height) << endl;
waitKey();
return 0;
}
Results: Image width = 6024, Image height = 4024
I hope this answer will help other users and thanks for wonderful library!
You may send link (to dropbox/mediafire/wetransfer) to info@libraw.org to avoid public file exposure.
I think its because of the exiftool. The original IIQ image metadata seems different. Do you know an easy way to tell if its in the exif or xmp ? I will ask my coworker to see if we can create a IIQ with gps and no sensitive info but it may take several days.
Thank you for the file. In this file
- GPS coordinates are recorded in XMP block, not in GPSDirectory EXIF block
- GPSDirectory does not contains coordinates, only references:
| + [GPS directory with 3 entries]
| | 0) GPSVersionID = 2 3 0 0
| | - Tag 0x0000 (4 bytes, int8u[4]):
| | 6218624: 02 03 00 00 [....]
| | 1) GPSLatitudeRef = S
| | - Tag 0x0001 (2 bytes, string[2]):
| | 6218630: 53 00 [S.]
| | 2) GPSLongitudeRef = E
| | - Tag 0x0003 (2 bytes, string[2]):
| | 621863c: 45 00 [E.]
LibRaw does not parse XMP blocks (and no plans for that), so it is unable to extract GPS data from such file.
Pages