Astro-TIFF, bessere Nutzung von TIFF

[Han59]

Gegenwärtig ist es mit einer Reihe von Programmen möglich, Lights, Darks, Flats und Flat-Darks im TIFF-Format zu speichern. Die Informationen wie Belichtungszeit, Verstärkung und Datum gehen nicht verloren. Der Vorteil ist, dass die Dateien komprimiert sind und weniger Speicherplatz benötigen als FITS-Dateien. Das Format heißt Astro-TIFF. Hier die englische Beschreibung:
----------------------------------------------------------------------------------
There is currently an initiative to make better use of the TIFF format for astronomy.

The idea is to use TIFF not only for saving an image but also to store the FITS header in a standard way into the TIFF file. So the exposure time, celestial position, date, gain, astronomical solution , sensor temperature can be stored and read similar as for a FITS file.

Benefits:

• The TIFF compression algorithm makes the files smaller
• The files are readable by almost any image viewer.

Astro-TIFF as is called is already available in several programs and more are coming:

Image acquisition programs Astro-Tiff compatible:

• CCDCiel. version 0.9.78 read/write
• Nina 2.0 beta version
• SharpCap (beta)
• Indigo (code)

Image processing programs:

• Siril version 1.0 just released
• ASTAP latest versions, read/write, conversion

In planning:

• APT
• AstroImageJ

Other program can read TIFF but not the header currently.

The idea is to use this format for 16 bit raw images, so lights, darks, flats and flat-darks/bias files. These images are produced in the thousands. For these files compression is beneficial. The TIFF deflate compression is almost as good as the Rice compression as specified in the FITS standard 4.0. Any further processing results can be stored in FITS.

It is possible to convert batch wise between TIFF and FITS possible without loosing header information.

The Astro-TIFF specification is here:

https://astro-tiff.sourceforge.io/

Note this specification is not set up as a replacement of FITS or other formats. It just proposes a better of use of the existing TIFF file format.

Some configuration settings:
CCDCiel:


Nina:

 

[Caprica]

Was soll dieser Post? Hat jemand danach gefragt? Muss man das Forum unnötig zumüllen?

Und ich werde NINA nicht in TIFF speichern lassen, da APP beim Stacken nur FITS verarbeiten möchte.
Also ehrlich..

 

[elythomaslumber]

Hallo Han,
ist auch eine Implementierung unter LINUX (Astroberry...) geplant?

Grüße
Hartmut

 

[maximilian]

Hallo!

Was soll dieser Post?

Was soll bitte so eine Antwort? Es ist doch normal, dass in einem Forum für elektronische Bildverarbeitung über Neuigkeiten auf diesem Gebiet geschrieben wird. Wo denn sonst?

Muss man das Forum unnötig zumüllen?

Zumüllen? Meine Festplatten sind zugemüllt mit unkomprimierten Bilddateien. Vielen Gigabytes davon. Wenn jetzt endlich ein verlustlos komprimiertes Format für solche Daten kommt nehme ich das gerne an. Und ich wenn als Preis für 1 TByte Festplattenplatz 1kByte Forenspeicher bezahlen muss, dann bezahle ich diesen Preis ausgesprochen gerne

Und ich werde NINA nicht in TIFF speichern lassen, da APP beim Stacken nur FITS verarbeiten möchte.

Es soll auch Menschen geben, die andere Software als „NINA“ und „APP“ verwenden, die mit solchen Dateien umgehen können. Die Liste der derzeit kompatiblen Software steht oben. Warum willst Du diesen Menschen den Fortschritt vorenthalten?

Grüße
Maximilian

 

[Han59]

Linux: Es wurde ein Vorschlag gemacht. Jasem (Ekos) weiß Bescheid:

Astro-TIFF support, better use of the TIFF format.

Astro-TIFF support, better use of the TIFF format.

indilib.org

Dies wurde auch für APP und DSS vorgeschlagen. Diese Dinge brauchen einfach Zeit.

Gruss,
Han

 

[astro_alex80]

Was soll dieser Post? Hat jemand danach gefragt? Muss man das Forum unnötig zumüllen?

Was ist dir denn über die Leber gelaufen? Findest du das nicht auch ein bisschen unangemessen?
Interessante Info, ob man es nutzt oder nicht, bleibt doch jedem selbst überlassen. Ich lasse Nina direkt XISF speichern.

 

[JürgenN]

ist auch eine Implementierung unter LINUX (Astroberry...) geplant?

Hallo Hartmut,
zumindest wars schon mal im Forum angesprochen worden. Jasem steht dem wohl erst mal positiv gegenüber..

Astro-TIFF support, better use of the TIFF format. - INDI Forum

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...

indilib.org

P.S.: der threat bei INDI war ja auch von Han ;-)

 

[elythomaslumber]

Danke Dir! Siril 1.0.0 soll es laut der Diskussion schon unterstützen.
Die Spec 1.0 ist aber noch "ofenheiß" (15.03.2022). Da wird sich wohl noch was an den Details tun.

Grüße
Hartmut

 

[Caprica]

Was ist dir denn über die Leber gelaufen? Findest du das nicht auch ein bisschen unangemessen?

Ja, naja.. Aber das sind nun wirklich Basics die man sowieso in der Bedienungsanleitung oder bei google findet..

Ich lasse Nina direkt XISF speichern.

warum?

Schönen Gruss, Daniel

 

[Han59]

Jasem (Linux, Ekos Programm) hat viele Themen und Prioritäten. Etwas dazu schreiben (INDI Forum), das hilft

Für meine Dateien erhalte ich bei Verwendung von TIFF die folgenden Ergebnisse:

Bei einer Monokamera etwa 50 % der ursprünglichen FITS-Dateigröße.
Bei RGB-Kameras etwa 60 % der ursprünglichen FITS-Dateigröße.

Han

 

[astro_alex80]

warum?

Ist das Datenformat von PixInsight https://pixinsight.com/xisf/
Finde es super, dass Nina das kann, beziehungsweise abspeichern in verschiedenen Formaten berücksichtigt wurde.

Viele Grüße,
Alex

p.s. dann ist diese Bedienungsanleitung wohl auch an mir vorbeigegangen
höre zum ersten Mal von Astro-TIFF

 

[Ehemaliges Mitglied]

Was soll dieser Post? Hat jemand danach gefragt? Muss man das Forum unnötig zumüllen?

Ich denke, hier darf jeder posten, was ihm wichtig oder interessant erscheint, da muss man niemanden vorher fragen, Dich oder mich auch nicht. Wenn du meinst, ein Post verstößt gegen die Nutzungsbedingungen melde es der Administration.

lg
Niki

 

[Han59]

Hallo Han,
ist auch eine Implementierung unter LINUX (Astroberry...) geplant?

Grüße
Hartmut

Harmut,
Im letzten Beitrag Jasem (Gestern) wurden bereits einige Vorbereitungen vorgestellt:

I finally managed to pave the way for this in INDI v1.9.5 by defining INDI_TRANSFER_FORMAT and INDI_CAPTURE_FORMAT. We should have support for this in the next release. Now if anyone willing to submit a PR for this, it would be awesome!

Grusse Han

 

[Stefan822]

Wieso das Rad neu erfinden? Zu archivierende Dateien komprimiere ich mit

xz --lzma2=preset=1,dict=4KiB

Das ist schnell (Multi-Threaded mit Parameter "-T"), verlustfrei, komprimiert gut und ich kann mir sicher sein, das auch noch in 20 Jahren lesen zu können. Das funktioniert aber nur bei quantisierten Daten (Rohbildern).

Bei verarbeiten Gleitkomma-Bildern hilft CFITSIO welches quantisiert und damit nur quasi-verlustfreie ist. (Bei Rohbildern kann man mit CFITSIO selten mehr als 1-2 Bit zusätzlich einsparen.)

 

[Han59]

Richtig. Rice-Komprimierung (von CFITSIO verwendet), wie im FITS-Standard 4.0 angegeben, führt zu einer um 1% vielleicht 2 % besseren Komprimierung. Aber die Implementierung ist selten. Die Deflate (zip)-Komprimierung, wie sie in TIFF standard angegeben ist, ist fast genauso gut in der Komprimierung. Das Schöne ist, dass für den Programmierer die Implementierung von Astro-TIFF mit vorhandenen TIFF-Bibliotheken super einfach ist. TIFF-Dateien werden auch in 20 Jahren noch lesbar sein. Rohbilder nehmen den Großteil des Speicherplatzes ein. Die Devise lautet daher „Better use of TIFF“. Es ist kein neues Format, sondern ein etabliertes Format, das wir nur besser nutzen wollen.

TIFF-Deflate ist besser wie TIFF-LZW kompression.

TIFF kann ähnlich wie FITS 32- oder 64-Bit-Gleitkommabilder speichern. Es gibt also keine Begrenzung. Die meisten Speicherplatzeinsparungen werden jedoch durch die Komprimierung von RAW-Bildern erreicht. weil RAW-Bilder in großen Mengen kommen.

 

[Caprica]

p.s. dann ist diese Bedienungsanleitung wohl auch an mir vorbeigegangen
höre zum ersten Mal von Astro-TIFF

Ok ja, von Astro-TIFF höre ich auch das erste mal. Was ist denn der Unterschied zu normal TIFF?

Im Eingangspost wurde der Unterschied zu FITS beschrieben, darum ist mir das "Astro" gar nicht aufgefallen.

Dann entschuldige ich mich gerne. Dieser Threat ist sehr wilkommen

Trotz dem verstehe ich nicht den Vorteil, da ich zunächst einmal FITS brauche um Stacken zu können. TIFF erst später in der PhotoShop Bearbeitung..

LG, Daniel

 

[Stefan822]

Die Deflate (zip)-Komprimierung, wie sie in TIFF standard angegeben ist, ist fast genauso gut in der Komprimierung. Das Schöne ist, dass für den Programmierer die Implementierung von Astro-TIFF mit vorhandenen TIFF-Bibliotheken super einfach ist. TIFF-Dateien werden auch in 20 Jahren noch lesbar sein. Rohbilder nehmen den Großteil des Speicherplatzes ein. Die Devise lautet daher „Better use of TIFF“. Es ist kein neues Format, sondern ein etabliertes Format, das wir nur besser nutzen wollen.

Also wenn Astro-TIFF Deflate verwendet, dann behaupte ich ganz frech, xz komprimiert besser. Denn als ich mich vor einiger Zeit auf die Suche nach einem Kompressionsverfahren begab, habe ich vergleichen zwischen gzip (=Deflate), bz2 und xz. (Mit in Post #14 genannten Parametern kann man bei der Wörterbuch-Suche etwas abkürzen was bei Astro-Daten nur minimal Kompression kostet, aber die ganze Sache enorm beschleunigt.)

Implementierungsaufwand für den Programmierer: 0

Die Art und Weise, wie bei Astro-TIFF die FITS-Keys konvertiert werden, ist bestimmt nicht etabliert. Und die Verwendung von TIFF in Astro-Software ist auch nicht sonderlich weit verbreitet. Es würde mir in 20 Jahren wenig nutzen, wenn ich die Rohdaten ohne FITS-Keys nur mit einem Malprogramm einlesen kann.

 

[Han59]

Daniel,
Ziel ist ganz einfach die Komprimierung von Rohbildern.

Stefan,
Das Ziel ist on-the-fly Komprimierung Bilder. Nicht archivieren. Wie sollte das mit xz funktionieren? im Betriebssystem MacOS, Linux oder Windows?

 

[maximilian]

Hallo!

Das Ziel ist on-the-fly Komprimierung Bilder. Nicht archivieren. Wie sollte das mit xz funktionieren? im Betriebssystem MacOS, Linux oder Windows?

Das läuft als Kommandozeilenprogramm unter diversen Unix Varianten, darunter Linux und MacOS. Unter Windows soll es wohl in irgendwelche anderen Komprimierungsprogramme eingebaut sein.
Ich fange auch nichts damit an, das ist noch ein weiterer Bearbeitungsschritt und die Zukunftssicherheit ist nicht ganz unumstritten: Xz format inadequate for long-term archiving

Grüße
Maximilian

 

[astro_alex80]

Ok ja, von Astro-TIFF höre ich auch das erste mal. Was ist denn der Unterschied zu normal TIFF?

Im Eingangspost wurde der Unterschied zu FITS beschrieben, darum ist mir das "Astro" gar nicht aufgefallen.

Dann entschuldige ich mich gerne. Dieser Threat ist sehr wilkommen

Trotz dem verstehe ich nicht den Vorteil, da ich zunächst einmal FITS brauche um Stacken zu können. TIFF erst später in der PhotoShop Bearbeitung..

LG, Daniel

alles gut Daniel. Han hat es ja schon geschrieben, es geht in erster Linie um Komprimierung von Rohbildern, von Programmen die Astro-TIFF speichern können. 50 MB als FITS, 30 MB als Astro-TIFF (ohne jetzt die genauen Kompressionsverhältnisse zu kennen), das hat damit durchaus Relevanz. Und bei einem gestackten 6000x4000 32 Bit Bild, was ja mittlerweile normal ist, auch. Aber wie geschrieben, interessiert mich persönlich nicht ich lasse XISF speichern - unkomprimiert.

 

[Han59]

Die lzma2-Komprimierung wird von einigen Programmen für TIFF-Bilder verwendet. Wenn es also etablierter ist, könnte es für Astro-TIFF-Dateien verwendet werden.

 

[Stefan822]

Das Ziel ist on-the-fly Komprimierung Bilder. Nicht archivieren. Wie sollte das mit xz funktionieren? im Betriebssystem MacOS, Linux oder Windows?

xz ...fits.xz | simg zocorrect - ...

Wenn der Programmierer nicht ganz so faul ist wie ich, kann man auch die liblzma (oder etwas ähnliches einbinden: Es gibt zahlreiche Implementierungen und zahlreiche Bindings) um das Ganze on-the-fly zu lesen oder schreiben.

Das xz-Containerformat ist in der Unix-Welt Standard (und etabliert) und wird z.B. zur Komprimierung des Linux-Quellcodes verwendet.

Zukunftssicherheit ist nicht ganz unumstritten: Xz format inadequate for long-term archiving

Da geht es um Robustheit gegenüber Medien-Fehlern, also wie viel ist von der Datei noch zu gebrauchen falls die Daten korrumpiert wurden und bekommt man das überhaupt mit?

Gibt's eine vergleichbare Studie für Astro-TIFF ?

Der Vorteil, einer externen und unabhängigen Komprimierung ist, dass man nicht darauf angewiesen ist, das jemand das in die Bildverarbeitung implementiert. Das Tool zum dekomprimieren wird's auch in 20 Jahren noch geben (ist Quelloffen und braucht nur neu kompiliert werden).

Wem xz nicht passt, der kann auch gzip nehmen. (Deflate-Komprimierung wie bei Astro TIFF). Das komprimiert zwar schlechter als lzma2 ist aber noch weiter verbreitet und super einfach in Programme (on-the-fly) einzubinden: einfach fdopen/fdread/... durch gzopen/gzread/... ersetzen.

Und noch etwas (das hatte ich schon geschrieben): Verarbeite Bilder (Gleitkomma oder 32 Bit Integer) können nur halbwegs vernünftig komprimiert werden wenn diese vorher quantisiert werden, d.h. die Anzahl der möglichen Bildwerte eingeschränkt wurde. Bei fits hat sich hierfür hat sich CFITSIO etabliert. Wie macht man das bei Astro-TIFF?

 

[maximilian]

Hallo!

Das Tool zum dekomprimieren wird's auch in 20 Jahren noch geben (ist Quelloffen und braucht nur neu kompiliert werden).

Das TIFF Format ist 36 Jahre alt, ebenfalls quelloffen und seit über drei Jahrzehnten der etablierte Standard in Druck und Druckvorstufe. Auch das wird man in 20 Jahren noch dekomprimieren können. AstroTIFF ist auch nicht direkt vom Himmel gefallen, vergleichbares gibt es in anderen Bereichen schon lange, z.B. GeoTIFF für Geoinformationsdateien. Ich vermute, dass AstroTIFF davon abgeleitet wurde. Und im Gegensatz zu FITS und anderen speziellen Bildformaten kann man TIFFs auch mit „normalen“ Grafikprogrammen bearbeiten, unkonvertiert austauschen, im Fotogeschäft ausdrucken lassen, usw.
Ich sehe nichts was an AstroTIFF irgendwie nachteilig wäre. Wirklich gar nichts.

Grüße
Maximilian

 

[Stefan822]

Das TIFF Format ist 36 Jahre alt, ebenfalls quelloffen und seit über drei Jahrzehnten der etablierte Standard in Druck und Druckvorstufe. Auch das wird man in 20 Jahren noch dekomprimieren können. AstroTIFF ist auch nicht direkt vom Himmel gefallen, vergleichbares gibt es in anderen Bereichen schon lange, z.B. GeoTIFF für Geoinformationsdateien. Ich vermute, dass AstroTIFF davon abgeleitet wurde. Und im Gegensatz zu FITS und anderen speziellen Bildformaten kann man TIFFs auch mit „normalen“ Grafikprogrammen bearbeiten, unkonvertiert austauschen, im Fotogeschäft ausdrucken lassen, usw.
Ich sehe nichts was an AstroTIFF irgendwie nachteilig wäre. Wirklich gar nichts.

Welches Fotogeschäft druckt mir Gleitkomma-TIFF aus, welches ,,normale'' Grafikprogramm kann das bearbeiten, welches das ohne Datenverlust (in was auch immer) konvertieren?

Ich sehe nichts was an AstroTIFF irgendwie nachteilig wäre. Wirklich gar nichts.

Wenn komprimiertes Astro-TIFF gegenüber komprimierten FITS (siehe https://heasarc.gsfc.nasa.gov/docs/software/fitsio/c/c_user/node41.html) nicht im Nachteil ist, dann erklär mir doch bitte, wie mit Astro-TIFF Gleitkomma-Bilder oder 32-Bit integer Bilder komprimiert werden. Wie schon mehrfach geschrieben geht das nur mit Quantisierung, wovon in den Astro-TIFF Specs aber nichts zu finden ist.

Ich frage mal anders herum: Was kann Astro-TIFF besser als (komprimiertes) FITS?

Nachtrag:
Die Astro-TIFF-Specs empfehlen ein anderes Koordinatensystem als FITS (Ursprung, Orientierung). Die Meta-Infos werden aber in Form von FITS-Keys gespeichert. Welches Koordinatensystem gilt für diese, falls diese Pixel-Koordinaten enthalten (z.B. WCS-Infos)?

 

[Han59]

Ich frage mal anders herum: Was kann Astro-TIFF besser als (komprimiertes) FITS?

Gar nichts . Aber die Implementierung ist super einfach mit bestehenden TIFF-Bibliotheken. Es gibt nur an, wie das Tag "Bildbeschreibung" verwendet wird.

Die Astro-TIFF-Specs empfehlen ein anderes Koordinatensystem als FITS (Ursprung, Orientierung). Die Meta-Infos werden aber in Form von FITS-Keys gespeichert. Welches Koordinatensystem gilt für diese, falls diese Pixel-Koordinaten enthalten (z.B. WCS-Infos)?

gleichwertig. WCS ist voll funktionsfähig.

Welches Fotogeschäft druckt mir Gleitkomma-TIFF aus, welches ,,normale'' Grafikprogramm kann das bearbeiten, welches das ohne Datenverlust (in was auch immer) konvertieren?

Das Stapeln von Bildern führt zu Fließkommadateien. Die Bearbeitung kann in Photoshop oder Gimp erfolgen.

Und noch etwas (das hatte ich schon geschrieben): Verarbeite Bilder (Gleitkomma oder 32 Bit Integer) können nur halbwegs vernünftig komprimiert werden wenn diese vorher quantisiert werden, d.h. die Anzahl der möglichen Bildwerte eingeschränkt wurde. Bei fits hat sich hierfür hat sich CFITSIO etabliert. Wie macht man das bei Astro-TIFF?

Das Hauptziel ist die Komprimierung von 16 bit integer Raw-Dateien.


TIFF erlaubt viele Komprimierungsmethoden. Für die LZMA2-Komprimierung in TIFF wird Tag 34925 verwendet.

Han

 

[steffens]

Hallo,

Ganz ehrlich, ich verstehe das Genöle von einigen hier überhaupt nicht.
Hier geht es doch nur um eine zusätzliche Option, die niemand nutzen muss. Für einige mag es aber praktisch und nützlich sein.
Der Vorteil liegt doch klar auf der Hand: die Bilder sind ohne Informationsverlust kleiner als unkomprimierte FITS, lassen sich mit normalen Bildbetrachtern einfach durchblättern, behalten aber die Metadaten der Aufnahme.

Natürlich kann man auch FITS Compression benutzen. Das unterstützt aber auch nicht jede Software (Siril kann das). Und einfach mal Bilder durchblättern ist damit ohne Astro-Software nicht drin.
Natürlich kann man auch .fits.gz, .fits.bz oder .fits.xz benutzen. Aber welche Software lädt das denn bitte direkt?

Ich werde meine Aufnahmen auch erstmal weiterhin im FITS Format machen. Aber ich finde es gut, wenn in dem fertigen Stack, den ich dann als TIFF exportiere, noch der FITS Header enthalten ist. Das ist doch super, was ist daran verkehrt?

Die Frage nach dem Koordinatensystem finde ich valide.
Leider kenne ich mich mit den möglichen Metadaten in FITS nicht so gut aus, dass ich da eine fundierte Meinung dazu hätte. Aber werden die WCS-Informationen nicht immer relativ zur Bildmitte angegeben? Das wäre dann ja kein Problem.
Übrigens ist gerade die Frage des Koordinatensystems ein großer Schwachpunkt von FITS, da die Spezifikation da sehr schwammig ist, und leider verschiedene Programme unterschiedliche Implementierungen haben. Einige lesen von oben nach unten, andere von unten nach oben. Das führt bei Programmwechseln oft zu gespiegelten Bildern. Das wäre bei Astro-TIFF mit klar definiertem Koordinatensystem kein Problem mehr.

Grüße,
Steffen

 

[elythomaslumber]

Ich kann der tiefen technischen Diskussion hinsichtlich der Qualität und Effiezienz der Kompression mangels Fachkenntnissen nicht folgen.
Ist aber auch egal. Ich sehe das aus Sicht des Nutzers. Ein neuer Standard muß durchgehend in meinen Anwendungen implementiert sein, und zwar dort, wo ich ihn benötige und er muß mir einen Vorteil bringen.
Ich will auch keine Befehlszeilen aufrufen oder irgendwelche technischen Klimmzüge machen. Anklicken und freuen, dass es geht und besser ist, als mein bisheriger Weg.
Ich denke, die meisten Nutzer werden das auch so sehen. Wenn es dann paßt, ist es ok, wenn nicht, wird der Standard vermutlich irgendwo unter "Sonstiges" landen.
Grundsätzlich bin ich immer offen für Neuheiten und Innovationen.
Schaun wir mal...

Grüße
Hartmut

 

[Han59]

Komfort und vielleicht Geschwindigkeit sind wichtiger als maximale Komprimierung. Aber hier einige Testergebnisse für Kompression zwei 16 bit raw Monobilder m5 und m16.
Notes:
xz lzma2-Komprimierung ist die beste, aber ein Archivierer. Tiffcp lzma2 ist nicht so gut. Tiffcp ist ein Linux-Tool
Extension .fz ist fits RICE compression (cfitsio).

Grusse, Han

test Dateien:

Upload files for free - test.zip - ufile.io

Download test.zip for free from ufile.io instantly, no signup required and no popup ads

ufile.io

 

[Stefan822]

Ich frage mal anders herum: Was kann Astro-TIFF besser als (komprimiertes) FITS?

Gar nichts . Aber die Implementierung ist super einfach mit bestehenden TIFF-Bibliotheken. Es gibt nur an, wie das Tag "Bildbeschreibung" verwendet wird.

Wenn jeder das Rad neu erfindet und sich ein neues Bildformat ausdenkt, dann enden wir in einem Wildwuchs inkompatibler Formate. Das war und ist meine Hauptkritik.

Wenn Astro-TIFF nichts besser kann, stellt sich auch die Frage wie viele Programmierer das implementieren werden.

Einfacher als Astro-TIFF zu implementieren (gibt es Libraries?) Ist es zlib einzubinden und fdopen/fdread/.. durch gzopen/gzread/.. zu ersetzen. Zumindest viele Programme aus der Unix-Welt können das (weil es so simpel ist) und können deshalb von Haus aus gzip-komprimierte FITS Dateien lesen. (Was mir nichts nutzt da ich es wegen der schlechen Kompression -- genauso schlecht wie Astrto-TIFF mit Deflate-Kompression -- nicht verwende.)

Darüber hinaus haben die Astro-TIFFS Specs Schwächen, die ich gerne noch mal wiederhole:

• Die FITS-Keys werden im Description Tag gespeichert. Dazu steht in den Specs richtigerweise "Some image programs could crop the description when saved again." Es kann also passieren, dass bei einem Wechsel der Library / nach einem Software-Update die Meta-Infos nicht mehrt gelesen oder geschrieben werden. Es ist außerdem denkbar, via Description-Header Angriffe auf bestimmte Software durchzuführen, wogegen Sich die Software-Entwickler dann mit einer (Längen)Beschränkung oder einem Verbieten bestimmter Sequenzen (z.B. ASCII-Steuerzeichen) wehren würden. In der Unix-Welt, wo shared Libraries verwendet werden und der Entwickler der Bildverarbeitung somit keinen Einfluss auf so etwas hat, ist das sehr kritisch.
• Die Specs empfehlen "TIFFtag_orientation=1 (left-top) Orientation is following the conventions. Pixel FITS_image[1,1] is left-bottom. TIFF_image[0,0] is left-top. These pixels are first written or read from the file. So when writing a FITS image into TIFF preserving the orientation for the user, the first pixel to write is FITS_image[1,NAXIS2]." In den Amerkungen steht: "If an astrometrical (plate) solution is included it should match with the image orientation".
  Diese soll aber laut Empfehlungen geändert werden (aus der FITS-Koordinate (1,NAXIS2) wird die TIFF-Koordinate (0,0)), D.h. alle FITS-Keys, die sich auf Koordinaten-beziehen, müssen auf das neue das gänderte Koordinatensystem ungerechnet werden. Das betrifft u.A. die WCS-Daten (Referenzpixel (CRPIX1,CRPIX), Matrix und ggf. High-Order-Koeffizienten) und das Bayer-Muster
• Specs empfehlen ohne Einschränkung Kompression zu verwenden. Das ist kein Problem, es ist nur Unsinnig wenn sich die Dateien aus den bereits beschrieben Gründen nicht komprimieren lassen

Hand hoch: wer von denen, die mich für meine Kritik kritisieren, hat sich die Specs angeguckt ??

 

[Han59]

Einfacher als Astro-TIFF zu implementieren (gibt es Libraries?

Ja, jede TIFF Library reicht aus, da die Dateien vollständig dem TIFF-Standard entsprechen.

lle FITS-Keys, die sich auf Koordinaten-beziehen, müssen auf das neue das gänderte Koordinatensystem ungerechnet werden.

Es gibt kein Problem. TIFF Koordinaten [0,0] sind in FITS nicht vorhanden. FITS-Koordinatensystem beginnen mit [1,1]. Die Spezifikation folgt nur den Konventionen.

Wenn jeder das Rad neu erfindet und sich ein neues Bildformat ausdenkt, dann enden wir in einem Wildwuchs inkompatibler Formate. Das war und ist meine Hauptkritik.

Entschuldigung, aber das ist purer Unsinn! Es ist und bleibt TIFF. Lediglich das TIFF-Tag „Bildbeschreibung“ wird strukturiert verwendet. Sollte das Bildbeschreibungs-Tag leer bleiben?

Specs empfehlen ohne Einschränkung Kompression zu verwenden. Das ist kein Problem, es ist nur Unsinnig wenn sich die Dateien aus den bereits beschrieben Gründen nicht komprimieren lassen

Welche Dateien und Gründen? Beispiel bitte. Die Diskussion dreht sich nicht um TIFF (nach 30 Jahren Nutzung), sondern darum, wie man es besser nutzen kann.