han shared a photo. 3 months ago

ASTAP crashed in these files when it tries to change a header keyword. But it is now avoided in ASTAP version 2022.09.16. But the Ekos/Indi files are still not conform the FITS standard.

I'm not familiar with Ekos/Indi bug/issue tracker but raised an issue here
github.com/indilib/indi/issues/1733

Han

Read More...

INDIGO has implemented Astro-TIFF is the code.

Read More...

Good. I looked it briefly up for somebody and could only find: Compression = 32946 PKZIP-style Deflate encoding (experimental)

which accordiing Wikpedia is different the compression type=8 Deflate. But the documentations for the coverage hasn't been updated since 2002. :)

Read More...

It is only the filling of a standard TIFF description tag in a structured way with date, gain, exposure time, sensor temperature, used filter.....

Standard libraries like www.libtiff.org support the tag Description. The Description is just a string you could fill with the FITS header except that each line is completed with a LF or CR+LF as you like. LibbTiff has only LZW compression which performs a little less then Deflate. (LZW is used in GIF, Deflate in PNG)Personally I'm use a Pascal library. Code for importing was simple since the FITS header is of simple structure. Filling the Description tag was only a few lines of code.For Ekos mainly writing Astro-TIFF is interesting. With the compression method Deflate (same like ZIP) achieves almost the standard FITS compression factor called RICE from the CFITSIO utilities FPACK  and FUNPACK leaving about 60% of the file size.
 TIFF is super flexible format. I don't think there are any compatibility problem since it is already a few decennia’s available. Except for FITS it is the only generic format which allows 32 and 64 bit in floating point images. But the intended purpose if for 16 bit lights, darks, flat and flat-darks. Astro imagers produce these files in the thousands. The files size reduces to about 60% and you can use standard image managers to organise and view your images. So the intention is just use the power of this existing established TIFF format.

Siril version 1.0 to be released soon will accept Astro-TIFF for stacking. CCDCiel has implemented Astro-TIFF reading and writing fully in the code. The next ASTAP to be released today or tomorrow will fully support it including batch conversion both ways.
 Han

Read More...

There is currently an initiative to make better use of the TIFF format for astronomy.

The idea is to save a FITS header in a standard way into a TIFF file. This makes conversion between TIFF and FITS possible without loosing header information.

The FITS header is stored in the description tag of the TIFF file.  The specification is here: www.hnsky.org/astro-tiff.htm  Benefits:

  • The TIFF compression algorithm makes the files smaller
  • The files are readable by almost any image viewer.
The standard way is intended to be used for light, dark, flat and flat-darks. These files are normally written in large quantities and compression and viewability makes sense. Already some application developers are working on support. See the list at end of the specification in above webpage. For APP the only requirement would be to read TIFF and decode the tag description containing the header information in a string and decode information like date, exposure, gain, sensor temperature.The specification is not set up as a replacement of FITS. It just propose better of use of the existing TIFF file format. 
Han

Read More...

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





 

Read More...

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 format 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?

Read More...

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

Read More...

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.

I have compared 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 hotpixelsCR2 dark using DPP (Adobe), positions 18, 3141 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, 2808So 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 values for the tested image 168, 56 pixels. The margins for the active area are left 158, top=52. The difference is the same 10 and 5 pixels.

I have 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 + C:   The Active Area, which is the largest area from which a useful image can be formed.
  • C:   The Crop Area, which is the subset of the Active 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.
  • :  Masked Area, used by some cameras, especially Canons used a dark.
 
 


Read More...