which file format to use to store raw grayscale ?

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I manipulate pictures as grayscale, and need to store them on hard drive WITHOUT ANY COMPRESSION, because I study the quality of the pictures, and can not accept any kind of picture compression. I would like to avoid inventing my own format. I want to use system libraries of Linux. Imlib can not create bmp at all. libjpeg and libpng can only write respective formats. I accept to use any standard format, providing it is open, can be used under Linux, and I can manipulate greyscale freely. I just need 8bpp. I also want to be able to load the files, and get them back also as greyscale. I can not accept to export to RGB files, and then import. What about ppm ? tiff ? what are the libs to manipulate them ? how to work only in greyscale ? - -- DEMAINE Beno�t-Pierre http:/www.demaine.info/ \_o< apt-get remove ispell >o_/ There're 10 types of people: those who can count in binary and those who can't. There are two kind of admins: those who have already done something bad as root, and those who will. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCBoA6GWSTLbOSw8IRAufdAKDCYvgFXw8mfT/D7WtrljyxKmqsEQCfVorv hYF/HMlpYS0NRK5kyKxJrbM= =MdOW -----END PGP SIGNATURE-----

"DEMAINE Benoit-Pierre" <nntp_pipex@demaine.info> wrote in message news:1qCdnbm695yhHZvfRVnyrA@pipex.net... > I manipulate pictures as grayscale, and need to store them on hard drive > WITHOUT ANY COMPRESSION, because I study the quality of the pictures, and > can not accept any kind of picture compression. PNG supports greyscale images, and uses lossless compression. If you really don't want compression (speed penalty is the only reason for this that I can think of), PPM is a trivial format. However, it is RGB only. This isn't really a problem - either use only one channel when you import or export, or set all channels to the same values on export and (if you wish) verify all are the same on import. Alex

On Sun, 6 Feb 2005, DEMAINE Benoit-Pierre wrote: > > I manipulate pictures as grayscale, and need to store them on hard drive > WITHOUT ANY COMPRESSION, because I study the quality of the pictures, and > cannot accept any kind of picture compression. http://www.contrib.andrew.cmu.edu/~ajo/#ImageFmtc http://www.contrib.andrew.cmu.edu/~ajo/free-software/ImageFmtc.h http://www.contrib.andrew.cmu.edu/~ajo/free-software/ImageFmtc.c > I also want to be able to load the files, and get them back also as > greyscale. > I can not accept to export to RGB files, and then import. This is a silly restriction. Do you know the difference between grayscale and RGB? Do you know what RGB stands for? > what are the libs to manipulate them ? how to work only in greyscale ? If you are dealing with 8bpp, grayscale, rectangular images, there is no reason to use any kind of manipulation library at all. If you really would feel naked without a gigantic dependency or two, I recommend libpng. Just don't ask me how to use it. -Arthur

"Alex Fraser" <me@privacy.net> wrote in message news:36nm0cF53tpkhU1@individual.net... > "DEMAINE Benoit-Pierre" <nntp_pipex@demaine.info> wrote in message > news:1qCdnbm695yhHZvfRVnyrA@pipex.net... > > I manipulate pictures as grayscale, and need to store them on hard drive > > WITHOUT ANY COMPRESSION, because I study the quality of the pictures, and > > can not accept any kind of picture compression. > > PNG supports greyscale images, and uses lossless compression. > > If you really don't want compression (speed penalty is the only reason for > this that I can think of), PPM is a trivial format. However, it is RGB only. > This isn't really a problem - either use only one channel when you import or > export, or set all channels to the same values on export and (if you wish) > verify all are the same on import. PGM is very close to PPM, but is designed for grayscale images, so it looks like the best choice if you want a format that is trivial to understand for that kind of images. -- Matthieu Villeneuve

In article <1qCdnbm695yhHZvfRVnyrA@pipex.net>, nntp_pipex@demaine.info says... > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I manipulate pictures as grayscale, and need to store them on hard drive > WITHOUT ANY COMPRESSION, because I study the quality of the pictures, and can > not accept any kind of picture compression. > > I would like to avoid inventing my own format. I want to use system libraries > of Linux. > Imlib can not create bmp at all. > libjpeg and libpng can only write respective formats. > I accept to use any standard format, providing it is open, can be used under > Linux, and I can manipulate greyscale freely. > > I just need 8bpp. > > I also want to be able to load the files, and get them back also as greyscale. > I can not accept to export to RGB files, and then import. > > What about ppm ? tiff ? > what are the libs to manipulate them ? how to work only in greyscale ? This is one case where inventing a format will do just fine! How about { int FILETYPE_IDENTIFIER int xSize int ySize BYTE[] data, left to right in rows from top } - Gerry Quinn

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 |> I also want to be able to load the files, and get them back also as |> greyscale. |> I can not accept to export to RGB files, and then import. | | | This is a silly restriction. Do you know the difference between | grayscale and RGB? Do you know what RGB stands for? I may work on very large files: if I import whatever the way a 200M greyscale, and the importing lib put it RGB, then I have a 600M array in memory, if it can keep it grayscale, then I only use 200M. That is 3 times less memory, 3 times les swap required, 3 times faster when applying personal filters on the lot. I am not dealing with 1M holidays pics ... I deal with very large amount of data. several G per day. - -- DEMAINE Beno�t-Pierre http:/www.demaine.info/ \_o< apt-get remove ispell >o_/ There're 10 types of people: those who can count in binary and those who can't. There are two kind of admins: those who have already done something bad as root, and those who will. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCB6pyGWSTLbOSw8IRAqNvAKCxkc8oKfKO/8nFGcNRfg1c4SzbmQCeMvq4 Ve6OnZK0aOZEHj4boDJSyLA= =RKyV -----END PGP SIGNATURE-----

On Mon, 7 Feb 2005, Gerry Quinn wrote: > nntp_pipex@demaine.info says... >> >> I manipulate pictures as grayscale, and need to store them on hard drive >> WITHOUT ANY COMPRESSION, because I study the quality of the pictures, >> and cannot accept any kind of picture compression. >> >> I would like to avoid inventing my own format. [...] >> What about ppm ? tiff ? >> what are the libs to manipulate them ? how to work only in greyscale ? > > This is one case where inventing a format will do just fine! > > How about > > { > int FILETYPE_IDENTIFIER > int xSize > int ySize > BYTE[] data, left to right in rows from top > } (1) -- Inventing your own file format is hardly ever a good idea, especially in cases like this one, in which you (the OP) admit you don't know much about the topic and /do/ know that solutions already exist. (2) -- That's not a file format, it's a pseudo-C-struct definition. (3) -- Modulo weirdnesses such as FILETYPE_IDENTIFIER's being a two-byte sequence instead of an "int", that's exactly the PNM format[1] that several regulars have already recommended to the OP. -Arthur [1] - "PNM" is the abbreviation for PBM/PGM/PPM and beyond. If you (the OP) use Linux, you probably have the libpnm utilities already installed. 'man libpnm' for details.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 |>export, or set all channels to the same values on export and (if you wish) |>verify all are the same on import. | | | PGM is very close to PPM, but is designed for grayscale images, so | it looks like the best choice if you want a format that is trivial to | understand for that kind of images. that looks good. Ok the format is lossless, and files can be loaded/saved using libnetpbm. Note that when loading the file, whether the file is 8bpp or 16bpp, each pixel is copied in a (int) cell, what means 24bpp. For many ppl it does not matter. For me it does since I use large files, and allocating 4B per pixel requires 4 times memory or SWAP for filtering each file. I did not find any workaround. - -- DEMAINE Beno�t-Pierre http:/www.demaine.info/ \_o< apt-get remove ispell >o_/ There're 10 types of people: those who can count in binary and those who can't. There are two kind of admins: those who have already done something bad as root, and those who will. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCB8M2GWSTLbOSw8IRAkvHAJ4kCvQqSzn0HSETLpNwQVM8jb2cHQCguZzC DffToIwF86EFYlI/HtY8LY4= =66ia -----END PGP SIGNATURE-----

In article <Pine.LNX.4.60-041.0502071324580.3624@unix48.andrew.cmu.edu>, ajo@nospam.andrew.cmu.edu says... > On Mon, 7 Feb 2005, Gerry Quinn wrote: > > nntp_pipex@demaine.info says... > >> > >> I manipulate pictures as grayscale, and need to store them on hard drive > >> WITHOUT ANY COMPRESSION, because I study the quality of the pictures, > >> and cannot accept any kind of picture compression. > >> > >> I would like to avoid inventing my own format. > > > > This is one case where inventing a format will do just fine! > > > > How about > > > > { > > int FILETYPE_IDENTIFIER > > int xSize > > int ySize > > BYTE[] data, left to right in rows from top > > } > > (1) -- Inventing your own file format is hardly ever a good idea, > especially in cases like this one, in which you (the OP) admit you > don't know much about the topic and /do/ know that solutions already > exist. If the format is this trivial (and it likely is) then it can be implemented in a time best specified in minutes, not hours. So I don't see anything wrong with it. > (2) -- That's not a file format, it's a pseudo-C-struct definition. It's a file format described briefly using a pseudo struct definition. If we were to associate a struct with it, the greyscale data would normally be held separately in memory, and the last variable would be a pointer to the data array. But as a file, the greyscale data is explicitly present following the 'informational' data. > (3) -- Modulo weirdnesses such as FILETYPE_IDENTIFIER's being a > two-byte sequence instead of an "int", that's exactly the PNM format[1] > that several regulars have already recommended to the OP. > > [1] - "PNM" is the abbreviation for PBM/PGM/PPM and beyond. If you > (the OP) use Linux, you probably have the libpnm utilities already > installed. 'man libpnm' for details. Never heard of PNM. But it really is rather trivial to reinvent the wheel in this case. (Also I would personally not be comfortable with a two-byte identifier. Indeed, I would use eight bytes, with the option of using the second int to represent a subtype.) Still, it all depends on what he wants to do. In the simplest case it amounts to saving an array and its xy dimensions. - Gerry Quinn

On Mon, 7 Feb 2005, DEMAINE Benoit-Pierre wrote: [re: PNM format for grayscale images] > that looks good. > > Ok the format is lossless, and files can be loaded/saved using libnetpbm. > > Note that when loading the file, whether the file is 8bpp or 16bpp, each > pixel > is copied in a (int) cell, what means 24bpp. Actually, very few modern platforms have 24-bit ints. Perhaps you meant "32bpp"? Anyway, that's only relevant if you use libnetpbm for reading and writing PNM files, which sounds like overkill to me. (Can you guess why? Hint: I gave you the answer in my first post in this thread.) > I did not find any workaround. Workaround for what? -Arthur

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 |> is copied in a (int) cell, what means 24bpp. | | Actually, very few modern platforms have 24-bit ints. Perhaps you meant | "32bpp"? sure you are right: I meant 32b per pixel ... what is in my case 24 bits lost. | Anyway, that's only relevant if you use libnetpbm for reading | and writing PNM files, which sounds like overkill to me. (Can you guess | why? Hint: I gave you the answer in my first post in this thread.) no ... cant find the answer. | Workaround for what? to force libnetpbm storing directly the data in an array of 8bits per cell, or at least 16b .... because using 32 means at least 16 bits lost, and 24 in my case ( since I use only 8bpp); that means 75% memory allocated for nothing !!! Any may, that libpgm is perfect for what I need, exept about memory allocation. But that have some good side effects. - -- DEMAINE Beno�t-Pierre http:/www.demaine.info/ \_o< apt-get remove ispell >o_/ There're 10 types of people: those who can count in binary and those who can't. There are two kind of admins: those who have already done something bad as root, and those who will. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCCGVpGWSTLbOSw8IRAoeHAKCMnGJkiQ3d5yBWcs3reTjiLtPomwCffe/b jeNdd+kviUVxjt8qn6mCNI0= =ihyF -----END PGP SIGNATURE-----

On Tue, 8 Feb 2005, DEMAINE Benoit-Pierre wrote: [I wrote:] > | Anyway, that's only relevant if you use libnetpbm for reading > | and writing PNM files, which sounds like overkill to me. (Can you guess > | why? Hint: I gave you the answer in my first post in this thread.) > > no ... cant find the answer. *sigh* From my first post in this thread: http://www.contrib.andrew.cmu.edu/~ajo/#ImageFmtc http://www.contrib.andrew.cmu.edu/~ajo/free-software/ImageFmtc.h http://www.contrib.andrew.cmu.edu/~ajo/free-software/ImageFmtc.c Explanation: The idea of using libnetpbm to read PGM images seems like overkill to me because I have already implemented a PGM reader and writer with much less overhead. The implication is that you may wish to use the "ImageFmtc" library in your project, or use it as a guide for writing your own PGM I/O functions. -Arthur

> or use > it as a guide for writing your own PGM I/O functions. I am not going to rewrite anything about files ... I wanna use standard libraries. My project deals with OCR, not picture formats. -- DEMAINE Beno�t-Pierre http:/www.demaine.info/ \_o< apt-get remove ispell >o_/ There're 10 types of people: those who can count in binary and those who can't. There are two kind of admins: those who have already done something bad as root, and those who will.