Hi,
I am observing some strange behaviour with some Fuji RAF files. My workflow is:
Libraw r;
r.open_file(fileName);
r.unpack()
When I inspect r.imgdata.sizes, I notice the visible image size is reported larger than RAW size. In my specific file, the values are:
3688 2512 for RAW height and Raw width
4291 4292 for Visible height and width
The Aspect Ratio is reported as 1.
I am trying to copy the visible portion of the RAW data into my buffer, but these sizes result in a crash. Reading the entire RAW data works fine.
When I do dcraw_process and dcraw_make_mem_image, I get an RGB image with dimensions 2607x3460x3.
I have observed this only with some RAF files.
Am I missing something trivial?
This is the way how Fuji
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
-- Alex Tutubalin @LibRaw LLC
Thanks!
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?
https://www.libraw.org/docs
https://www.libraw.org/docs/API-CXX.html#adjust_sizes_info_only
-- Alex Tutubalin @LibRaw LLC
Seems to impact only output height/width
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
I think it will be faster to
I think it will be faster and more productive to try raw2image() than discuss this here.
-- Alex Tutubalin @LibRaw LLC
Sure thing!
So raw2image() works the same way for these files i.e. only one of the 4 channels will have a valid value and this will correspond to COLOR(r, c).
Is the size of the buffer (n bytes) allocated after raw2image() equal iheight*iwidth*2? This info is necessary for me to allocate the suitable output buffer in my code.
imgdata.image buffer is NOT
imgdata.image buffer is NOT equal to iheight*iwidth*2
-- Alex Tutubalin @LibRaw LLC
Think I figured it out
Alex,
I think I figured it out.
For Super-CCD sensors, there is a 45 degree rotation applied to the image. So the height/width fields in sizes report the bounding box that is needed to store this rotated image i.e. if you apply a 45 degree rotation on an image with dimensions 2177 rows and 2894 cols, u will need a buffer of size 3587 x 3588 pixels to store it. It will have a bunch of black pixels around the image. So, image contains height*width*4*2 bytes.
A few follow up questions I have are:
1. Does COLOR() function work for these types of images? Because for this specific image, cdesc is "RGBG" and COLOR(0, 0), COLOR(0, 1), COLOR(1, 0) and COLOR(1, 1) are 0, 2, 1, 3 respectively which results in a "RBGG" Bayer Pattern but I don't think that is correct because these are not really Bayer images?
2. Which fields/props in imgdata do I use to detect these kinds of files such that i can update my copying code suitably? The call to raw2image is not needed for typical Bayer or X-Trans sensors. You can copy from raw_image or color3_image etc.
Appreciate your help.
is_fuji_rotated?
Hi Alex,
Is the API call is_fuji_rotated() the one to use to identify Super CCD sensors?
Also it looks like number of pixels in imgdata.rawdata.raw_image and number of pixels in imgdata.image seem to be consistent with raw_height/raw_width and height/width.
Dinesh
yes, is_fuji_rotated() could
yes, is_fuji_rotated() could be used to identify 'rotated processing' used in LibRaw/dcraw.c
COLOR(r,c) is correct in raw-coordinates (and FC(r,c) is correct in imgdata.image[] coordinates)
-- Alex Tutubalin @LibRaw LLC
Thanks!
Alex,
Thanks for your help. FC(r, c) worked as expected. I believe I am all set.
Dinesh