The images produced by Ekos are shifted 10 pixels in width en 5 pixel in height compared with Adobe Digital Photo Professional and ASTAP.  This is not a major problem but doesn't allow the make darks outside Ekos.

For ASTAP (stacking) user,  I have compared the hotpixels from FITS images taken with Ekos/Astroberry with CR2 darks and analysed them with Adobe Digital Photo Professional and ASTAP 1.0.0RC2. All images are in 5184 x3456 pixel format 

These are the positions of two hotpixels:

• CR2 dark using DPP (Adobe), positions 18, 314 and 152, 2802 (counting starts at zero)
• CR2 dark using ASTAP, positions: 19, 3142 and 153, 2803
• FITS light by INDI, positions: 29, 2147 and 163, 2808

So there is a shift of 10 in width and 5 in height between the INDI FITS and the CR2 dark. The fault lies in Ekos/INDI. For ASTAP the position of the .CR2 hot pixels are exactly the same as with Canon "Digital Photo Professional". For INDI FITS file the extracted 5184 x3456  cropped-active-area  lies not in the middle of the full-active-area of 5202x3464 pixels but at the side. In Libraw the left and right margin of the cropped active area (thumb) are defined  S.raw_inset_crops[0].cleft and  S.raw_inset_crops[0].ctop and have the for the tested image the values left=168, top=56 pixels. The margins for the active area are left 158, top=52. The difference is the same 10 and 5 pixels.

I have no idea where to place a bug report. Maybe somebody can do that.

Han

Raw size: 5360x3516
Active area size: 5202x3464
Default cropped active area: 5184x3456
Margins active area: left=158, top=52
Margins cropped active area: left=168, top=56

• A,   Active-area, which is the largest area from which a useful image can be formed.
• C,   Cropped-active-area, which is the subset of the A Area which many raw converters convert into a useful image. The main reason why C is smaller than A is to provide some extra pixels all around for a raw converter's demosaicing algorithm to use. In LibRaw this area is called Thumb area for some unknown reason.
• M,   Masked-area, used by some cameras, especially Canons and is used a dark reference.

 

The blue marked area is where Ekos is extracting the pixels from (cropped active area or in LibRaw terms "Thumb image"):
 

Easiest fix would be to extract always the full active sensor area. In this case 5202x3464 pixels. Extracting the default cropped active area, 5184x3456 pixels is just a waste. You have to crop the image later anyhow. That is also what other programs (MaximDl, SGP) are doing.

Some background info about the sensor areas can be found here:
www.barrypearson.co.uk/articles/dng/specification.htm#areas

Han

So it looks like X needs to be offset by some margin and also Y.

X + offset
Y - offset

would make INDI GPhoto driver match C? Are these offset reported libraw? You can check how the image is read Line #316 of gphoto_readimage.cpp

The offset for the cropped-active-sensor-area (Thumb) are reported in the LibRaw sample program raw_identfy.cpp as follows:

if (S.raw_inset_crops[0].cleft != 0xffff) fprintf(outfile, "left: %d ", S.raw_inset_crops[0].cleft);
if (S.raw_inset_crops[0].ctop != 0xffff) fprintf(outfile, "top: %d", S.raw_inset_crops[0].ctop);


Some formats like .PEF don't report these values. Same for "thumb size" dimensions  (Strange name only used in DCRAW and LibRaw.)

But is better to extract the whole-active-sensor-area.(Image size). Why throw away active pixels?

Can you debug the driver around that line and see which offsets need to be applied?

Hello Jasem,

The images came from an user. I haven't Ekos running here. The LibRaw program raw_identify gives this:

raw-identify -v  ./2.CR2
.....
Number of raw images: 1
Thumb size:  5184 x 3456
Full size:   5344 x 3516
Raw inset, width x height: 5184 x 3456 left: 152 top: 56
Aspect: 3:2
Image size:  5202 x 3464
Output size: 3464 x 5202
Image flip: 6
Canon record mode: 6, CR2
SensorWidth          = 5344
SensorHeight         = 3516
SensorLeftBorder     = 152
SensorTopBorder      = 56
SensorRightBorder    = 5335
SensorBottomBorder   = 3511
Margins cropped active area: left=168, top=56
.....

So you can identify:

Raw size: 5360x3516
Active area size: 5202x3464
Default cropped active area: 5184x3456
Margins active area: left=158, top=52
Margins cropped active area: left=168, top=56

So there are 5202 - 5184= 18 pixels spare in width
So there are 3464 - 3456= 8 pixels spare height.

The left-top coroner of the 5184x3456 frame is at position 168, 56.  The Ekos left-top corner of the 5184x3456 frame is at 158, 51?
The left-top coroner of the 5202x3464 frame is at position 158, 52

You have to read S.raw_inset_crops[0].cleft and S.raw_inset_crops[0].ctop  to be correct.

Han