I've created a new image format for storing high dynamic range images. 
The new format is quite simple to implement: it is basically a 16-bit 
PNG with a gamma of 1, using half-precision floating point numbers 
instead of 16 bit integers. It's a bit of a hack, but it seems to work 
quite well.
The floating point format I use is 5 exponent bits, giving an exponent 
range from -16 to 15, and 11 mantissa bits, for a range of 0 to 2047. I 
did not include a sign bit, thus the format can only contain positive 
values...I do not think negative values are useful enough to warrant the 
loss in precision. I might add a second 1-5-10 format if it turns out to 
be useful.

Benefits: you get basically all the benefits of the PNG format, such as 
compression. The other HDRI formats I've seen are uncompressed or use 
relatively crude forms of compression, and tend to result in huge files.
Implementation is quite easy. Once you have PNG reading/writing, FNG is 
just a few extra lines. The resulting files are actually readable by PNG 
viewers...the colors are dimmed in the resulting display, but the image 
is recognizable.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

> I've created a new image format for storing high dynamic range images. 
> The new format is quite simple to implement: it is basically a 16-bit 
> PNG with a gamma of 1, using half-precision floating point numbers 
> instead of 16 bit integers. It's a bit of a hack, but it seems to work 
> quite well.

	Cool !
	The question now is: are you going to patent your idea, or will
you release it shortly in the form of an OpenSource project ?  ;-)

	- NC

Post a reply to this message

In article <408ce85d$1@news.povray.org>,
 Nicolas Calimet <pov### [at] freefr> wrote:

> > I've created a new image format for storing high dynamic range images. 
> > The new format is quite simple to implement: it is basically a 16-bit 
> > PNG with a gamma of 1, using half-precision floating point numbers 
> > instead of 16 bit integers. It's a bit of a hack, but it seems to work 
> > quite well.
> 
> 	Cool !
> 	The question now is: are you going to patent your idea, or will
> you release it shortly in the form of an OpenSource project ?  ;-)

Heh, the way things are going these days, I might need to patent it in 
self-defense...
I'm going to release it after I have a few more tools...currently, I 
have a viewer and converters to/from PNG, I plan to write converters 
to/from some other HDRI formats. At the very least, I need to implement 
grayscale and some kind of PNG meta-data tag to identify the FNG files 
as such.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:
> I've created a new image format for storing high dynamic range images. 
> The new format is quite simple to implement: it is basically a 16-bit 
> PNG with a gamma of 1, using half-precision floating point numbers 
> instead of 16 bit integers. It's a bit of a hack, but it seems to work 
> quite well.
> The floating point format I use is 5 exponent bits, giving an exponent 
> range from -16 to 15, and 11 mantissa bits, for a range of 0 to 2047. I 
> did not include a sign bit, thus the format can only contain positive 
> values...I do not think negative values are useful enough to warrant the 
> loss in precision. I might add a second 1-5-10 format if it turns out to 
> be useful.

This is an interesting idea although as long as there isn't support for 
such files at least in some applications it will not be so useful.  You 
might consider proposing this to the libpng guys so it might get added 
to libpng.

Signed values might be useful for non-Image applications but in most 
cases you would want at least 32bit floating point values for this.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 21 Mar. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

> You 
> might consider proposing this to the libpng guys so it might get added 
> to libpng.

	But using floating point in this format as Christopher describes
is not "portable" (the P in PNG) anymore, or am I wrong somewhere ?

	- NC

Post a reply to this message

[answering to myself]
> am I wrong somewhere ?

	Yes, most likely.

	- NC

Post a reply to this message

In article <408d0b94@news.povray.org>,
 Nicolas Calimet <pov### [at] freefr> wrote:

> > You 
> > might consider proposing this to the libpng guys so it might get added 
> > to libpng.
> 
> 	But using floating point in this format as Christopher describes
> is not "portable" (the P in PNG) anymore, or am I wrong somewhere ?

It is portable.
The portability problem with binary data comes from the fact that the 
native format may have a different layout on different platforms. The 
FNG code encodes and decodes the actual bit pattern, and will read and 
write it the same way on all platforms.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

In article <c6iui9$54s$1@chho.imagico.de>,
 Christoph Hormann <chr### [at] gmxde> wrote:

> This is an interesting idea although as long as there isn't support for 
> such files at least in some applications it will not be so useful. 

That's why I'm working on converters to/from other HDRI formats. ;-)


> You might consider proposing this to the libpng guys so it might get 
> added to libpng.

That is a good idea...it obviously wouldn't take much to add, basically 
just define another couple color types. Optimal compression might be a 
bit harder...


> Signed values might be useful for non-Image applications but in most 
> cases you would want at least 32bit floating point values for this.

Hmm...sFNG? (signed FNG)
FNG32? (How to fit the extra bits in?  Probably a custom data "chunk".)

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:
> 
> It is portable.
> The portability problem with binary data comes from the fact that the 
> native format may have a different layout on different platforms. The 
> FNG code encodes and decodes the actual bit pattern, and will read and 
> write it the same way on all platforms.
> 

And actually the same would be possible for 32bit floating point values, 
you just would need to have a convention for the distribution of bits 
for mantissa/exponent and a file format storing 32bit values (which png 
IIRC does not).  And of course reading such files would be slower than 
reading the native binary format of that particular platform.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 21 Mar. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

> It is portable.

	Indeed, and this is why I answered to myself that I was wrong.
It's just that I'm so used to softwares writing raw floating-point data
by people who don't even know what is endianness that I was immediatly
suspicious of using floating point in PNG... until I re-read your
message and the bit distribution you proposed.

	As Christoph suggests, that would be quite nice to make it in
the official PNG format, instead of making it a derivative.  That could
go in e.g. libpng-1.3 -- the only drawback is: when would it appear ?
(png and zlib developpers are not particularly fast at releasing new
versions, and I don't know their policies in accepting contributions).

	- NC

Post a reply to this message