🚀 go-pugleaf

Paul Richards wrote:
> 
> Hi,
> Does anyone know of a simple image file format that I can use that can
> handle 16bits per channel?  In effect producing 48bit colour images?  I
> mean simple in that it'll be easy for me to write the input/output
> routines for in C++.
> 
Both TIFF and NITF can be set to run in that mode.  I'm fairly certain
that the Leffler/SGI libtiff.a will do it for you so you don't even
have to write the code to deal with the TIFF nitty-gritty.

Paul Richards wrote:
> 
> Hi,
> Does anyone know of a simple image file format that I can use that can
> handle 16bits per channel?  In effect producing 48bit colour images?  I
> mean simple in that it'll be easy for me to write the input/output
> routines for in C++.

There's also the Portable Network Graphics (PNG). It might not be the
easiest format to read/write, but it compresses well, is the coming
standard for WWW graphics, and C source code is available.

Have a look at

http://graphicswiz.com/png/

HTH,

  Oliver

-- 
Email: kreylos@cs.ucdavis.edu
WWW:   http://graphics.cs.ucdavis.edu/~okreylos

Oliver Kreylos wrote:
> 
> Paul Richards wrote:
> >
> > Does anyone know of a simple image file format that I can use that can
> > handle 16bits per channel?  In effect producing 48bit colour images?  I
> > mean simple in that it'll be easy for me to write the input/output
> > routines for in C++.
> 
> There's also the Portable Network Graphics (PNG). It might not be the
> easiest format to read/write, but it compresses well, is the coming
> standard for WWW graphics, and C source code is available.

In defense of PNG's encoding, the only other option suggested here is
TIFF, which uses a similar compression algorithm to PNG's -- PNG uses
LZH (?) and TIFF uses LZW.  And let's not forget the Unisys patent on
LZW: it applies to TIFF just as well as to GIF.
-- 
= Warren -- ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m

Warren Young wrote:
[snip]
> In defense of PNG's encoding, the only other option suggested here is
> TIFF, which uses a similar compression algorithm to PNG's -- PNG uses
> LZH (?) and TIFF uses LZW.  And let's not forget the Unisys patent on
> LZW: it applies to TIFF just as well as to GIF.

Right. Actually, the encoding mechanism used by PNG is called "deflate",
and it is based on the LZ77 sliding window algorithm and Huffman
encoding of literal/length and distance pairs.

As opposed to LZW, LZ77 is not patented itself; some implementations
using special "tricks" might be. But PNG uses a non-patented
implementation and is thus not endangered as is TIFF/GIF.

  Oliver

-- 
Email: kreylos@cs.ucdavis.edu
WWW:   http://graphics.cs.ucdavis.edu/~okreylos

Paul Richards wrote:
> Hi,
> Does anyone know of a simple image file format that I can use that can
> handle 16bits per channel?
[snip]

I've just found out about 16bit greyscale TGA's.  Does anyone know how
these are coded or perhaps some documentation that would tell me?
-- 
Paul Richards (Pauldoo) - http://www.pauldoo.co.uk

I've not run any Microsoft code for 2770077 seconds.
    How about you?

Paul Richards <pauldoo@dunvegan1.demon.co.uk> wrote:
: Hi,
: Does anyone know of a simple image file format that I can use that can
: handle 16bits per channel?  In effect producing 48bit colour images?  I
: mean simple in that it'll be easy for me to write the input/output
: routines for in C++.

ppm

-- 
This is a test of the Emergency Broadcast System.  If this had been an
actual emergency, do you really think we'd stick around to tell you?

In article <38699999.9E9CC97D@mail.com>,
  Warren Young <tangent@mail.com> wrote:

> In defense of PNG's encoding, the only other option suggested here is
> TIFF, which uses a similar compression algorithm to PNG's -- PNG uses
> LZH (?) and TIFF uses LZW.  And let's not forget the Unisys patent on
> LZW: it applies to TIFF just as well as to GIF.

LZW is only one of the storage methods within TIFF and LZW support
has been dropped from the latest version of libtiff according to the
freshmeat announcement that appeared the other day.  I don't know
whether LZW-reading capability was retained, but I would assume so.

--
Glenn Randers-Pehrson
PNG/MNG Development Group


Sent via Deja.com http://www.deja.com/
Before you buy.

Victor Wagner wrote:
> 
> Paul Richards <pauldoo@dunvegan1.demon.co.uk> wrote:
> : Hi,
> : Does anyone know of a simple image file format that I can use that can
> : handle 16bits per channel?  In effect producing 48bit colour images?  I
> : mean simple in that it'll be easy for me to write the input/output
> : routines for in C++.
> 
> ppm

PPM can't do 16bits per channel or 16bit greyscale which is what I'm
looking for.
-- 
Paul Richards (Pauldoo) - http://www.pauldoo.co.uk

I've not run any Microsoft code for 2907177 seconds.
    How about you?

Paul Richards wrote:
> 
> Victor Wagner wrote:
> >
> > Paul Richards <pauldoo@dunvegan1.demon.co.uk> wrote:
> > : Hi,
> > : Does anyone know of a simple image file format that I can use that can
> > : handle 16bits per channel?  In effect producing 48bit colour images?  I
> > : mean simple in that it'll be easy for me to write the input/output
> > : routines for in C++.
> >
> > ppm
> 
> PPM can't do 16bits per channel or 16bit greyscale which is what I'm
> looking for.

I think it can. The ASCII ppm format is rather flexible. AFAIK, you can
have arbitrarily large values per channel per pixel, you just should
give the maximal used value in the "maxValue" field.

The binary ppm format, on the other hand, supports only 8 bit values per
channel per pixel.

But since ASCII ppm is a horribly bloated format, I still suggest using
PNG. (ppm is *much* easier to read or write, though...)

  Oliver

-- 
Email: kreylos@cs.ucdavis.edu
WWW:   http://graphics.cs.ucdavis.edu/~okreylos

Paul Richards wrote:
> 
> Victor Wagner wrote:
> >
> > Paul Richards <pauldoo@dunvegan1.demon.co.uk> wrote:
> > : Hi,
> > : Does anyone know of a simple image file format that I can use that can
> > : handle 16bits per channel?  In effect producing 48bit colour images?  I
> > : mean simple in that it'll be easy for me to write the input/output
> > : routines for in C++.
> >
> > ppm
> 
> PPM can't do 16bits per channel or 16bit greyscale which is what I'm
> looking for.
>

Huh?

The "ASCII" ppm format (with P3 tag) can contain 16 bits per channel.

Here is an example file: (4 pixels)
--------------------
P3
2 2
65535
65535 0 0
0 65535 0
0 0 65535
65535 0 65535
--------------------


		Eero

Oliver Kreylos wrote:
> 
> Paul Richards wrote:
> >
> > Victor Wagner wrote:
> > >
> > > Paul Richards <pauldoo@dunvegan1.demon.co.uk> wrote:
> > > : Hi,
> > > : Does anyone know of a simple image file format that I can use that can
> > > : handle 16bits per channel?  In effect producing 48bit colour images?  I
> > > : mean simple in that it'll be easy for me to write the input/output
> > > : routines for in C++.
> > >
> > > ppm
> >
> > PPM can't do 16bits per channel or 16bit greyscale which is what I'm
> > looking for.
> 
> I think it can. The ASCII ppm format is rather flexible. AFAIK, you can
> have arbitrarily large values per channel per pixel, you just should
> give the maximal used value in the "maxValue" field.

ASCII PPM?  What do you mean by that?  The PPM's I currently can make
have the header in ASCII, and they do have a "maxValue" field but the
data is just raw binary.

Could you explain a little further on how these ASCII ones work?
-- 
Paul Richards (Pauldoo) - http://www.pauldoo.co.uk

I've not run any Microsoft code for 2926857 seconds.
    How about you?

Paul Richards wrote:
[snip]
> ASCII PPM?  What do you mean by that?  The PPM's I currently can make
> have the header in ASCII, and they do have a "maxValue" field but the
> data is just raw binary.
> 
> Could you explain a little further on how these ASCII ones work?

Well, I can try...

The header for an ASCII ppm is the code P3, followed by width, height
and maxValue, as usual. Note that the values for those fields are given
in ASCII - I mean, they are printed out.

In a "raw" or binary ppm file, the code is a P6, and the image data is
written as a series of bytes - three per pixel. In the ASCII format,
each pixel is written as three integer values - all spelled out.
Example:

P3
2 2 1000

   0    0    0       0 1000    0

1000    0    0    1000 1000 1000

The maxVal field can be arbitrarily large (well, let's say it *can* be
65535), so you can effectively store 16 bits per channel per pixel.

HTH,

  Oliver

-- 
Email: kreylos@cs.ucdavis.edu
WWW:   http://graphics.cs.ucdavis.edu/~okreylos

Paul Richards wrote:

> ASCII PPM?  What do you mean by that?  The PPM's I currently can make
> have the header in ASCII, and they do have a "maxValue" field but the
> data is just raw binary.
>
> Could you explain a little further on how these ASCII ones work?
>

I guess you missed my reply on c.l.c++ so I'll repeat it.  Go to
http://www.wotsit.org/ and look up ppm in the graphics file formats.

You're probably used to using the smaller/faster "P6" variation of PPM.  The
original was "P3" and used whitespace delimited ascii numbers for the RGB pixel
values.

Paul Richards <pauldoo@dunvegan1.demon.co.uk> wrote:
: Victor Wagner wrote:
:> 
:> Paul Richards <pauldoo@dunvegan1.demon.co.uk> wrote:
:> : Hi,
:> : Does anyone know of a simple image file format that I can use that can
:> : handle 16bits per channel?  In effect producing 48bit colour images?  I
:> : mean simple in that it'll be easy for me to write the input/output
:> : routines for in C++.
:> 
:> ppm

: PPM can't do 16bits per channel or 16bit greyscale which is what I'm
: looking for.

P6 cannot, but P3 - ascii format PPM, can. Of course, files would be
_HUGE_.

Here is quote from man ppm(5)

       Note  that  this  raw  format can only be used for maxvals
       less than or equal to 255.  If you use the ppm library and
       try to write a file with a larger maxval, it will automat�
       ically fall back on the slower but more general plain for�
       mat.


-- 
"Help save the world!"              -- Larry Wall in README

Philip Staite wrote:
> 
> Paul Richards wrote:
> 
> > ASCII PPM?  What do you mean by that?  The PPM's I currently can make
> > have the header in ASCII, and they do have a "maxValue" field but the
> > data is just raw binary.
> >
> > Could you explain a little further on how these ASCII ones work?
> >
> 
> I guess you missed my reply on c.l.c++ so I'll repeat it.  Go to
> http://www.wotsit.org/ and look up ppm in the graphics file formats.

Hehe, no I did get that post, but I only noticed specs for the "P6"
binary version.  I apologise if it was on the wotsit website and I
missed it.
-- 
Paul Richards (Pauldoo) - http://www.pauldoo.co.uk

I've not run any Microsoft code for 2981458 seconds.
    How about you?