StarTools

I just tried to open a TIFF file that was saved in strips and ST refuses to open it

I've put the file in my DropBox folder "General" and shared it to startoolsastro@gmail.com

ImageWidth (1 Short): 4136
ImageLength (1 Short): 2816
BitsPerSample (3 Short): 32, 32, 32
Compression (1 Short): Deflate
Photometric (1 Short): RGB
StripOffsets (564 Long): 8, 77166, 156931, 237036, 317284, 397887,...
Orientation (1 Short): TopLeft
SamplesPerPixel (1 Short): 3
RowsPerStrip (1 Short): 5
StripByteCounts (564 Long): 77158, 79765, 80105, 80248, 80603, 80950,...
XResolution (1 Rational): 100
YResolution (1 Rational): 100
PlanarConfig (1 Short): Contig
ResolutionUnit (1 Short): Inch
Software (28 ASCII): DeepSkyStacker 4.2.4 Beta 2
DateTime (20 ASCII): 2020:02:11 21:31:16
Predictor (1 Short): 3
SampleFormat (3 Short): 3, 3, 3
SMinSampleValue (3 Float):
SMaxSampleValue (3 Float):
50000 (1 Long): 3
50008 (1 Float):
50011 (1 Long): 125

perdrix wrote: Compression (1 Short): Deflate

Hi,

Thank you for sharing and uploading that dataset!
Strips are definitely supported, however compression is not.
(see also our earlier correspondence here)

To recap; TIFF import in StarTools is more of a courtesy function, as it is an image format not a data format (for the same reason, StarTools only saves as TIFF and not as FITS - StarTools design purpose is to output images and not data). Users are encouraged to use FITS (32-bit integer preferably) for import, guaranteeing data that is much closer to the ideal of 2D arrays of photon counts, rather than leaving room for all manner of detrimental processing.

Does that make sense?

Err well no it doesn't make sense to me at all - it's not as if lossy compression is being used here. Why the prejudice against TIFF? You load images from FITS even though FITS is NOT an image format (though it's often used as such) - the content could equally be anything such as solar seismic data ...

I accept that Startools is yours to do with as you please, but would still be nice not to have to save images in HUGE uncompressed format just so they can be fed into Startools.

David

perdrix wrote:Err well no it doesn't make sense to me at all - it's not as if lossy compression is being used here.

That was really not the point I was trying to make.

Why the prejudice against TIFF?

Per our previous exchanges, the - indeed very real! - prejudice against TIFF stems from the fact that it is an easily manipulated image format, whose use in that manner has been the cause of many hours of frustration of newbies.
Anything from well intentioned (but highly destructive) use of RAW converters (whether vendor supplied, Adobe Camera RAW or open source equivalents) to, indeed, the default destructive behaviour of a handful of stackers like DSS (applying stretches, white balancing, normalisation); at best they yield sub-optimal results and make certain operations impossible, at worst they yield unusable results that discourage people from pursuing the hobby. The quality you can get from even the most basic gear is incredible, if you only treat your data (there is that word again) as carefully as possible.

While I have you, this has been my main gripe with DSS (as well as a source of many words of support emails, documents and tutorials); its defaults and workflow invite (or singularly introduce!) deviation from modern best practices. By "modern" practices, I mean practices and signal processing as performed by other software such as PixInsight, Astropixel Processor and some other free stacking solutions. I'd be happy to elucidate if it is helpful for DSS development!

You load images from FITS even though FITS is NOT an image format

That is precisely the point. A FITS file is not a "photo" (as understood by newbies). FITS is not an image format. It is a data format. It guarantees the file contains data, and was produced some other software that also considered the data contained therein as precisely that; 'data' (and not pixels of an image).

I accept that Startools is yours to do with as you please, but would still be nice not to have to save images in HUGE uncompressed format just so they can be fed into Startools.

I believe you are greatly over-estimating the efficacy of non-lossy compression. As dynamic range increases, so does entropy; the Poisson noise introduced, averaged over multiple sub frames will make repeating patterns rarer and rarer (besides maybe some stacking artifacts). As a result you will find many compression algorithms struggle to achieve meaningful space savings with 16-bit (or above) images that have saturated dynamic ranges.

I hope this helps, or at very least, lends a useful perspective.