×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Ekos extracts the wrong RAW area (Shift of 10 and 5 pixels.)

  • Posts: 333
  • Thank you received: 92
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"):
 
 
Last edit: 2 years 4 months ago by han.
2 years 4 months ago #77882
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 333
  • Thank you received: 92
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
2 years 4 months ago #77885

Please Log in or Create an account to join the conversation.

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
2 years 4 months ago #77889

Please Log in or Create an account to join the conversation.

  • Posts: 333
  • Thank you received: 92
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?
Last edit: 2 years 4 months ago by han.
2 years 4 months ago #77891

Please Log in or Create an account to join the conversation.

Can you debug the driver around that line and see which offsets need to be applied?
2 years 4 months ago #77896

Please Log in or Create an account to join the conversation.

  • Posts: 333
  • Thank you received: 92
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





 
2 years 4 months ago #77899

Please Log in or Create an account to join the conversation.

Time to create page: 5.502 seconds