 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <408ce85d$1@news.povray.org>,
Nicolas Calimet <pov### [at] free fr> 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
|
|
| |
| |
|
|
From: Nicolas Calimet
Subject: Re: Another high dynamic range format: FNG
Date: 26 Apr 2004 09:16:04
Message: <408d0b94@news.povray.org>
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <c6j8q1$6rh$1@chho.imagico.de>,
Christoph Hormann <chr### [at] gmxde> wrote:
> 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).
It would be trivial to add storage for 32 bit values...it probably would
only consist of modifying the error checking code to allow additional
values for depth and color type.
> And of course reading such files would be slower than
> reading the native binary format of that particular platform.
But not hugely so, considering that you get it as an array of bytes read
from a compressed file. The additional overhead of decoding the float
values would be quite small in comparison.
And of course, the image will most likely be processed with native data
types, which may not match the stored data type...that's just
unavoidable, unless you want to emulate math on the stored data type,
which would be much slower. I'm pretty sure all implementations of
single-precision floats will exactly represent all possible values of
these half-floats, but it may affect processing of single-float images.
BTW, I'm especially interested in 32 bit float grayscale images, for
depth maps. Tri-channel images would also be useful for normal and point
maps. The post-processing filters of MegaPOV 0.7 showed some of the
possibilities of post processing when this data is available.
32 bit grayscale could be hacked over RGBA images. 32 bit RGB could be
done easily as double-width 16 bit per component RGB images. But again,
these are hacks, it'd be far better to add new depths and color types,
which should be quite easy.
--
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 <408d3322$1@news.povray.org>,
Nicolas Calimet <pov### [at] freefr> wrote:
> > It is portable.
>
> Indeed, and this is why I answered to myself that I was wrong.
Oh, I see it now... "Yes, most likely."
I just mentally set it aside to figure out what you were talking about
later, and it never "clicked". Sorry.
> 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.
Understandable. Most people take the easy way out, either through
ignorance or laziness. It'd probably be different if the C library
included functions for converting to some cross-platform standardized
format.
> 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).
Well, I'll find out when I get around to emailing them about
it...probably not until after finals.
--
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
|
|
| |
| |
|
|
|
|
| |
