To be clear, I think we agree that there are no literal 80 character records to preserve, but there is metadata that you want to 'preserve' (viz. include in a TIFF file). The metadata found in FITS headers consists of keywords, values and comments. Keywords are limited to 8 ASCII characters, values must fall into one of the value categories and comments are ASCII. The 80 character record is a FITS file restriction, and not necessary for storing the metadata information in a TIFF file. In short, my...
There is no need for 80 characters. The lines are separated by #10 character and can be shorter. The design is practical solution making a hybride between FITS and TIFF standard resulting in a simple specification very easy to implement. It is more focused on the FITS standard then to follow suggestion from the TIFF standard. Simplicity allows easy implementation using established TIFF libraries rather then modifying existing libraries. There are always a better ways but the same is true for the...
We want a visible header Yeah, there's a tradeoff between human (visible) and machine (invisible?) readability. I guess we differ on where that line should be drawn.
Where else is a description for? Descriptions are intended as a field for narrative comment. While equating narrative comment with ASCII metadata is possible, as you've done, I don't think that's the best design, and I'd have gone with what the standard I noted above suggests. Perhaps I have some confusion either over astro-tiff's purpose or how it's being used. When camera control software such as SharpCap is writing a TIFF file there are no FITS 80 byte records "to preserve", nor do I see a compelling...
I'm not a TIFF expert but it seems to me that a baseline tag != private tag, i.e. you're not >>following the standard's suggestion. No we don't. We want a visible header :)
Hi Jesse, I'm somewhat more familiar with FITS and it seemed to me what astro-tiff was doing was essentially throwing meta-data into a COMMENT when a "data structure" is called for. The metadata is stored in the TIFF baseline tag "Image Description". Code 270, Hex 010E. Where else is a description for? To preserve the FITS 80 bytes records with comments from position 32, storing them in a string of variable length is a flexible solution. You also have to cope with added textual comments and logged...
From your DSS Group post: Astro-Tiff is just following the TIFF 6.0 standard. As I stated earlier it's not the way I would implement it. Your specification has it: The FITS header is written to the TIFF baseline tag "Image Description". Code 270, Hex 010E. The TIFF standard has it: we suggest that you reserve a single private tag, define it as a LONG TIFF data type, and use its value as a pointer (offset) to a private IFD [image file directory] or other data structure of your choosing. Within that...
An issue was raised recently on the DeepSkyStacker (DSS) forum regarding DSS being unable to read TIFF files saved by SharpCap as RAW (aka single plane mosaic). In short, DSS asked SharpCap to use standard TIFF tags rather than rely on SharpCap's astro-tiff keyword, ah, redundancy. Hence this post. I don't think throwing everything but kitchen sink into a 'description' is/was a particularly good idea for image metadata. But if you're going to go that route I suggest a more thorough scouring of TIFF...
Hi Mary, There is no source code. Only the specification and sample files are available. It is a rather simple specification. Implementing it in an existing application would take only a few lines extra code assuming TIFF and FITS files reading and writing is already implemented. The only difference is adding the FITS header to the TIFF description. Sample code will be available in the following programs, ASTAP, CCDCIEL, SIRIL, Nina. They all share the code. Han
Hey Han! I was wondering where I can find the code for this project. I an relatively new to source forge so I am unfamiliar with downloading code from here.
This forum is created for discussion about the Astro-TIFF specification.