Issue on some camera

Submitted by lock on

Hello everyone.
First thank you for your big work on this lib I used for my software.
Since the last version I have issues with some camera (especially canon). This is probably due to a big change you've done.

As stated in Changelog:
* Bayer images: ensure that even margins have the same COLOR() for both the active sensor area and the full sensor area.

However, I need some help to better understand.
- First. Images coming from Canon EOS 2000D are read as Canon EOS 1500D. Is it normal? Is this due to your Normalized make/model ?
- Second, Bayer pattern of some camera have changed. OK for me, it is your choice and I have to accept it. But I have now some problem. For example with the 2000D, if I open the image in pure RAW mode, then I save the (new) Bayer pattern in the header (FITS keyword). If I try to debayer the image with the GBRG pattern the color will be wrong. I need to do it with RGGB. And it is the same with all astro software I tried.
So, my question is: need I do some margin check before demosaicing? Is it a bug? Is my way to get the pattern is wrong?

This is my method:

		int j = 0;
		for (int i = 0; i < fhigh; i++) {
			for (int c = i && 0; c < fwide; c++) {
				pattern[j++] = raw->idata.cdesc[fcol(raw, i, c)];
			}
		}

Best regards,

Forums: 

1) Canon uses different

Submitted by lexa on

1) Canon uses different marketing names for the same model, for example:
1500D / 2000D / Rebel T7 / Kiss X90 or 450D / Digital Rebel XSi / Kiss X2

For Canons, both model and normalized_model are set based on camera ID, not string specified in EXIF

2) Yes, if pre-LibRaw 0.20 margins was not even, new code will adjust it to even value. In that case, bayer pattern will become the same for full sensor area and for visible area within margins.

I'm not familiar with FITS, so could not help here.

-- Alex Tutubalin @LibRaw LLC

Thank you :)

Submitted by lock on

1 - It is always complicated with Canon ;). Thank you, I did not know that 1500 = 2000.

2 - OK. I send you a small example of two images of 2000D and 1200D. These images are pure RAW, in TIFF.
I get it with this code: https://gitlab.com/free-astro/siril/-/blob/master/src/io/image_formats_l...

So before 0.20 everything was ok, but now my results are not consistent while I would expect it it. What I understand it is just a compatibility issue with 0.19 and 0.20.

In the image I send you, both of camera has same Bayer pattern as stated by LibRaw. But as you can see, one is well demosaiced in GBRG, the other one no. Like if the Bayer Pattern was wrong for one image, of like I had to apply an offset for debayer (If I do it works of course).

https://filesender.renater.fr/?s=download&token=3c99e777-040b-44e9-9ecf-...

The files you sent are

Submitted by lexa on

The files you sent are monochrome tiffs, I do not have any idea what I could see from these files.

With LibRaw 0.20: both for Canon 2000D/1500D and Canon 1200D files, imgdata.idata.filters is 0x4b4b4b4b

I do not see any problem with colors when demosaicing using LibRaw::dcraw_process().

BTW, in your code i see:
g_snprintf(fit->row_order, FLEN_VALUE, "%s", "BOTTOM-UP");

Is there any possibility that this results in bayer pattern use from the bottom row, not top?

-- Alex Tutubalin @LibRaw LLC

Followup: EOS 1500D/200D

Submitted by lexa on

Followup: EOS 1500D/200D reported visible height is odd (4015), while EOS 2000D is even (3464), If bayer pattern is calculated on top row (fcol(raw, i, c), where i,c are 0...) and applied from bottom row this will may into observed mess.

-- Alex Tutubalin @LibRaw LLC

Yes this is monochrome CFA

Submitted by lock on

Yes this is monochrome CFA data. So we need to apply the debayer algo on it.
If I do it, one file is well demosaiced, the other not. While as you said, Bayer Pattern is the same.

g_snprintf(fit->row_order, FLEN_VALUE, "%s", "BOTTOM-UP");

This code is for FITS image where data is read bottom up. BUT, that changes anything: one file will be ok (not the same) but the other one not.
The problem is this lack of consistency: this is not normal. Before 0.20 everything was ok.

Debayer ok: https://postimg.cc/0KMm0zVz
Debayer ko: https://postimg.cc/0bv2f6Wh

In LibRaw 0.19 output size

Submitted by lexa on

In LibRaw 0.19 output size height was odd for both cameras.

I do not know how BOTTOM-UP is interpreted by software you use to check. If rows are reordered, but bayer pattern is not, this will result in incorrect demosaic.

Try to output files with even row count. If my hypothesis is right, this will result into the same behaviour for both cameras.

-- Alex Tutubalin @LibRaw LLC

do not know how BOTTOM-UP is

Submitted by lock on


do not know how BOTTOM-UP is interpreted by software you use to check. If rows are reordered, but Bayer pattern is not, this will result in incorrect demosaic.

It is just a flag to switch Bayer Pattern to match the right one, as you said ;). And in the cae I save in TIFF it is not used.

Try to output files with even row count. If my hypothesis is right, this will result into the same behaviour for both cameras.
I thought it was something like that. BUT ....
I can notice inconsistent behavior between 1200D and 1300D where the (effective) image size is the same (5202x3464 pixels) and even.

Maybe I'm doing something wrong, but ... I don't see what and where as I apply the same process to each image.

LibRaw demosaic uses same

Submitted by lexa on

LibRaw demosaic uses same imgdata.idata.filters field to determine specific pixel color.
I do not see any problem with 2000D/1200D/1300D files and LibRaw 0.20.

Could you please reproduce the problem using LibRaw calls or samples (e.g. dcraw_emu) only?

-- Alex Tutubalin @LibRaw LLC

When I use the

Submitted by lock on

When I use the 

	ret = libraw_unpack(raw);
	...
	ret = libraw_dcraw_process(raw);
	...
	libraw_processed_image_t *image = libraw_dcraw_make_mem_image(raw, &ret);

it works.
Now my question is. Is this because the change of the margin I have this issue? To be sure I would need a flag to know if the margin was changed or not. Is there such a flag like that? If no would it be possible to put a flag? Or does it exist a way to know it by analyzing some data?

There something between 0.19 and 0.20 that makes my code not working anymore. It is likely there is something wrong in my code. Something I do not check enough to ensure the right pattern.

Row order reversing will work

Submitted by lexa on

Row order reversing will work differently for odd and even row count:
Imagine the pattern
RGRGRGR (row #0)
GBGBGBG (row #1)
RGRGRGR (row #2)

For even number of rows (say 2), reversed pattern will be
GBGB.. (former row #1)
RGRG... (former row #0)

For odd number, reversed pattern is the same as original one.

So, if BOTTOM-UP really changes bayer pattern you need to ensure that it works correct for both odd and even row count.

Alternatively, calculate your pattern for left-low corner, not for left-top:

for(row = height-1; row >= height-2; row--)
  for(col = 0; col < 2; col++)
     pattern[j++] = cdesc[COLOR(row,col)]

-- Alex Tutubalin @LibRaw LLC

Oh man....

Submitted by lock on

Row order reversing will work differently for odd and even row count:
Oh boy... I think I owe you a wine bottle.

Thanks a lot. Thanks for everything. That was a so stupid error.
With 0.19 I was flipping the image for real. This is why it was working.