BatchDebayer produces degraded image if image is flipped

[johnpane]

Summary: Canon CR2 file indicates image should be rotated 90 degrees. If DSLR_RAW preference "No image flip" is unchecked, resulting RGB image is blurred, resulting in lower noise profile (higher SNRWeight in SubframeSelector) and worse FWHM, among other differences in image quality metrics.

To isolate this error, I converted the same CR2 file four times:
    1. Uncheck "No image flip", open CR2 directly, write resulting image as 32-bit floating .xisf
    2. Check  "No image flip", open CR2 directly, write resulting image as 32-bit floating .xisf
    3. Uncheck "No image flip", convert CR2 using BatchDebayer
    4. Check  "No image flip", convert CR2 using BatchDebayer

Methods 1, 2, and 4 produce identical images (once rotated to a common orientation). Method 3 produces a different image. Although I think this image is inferior to the others, I must acknowledge the possibility that method 3 is producing the correct result.

According to console logs (attached), the calls to dcraw are identical except for the presence or absence of the "-t 0" option.

Logs 3 and 4 show the different results of Noise Evaluation by BatchDeBayer.

SubframeSelector_table_fourways.csv, which I will attach to a subsequent message, shows image 3 is a substantial outlier on many evaluation criteria.

I can supply the original CR2, or other images on request, if that will help to reproduce the problem.

To work around this problem, users can turn on the "No image flip" setting in DSLR_RAW preferences.

(Unfortunately, I fear that many of my prior processing sessions were adversely affected by this).

John

[johnpane]

Here I attach SubframeSelector_table_fourways.csv, referenced in my previous post. I had to change the extension ".txt" to upload it.

[johnpane]

I think I've figured out the problem here, by excerpting code from BatchDebayer into a test script copied below.

Hypothesis: BatchDeBayer opens the image in the script (first three lines of code below). At this point, the image is already rotated (if necessary) and debayered. But for some reason, BatchDeBayer creates a Debayer object and executes it on this already-debayered image (probably so that options different than the default can be used). If no rotation is involved, this works fine. But if the input image has already been rotated, then the call to Bayer.execute will use the wrong debayer pattern. The code below should be run with an image that specify's rotation 90 degrees clockwise, and with the DSLR_RAW  "No image flip" preference unset. The first image "test-result" is corrupted by debayering with the wrong pattern. The second image "test-result-fixed" corrects the problem by specifying the rotated debayer pattern. If the DSLR_RAW  "No image flip" preference set, the opposite occurs: test-result is the same as test-input and "test-result-fixed" is corrupted because it uses the wrong debayer pattern.

By the way, the dcraw call displayed in the console is the first one from the ImageWindow.open() call, not the later call to dcraw that generates the output image.

John





/// Demonstrate bug in BatchDeBayer


var inputImageWindow = ImageWindow.open("/Users/pane/Desktop/video tmp/BatchDeBayer bug investigation/JFP_4539.CR2")
var sourceView = inputImageWindow[0].mainView;
sourceView.window.saveAs("/Users/pane/Desktop/video tmp/BatchDeBayer bug investigation/test-input.xisf", false, false, false, false );


// if image should be rotated and the DSLR_RAW "No image flip" preference is unset, this demonstrates the issue
// the image loaded above is already rotated and debayered. the script runs debayer again on this image, but
// because it has rotated the bayer pattern is wrong.


var p = new Debayer;
p.bayerPattern = p.RGGB;
p.debayerMethod = p.VNG;
p.evaluateNoise = true;

p.executeOn( sourceView )

var resultView = View.viewById( p.outputImage );
resultView.window.saveAs("/Users/pane/Desktop/video tmp/BatchDeBayer bug investigation/test-result.xisf", false, false, false, false );
resultView.window.forceClose();



var p2 = new Debayer;
p2.bayerPattern = p2.GRBG;
p2.debayerMethod = p2.VNG;
p2.evaluateNoise = true;

p2.executeOn( sourceView )

var resultView2 = View.viewById( p2.outputImage );
resultView2.window.saveAs("/Users/pane/Desktop/video tmp/BatchDeBayer bug investigation/test-result_fixed.xisf", false, false, false, false );
resultView2.window.forceClose();

[johnpane]

One more comment. My camera was set to AutoRotate=Off (neither on camera nor on computer), yet PixInsight is detecting the camera orientation and doing the rotate. I am guessing the CR2 metadata includes both an indicator of the camera orientation and an second indicator whether the computer should use that indicator; and that PixInsight is only looking at the first indicator.

[Juan Conejero]

Hi John,

Bug confirmed, thank you for discovering it, and for the well presented and detailed bug description and analysis. The problem with this script is that it uses ImageWindow.open() to load input images. That method does not allow using format hints (this will change in the next version), so we have no way to force it to load pure raw data, as is required in this case. Hence, the script depends on the current DSLR_RAW preferences settings. This is obviously incorrect.

The solution to this problem is a rewrite of this old script using the FileFormat JavaScript object, which of course allows format hints and thus can be made independent on specific format settings. Two good examples of scripts using this technique are BatchFormatConversion and BatchPreprocessing. I'll try to get this work done as soon as possible. For now, the only workaround is selecting "pure raw" settings in RAW Format Preferences, or at least enabling the no image flip option.

One more comment. My camera was set to AutoRotate=Off (neither on camera nor on computer), yet PixInsight is detecting the camera orientation and doing the rotate. I am guessing the CR2 metadata includes both an indicator of the camera orientation and an second indicator whether the computer should use that indicator; and that PixInsight is only looking at the first indicator.

As you know, our DSLR_RAW format support module uses dcraw as its back end. I'll check if dcraw does not support the auto rotate flag. If it does support it, then we have a bug in our code. Otherwise it's a dcraw problem.

[johnpane]

Thank you Juan.