STEVEG@MAINE.Bitnet.UUCP (04/28/87)
HI THERE!
SPANISH ASTRONOMERS ARE LOOKING FOR A IFF "FORM" TYPE (SIMILAR OR NOT TO FORM
8SVX) TO STORE 16 OR 32 BITS IMAGE DATA IN THE AMIGA. IS THERE A STANDAR AL-
READY?.
WE ARE DEVELOPPING AN AMIGA-BASED IMAGE PROCESSING SYSTEM FOR ASTROPHYSICAL
IMAGES (CCD'S IPCS'S ...), SO WE WOULD BE VERY PLEASED IF ANYONE COULD HELP
US. (THE INFORMATION ON AMIGA IS HARD TO GET IN SPAIN!).
THANX IN ADVANCE.
JAIME ZAMORANO (ASTROPHYSICS DEPT. MADRID UNIVERSITY)
<W062@EMDUCM11>
carolyn@cbmvax.cbm.UUCP (Carolyn Scheppner CATS) (05/06/87)
In article <44CSNEWS@MAINE> CSNEWS@MAINE.BITNET (CSNEWS CSBB Processor) writes: >HI THERE! >SPANISH ASTRONOMERS ARE LOOKING FOR A IFF "FORM" TYPE (SIMILAR OR NOT TO FORM >8SVX) TO STORE 16 OR 32 BITS IMAGE DATA IN THE AMIGA. IS THERE A STANDAR AL- >READY?. It sounds like you want to keep the 16/32 bits for each pixel together or alternately store the info with some type of delta encoding scheme. There is no FORM currently to meet your needs. But others who do data-gathering have asked for something similar. If you design a form, send it to me and I will check it out (make sure it follows IFF rules and has a unique name) and I will make other developers aware of the new form. Minimally, it needs a FORM name, some type of header chunk and a body chunk containing the data. It will be most flexible and useful for others if you design a header chunk (for example DHDR) which contains information applicable to any type of stored data samples. In addition, you could have your own application-specific chunk(s) (example ASTR) which would contain other information you might wish to store with the samples. Pad your chunks with a few unused fields for possible future registered expansion of the chunk, and to make the chunks an even length in bytes. For example, something like: FORM (length) DATA DHDR (length) UWORD BitsPerSample UBYTE Compression (0=none,1=FibDelta,2=???) (If storage is rows, or columns, etc., each row/column/etc. should be compressed individually) UBYTE Flags (?) ULONG StorageOrder (?) (I'm thinking something like 0=linear, 1=rows, 2=columns, etc. for other orders) ULONG X (X dimension for row) ULONG Y (Y dimension for column) ULONG Z (possible 3rd dimension to data) ULONG T (possible timestamps, 4th dimension ?????) ULONG SamplingRate ULONG NumberOfSamples (Plus whatever else you feel would be needed to describe data samples IN GENERAL) (Plus UBYTE pad0 if needed to make chunk even length) ULONG padl0 (future expansion) ULONG padl1 (future expansion) ASTR (length) (NOTE: Just ideas - you store what YOU need here) char[8] Date (YYYYMMDD for ease in sorting) char[16] Time (24-hour time HHMMSSMMMMMMxxxx) ULONG Latitude ULONG Longtitude ULONG Magnification etc. (UBYTE pad0 if needed) ULONG padl0; (for future expansion) ULONG padl1; ULONG padl2; BODY (length) The data samples go here --------------------------------------------------------------------- So - please feel free to design a FORM and email it to me. I'll look at it / comment on it. If OK with you, I'll post it on usenet and in our iff topic on BIX to see if anyone else who needs a similar form has any requests for additions. Once it is stable, I'll make other developers aware of the form. If you have any questions, send me email. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carolyn Scheppner -- CBM >>Amiga Technical Support<< UUCP ...{allegra,caip,ihnp4,seismo}!cbmvax!carolyn PHONE 215-431-9180 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
hadeishi@husc7.UUCP (05/06/87)
Carolyn's recent posting regarding astronomical FORMs reminds me of a fact that not everyone is aware of: a correct IFF reader will ONLY read the amount of data specified in the Chunk header, even if that chunk is "supposed" to have more data in it. Thus, an IFF writer can write just the first few fields of a structure, and as long as the Chunk header is written with the right length, the reader should read the first few fields. For example, DPaint saves brushes without saving the entire BMHD chunk; just the fields relevant to a brush. Thus, if you are planning to use your FORM and the various data chunks defined in the FORM for various purposes of different levels of complexity, you should place the data in your FORM design that is to be used most generally and most often near the top of your structure, and the more esoteric and less-used data toward the bottom. I.e., if in particular you have two uses, on which requires less data than the other, you should place all the data for one use at the top, and add extra data near the bottom. A similar effect can be had with multiple Chunk definitions, but this is an easy and simple way to design flexibility without cluttering up your FORM's data chunk design. -Mitsu