Author Topic: ImageIntegration module processes wrong Data region in certain circumstances  (Read 1260 times)

Offline bulrichl

  • PixInsight Guru
  • ****
  • Posts: 524
Dear development team,

I use a Canon EOS 600D for deep sky photography and recently wanted to get more knowledge about the data in the Overscan region of the raw files, which is located above and to the left of the normal image region. For that purpose, I adjusted to "Pure raw" and "No image crop" in the format explorer (DSLR_RAW), in order to get the raw data and NOT to clip the image. The effect of this is, that Pixinsight invokes dcraw with the following parameters:
   dcraw -4 -o 0 -r 1 1 1 1 -E -t 0 -k 0 -H 1
The -E parameter tells dcraw not to crop the image. In case of a raw file of the 600D, this means, that an image with a width of 5344 and a height of 3516 pixels is opened. When the "No image crop"  is not selected (dcraw-parameter -D instead of -E), the image has a width of 5202 and height of 3465 pixels. So far so good, but....

[1] When you try to integrate raw images directly (e.g. Biasframes or Darkframes) with that "No image crop" option active, you get a strange result: dcraw is invoked with the correct parameters (especially "-E"). However, the resulting integrated image has a width of only 5202 and a height of 3465 pixels. I used neither input hints nor ROI in the integration process.

Even more strange: if you inspect the resulting integrated image, you will see that this new image contains part of the overscan region. Pixinsight seems to have cropped the 5344 x 3516 image at the right and the bottom side instead of cropping at the upper and left side. So the data have been scrambled: the resulting integrated image contains the greater part of the Overscan region, but part of the normal image is missing.

I checked this also with the new version of the ImageIntegration module of today (03.11.2016), it behaved the same manner.

This does not happen, if you load the raw files, save them as *.XISF-files and then do the integration. But this procedure is rather cumbersome.


[2] In order to simplify the procedure, I used the script "BatchFormatConversion" prior to the integration step. But to my surprise: when I let the default input hint "raw cfa", BatchFormatConversion yielded 5202 x 3465 images (at least no scrambling with the Overscan region occurred). Only upon deleting the input hint "raw cfa", I got the whole image, 5344 x 3516. However, I don't understand why this altered the result.


I consider [1] as a bug and am not sure of [2] being that what you should expect.

Please have a look at it, perhaps this can be corrected in a future version of the ImageIntegration module.

Bernd

------------------------------------------------
Pixinsight Standard Edition
Version 01.08.04.1195 Ripley (x64)
Microsoft Windows 7 Professional, Service Pack 1
------------------------------------------------

Offline bulrichl

  • PixInsight Guru
  • ****
  • Posts: 524
Hi,

there was no reply to my report. Despite of (I guess) 2 new versions of the "ImageIntegration" process in the meantime, no change in this respect.

I tried also the input hints "raw cfa no-auto-crop" according to: http://pixinsight.com/forum/index.php?topic=9559.0, but no success.

Bernd

Offline bulrichl

  • PixInsight Guru
  • ****
  • Posts: 524
Hi,

after installing the new RAW module that is based on LibRaw (instead of dcraw), I again tried to integrate images of my Canon EOS 600D with 'No image crop' enabled in Format Explorer|RAW. (This camera has a region of optical black pixels: 51 pixel above and 142 pixel left of the actual image. So the uncropped image (including optical black pixels) has dimensions 5344 x 3516 and the cropped image (excluding optical black pixels) has 5202 x 3465)

With the new RAW module, the integration result is correct with 'No image crop' enabled as well. I guess this means that the former erroneous integration result was caused by the old dcraw-based DSLR_RAW module and NOT by the ImageIntegration module of PixInsight.

Bernd