Hi everyone. Yes, what the world really doesn't need right now is a new image file format. However, bear with me for a bit, there may be method in my madness. I have used this format (or earlier variants of it) for a couple of years now, and I can recommend it for development and rapid prototyping. The header writer can be a single print statement to start off with. The trouble with most image formats was... (1) They were only machine-readable. This meant you had to write a header debugger to pull apart a TIFF file or a DICOM file just to see how they worked, or spend hours peering over a hex dump. (2) They were not upgradeable. If you wanted an extra data entry for the pixel size or some note about the source image, then sometimes you could stuff it into a comment field. (3) They were not suitable for prototyping. To read or write a TIFF image you have to import a huge lump of head reading code. (4) The documentation was often bad or missing. The PNM formats seemed to be a good start. You could open these images with 'emacs' or a similar editor that did not insert line breaks in the image data. You could recognize the X and Y pixel counts without documentation, though the data format was a bit cryptic. What I have tried to do is to make the whole of the image header one big comment field. It should be readable and editable using a text editor. For example the 'cola.ahf' image starts with... AHF{ values{3} lines{17} pixels{28} }... If I have done my job properly then you ought to guess the following... * "AHF{" always starts the image. This can be used as a 'magic number'. * The header is the stuff between "AHF{" and the closing bracket "}". * The raw data starts straight after the closing bracket. * There are 3 values per pixel, 28 pixels per line, 17 lines in the image. * The format of the entries is {} The header of 'eye.ahf' starts with... AHF{ pixels{25} lines{20} compression{ quality{50} offset{0.0} } }... We can then see... * The order of the entries is not important. * We can stick in extra entries. The 'compression' entry has no effect unless we write something to interpret it. * The arguments can include curly brackets, so you can have a hierarchy of entries. * The number of values per entry defaults to 1. A few other things which may not be obvious without yet more examples... * The key names can include whitespace, but leading and trailing whitespace is ignored. This means you can format the header as you want. * '{' and '}' are the only characters that have a special meaning. You could include any other byte values. UTF8 coded Unicode is anticipated. Sticking in zero bytes or control characters or non-readable stuff is not encouraged. * There is no escape code if you want to include curly brackets in your arguments. If you want to put unmatched curly brackets into your arguments, then you will have to find some way of doing that yourself. * Keys with null names {} are not encouraged. The full form of a header for an image might be... AHF{ format{unsigned} bits{16} values{3} pixels{512} lines{768} frames{1} } There are... The numbers are unsigned (signed is the default for 16-bit images), 16 bits per value (my default is 8, probably restricted to powers of 2), 3 values per pixel (my default is 1, can be more than 3), 512 pixels per line (no legal default, must be > 1), 768 lines per frame (no legal default, must be > 1), 1 frame per image (default = 1, reserved but not implemented), ...then if the data continues with "AHF{" then you have a stack of images, and you can start reading the next. This should mean you can make and unmake stacks using a good text editor. NB: I have avoided using terms like 'height' or 'width' or X and Y. I used to work with drum scanners where lines went down the page, and I have met most of the 8 possible orientations within TIFF. Byte, short, int, float, and double data is written in big-endian format as a DataOutputStream might write it. The data is packed in order of values, then pixels, then lines, then frames. This meant I could make a writer from the RAW format writer by just sticking a header on the front. I did that yesterday. It only took a couple of hours. AHF is an extension that does not not seem to be used elsewhere. If you find a clash, please let me know. Possible extensions: I also support 1-bit, 2-bit, and 4-bit images but I have not stuck those into the supplied reader yet. When I do, they will be packed into bytes, with the high byte being the most significant one. I support float and 32-bit integer images, but I have not got any read data (as opposed to format-converted 16-bit images) to test it with. I have an option for human-readable data. It was based on 'C' format strings and I will probably change it. I may have an entry like... reader{ASCII} ..with options of RAW, ASCII, JPEG, and so on. I have a writer as well as a reader. However it is not as easy to plug in the writer so I have left it out of this note. If this sort of thing is of interest, please let me know. Cheers. Richard Kirk