GraLIC - new lossless image compressor
Alex Ratushnyak
http://encode.dreamhosters.com/attachment.php?attachmentid=1262&d=1271456170
It accepts only 8-bit grayscale images in PNM format.
Compresses some images better and faster than MRP, BMF, PAQ8* and
others.
The program was compiled with option -march=pentiumpro, I believe it
will run on almost any modern IBM-compatible PC. On the other hand, it
was designed for images with sizes between 2 and 10 Mb, there is no
point in testing it on traditional 512x512 or smaller images.
This executable for 32-bit Windows will fail if image width* is bigger
than 8184.
*or height, because some images are rotated, and there is no switch to
choose other rotation in the demo version.
Please e-mail to Alex at fleetwarecorp kom and bfrusina at rogers kom
for more info.
Thomas Richter
> Demo version of a new lossless image compressor is available here:
> http://encode.dreamhosters.com/attachment.php?attachmentid=1262&d=1271456170
How does it perform compared to JPEG-LS? What is its complexity?
For testing, I can provide a set of test images we used for the JPEG
internally.
Greetings,
Thomas
Alex Ratushnyak
It depends on what images you compress. We rarely compared to JPEG-LS
because its compression quality is rarely good enough, i.e. close to
what BMF, MRP and PAQ8px achieve.
For example, the first image considered in this thread:
http://encode.dreamhosters.com/showthread.php?t=595 . HP
implementation of JPEG-LS -- http://www.hpl.hp.com/loco/jlsrefV100.zip
-- compresses it to 1'999'693 bytes, that is 156.96% of GraLIC
compressed file size -- 1'274'046 bytes.
> What is its complexity?
It runs in linear time, if you mean time complexity.
> For testing, I can provide a set of test images we used for the JPEG internally.
Yes, please provide.
Thank you!
Thomas Richter
>> How does it perform compared to JPEG-LS?
>
> It depends on what images you compress. We rarely compared to JPEG-LS
> because its compression quality is rarely good enough, i.e. close to
> what BMF, MRP and PAQ8px achieve.
Well, it is nevertheless a very good lossless image compressor. The only
thing it does not do is a decorrelation accross components. Therefore,
this should be either added, or the compression should be compared on
grey-scale.
> For example, the first image considered in this thread:
> http://encode.dreamhosters.com/showthread.php?t=595 . HP
> implementation of JPEG-LS -- http://www.hpl.hp.com/loco/jlsrefV100.zip
> -- compresses it to 1'999'693 bytes, that is 156.96% of GraLIC
> compressed file size -- 1'274'046 bytes.
>
>> What is its complexity?
>
> It runs in linear time, if you mean time complexity.
Well, that goes for most compressors. (-: I was considering the
approximate running time.
>> For testing, I can provide a set of test images we used for the JPEG internally.
>
> Yes, please provide.
Is your email address valid? Mine is. Please check your inbox.
Greetings,
Thomas
Niels Fröhling
> Well, it is nevertheless a very good lossless image compressor. The only
> thing it does not do is a decorrelation accross components. Therefore,
> this should be either added, or the compression should be compared on
> grey-scale.
His compressor is greyscale only.
Ciao
Niels
Thomas Richter
In that case, I'm curious about the results. Niels, I think you do have
the JPEG test suite already, don't you?
So long,
Thomas
Sachin Garg
> Demo version of a new lossless image compressor is available here:http://encode.dreamhosters.com/attachment.php?attachmentid=1262&d=127...
>
> It accepts only 8-bit grayscale images in PNM format.
> Compresses some images better and faster than MRP, BMF, PAQ8* and
> others.
> The program was compiled with option -march=pentiumpro, I believe it
> will run on almost any modern IBM-compatible PC. On the other hand, it
> was designed for images with sizes between 2 and 10 Mb, there is no
> point in testing it on traditional 512x512 or smaller images.
> This executable for 32-bit Windows will fail if image width* is bigger
> than 8184.
> *or height, because some images are rotated, and there is no switch to
> choose other rotation in the demo version.
>
> Please e-mail to Alex at fleetwarecorp kom and bfrusina at rogers kom
> for more info.
Interesting. Can you share some numbers for speed and compression
results compared with jpeg-ls, bmf etc... maybe on images at
www.imagecompression.info
Its fair to ignore the traditional 512x512 images but out of
curiosity, is GraLIC known to perform worse on them or you just didn't
check?
In my own little test on one image, compression is better than jpeg-ls
and speed is slower (for 8-bit gray 2000x3008 cathedral.pgm, it is
3.569 bpp vs 3.188 bpp and 0.7 seconds vs 5.2 seconds). More numbers
on a larger number of images will be interesting to see. And
approximately how much memory does it need?
Is the algorithm scalable to 16-bit images like those at
imagecompression.info, any plans to support them?
Any plans to share code or 'general' algorithm details (with or
without your secret sauce)? eg X style arithmetic coding with context
based on X, Y, Z with LSE predictor or weighted blending of few fixed
predictors etc? I think MRP and BMF use LSE and glicbawls used
blending.
Sachin Garg
www.sachingarg.com
Niels Fröhling
I think it should be in your Richter-section in
http://cdb.paradice-insight.us, you mean the Honolulu-pics, right?
I'm going to post some stats later this night.
Ciao
Niels
Sachin Garg
> Thomas Richter wrote:
> > Niels Fröhling wrote:
> >> Thomas Richter wrote:
>
> >>> Well, it is nevertheless a very good lossless image compressor. The only
> >>> thing it does not do is a decorrelation accross components. Therefore,
> >>> this should be either added, or the compression should be compared on
> >>> grey-scale.
>
> >> His compressor is greyscale only.
>
> > In that case, I'm curious about the results. Niels, I think you do have
> > the JPEG test suite already, don't you?
>
>
> I'm going to post some stats later this night.
Not replying in your other thread to not break your series of posts.
The numbers look like they are "size and bpp". Do you record time
results too? And what is the difference between tiff lzw 1 and lzw 2?
SG
Niels Fröhling
> Not replying in your other thread to not break your series of posts.
> The numbers look like they are "size and bpp". Do you record time
> results too? And what is the difference between tiff lzw 1 and lzw 2?
Hm, no I don't record time. It's a bit pointless as these implementations are
not high quality industrial strength ready-to-use softwares.
LZW in TIFF has a variation in that I believe entire line-strides get
delta-coded (with the line below) before LZWed. I think it's just legacy stuff.
In theory I should have results for pixel/line/plane-interleave modes, but I
mean who's really interested in TIFF results. :^)
For floating-point TIFF becomes attractive again. It's very thin in that area.
EXR, TIFF, JPEG2000 and PW. No more. And only EXR and PW do half-precision
floats I believe. Also when I start to do 7-band infraband compression-tests
(like in 5 years maybe :-D) there are not much systems that can do 7 planes. I
was hoping I get N-dimensional KLT working. Anyway maybe PNG can do 7 planes too.
Ciao
Niels
Sachin Garg
> Sachin Garg wrote:
> > Not replying in your other thread to not break your series of posts.
> > The numbers look like they are "size and bpp". Do you record time
> > results too? And what is the difference between tiff lzw 1 and lzw 2?
>
> Hm, no I don't record time. It's a bit pointless as these implementations are
> not high quality industrial strength ready-to-use softwares.
Yep, most of these coders are significantly slower but by not
recording time we might miss if one of them is both reasonably fast
and gives reasonably better compression.
The definition of 'reasonable' is of course open to individual
interpretation :-)
> LZW in TIFF has a variation in that I believe entire line-strides get
> delta-coded (with the line below) before LZWed. I think it's just legacy stuff.
> In theory I should have results for pixel/line/plane-interleave modes, but I
> mean who's really interested in TIFF results. :^)
OK, thanks for clarifying and agreed that its ok to ignore other
permutations. I just got curious thinking if there exists a better
alternate implementation of LZW.
SG
Alex Ratushnyak
Didn't check because the goal was to minimize compressed size, not the
average bpp
> And approximately how much memory does it need?
ImageSize plus... less than 3 mb, afair
> Is the algorithm scalable to 16-bit images like those at
> imagecompression.info, any plans to support them?
yes, plus a lot of other plans, to-do list is far from being empty
> Any plans to share code or 'general' algorithm details (with or
> without your secret sauce)?
I wrote an article last year, planning to publish it in a periodical
with at least 1000 readers, but had no time to find and then
communicate with interested periodical(s). None of them got it, afaik,
so if you suggest a periodical I'll probably send it to them this
week.
Alex
Sachin Garg
> > imagecompression.info, any plans to support them?
>
> yes, plus a lot of other plans, to-do list is far from being empty
Great, looking forward to updates.
> so if you suggest a periodical I'll probably send it to them this
> week.
Sorry but don't know much about periodicals or journals etc.
SG
Thomas Richter
> Thomas Richter wrote:
>> Niels Fröhling wrote:
>>> Thomas Richter wrote:
>>>
>>>> Well, it is nevertheless a very good lossless image compressor. The
>>>> only
>>>> thing it does not do is a decorrelation accross components. Therefore,
>>>> this should be either added, or the compression should be compared on
>>>> grey-scale.
>>>
>>> His compressor is greyscale only.
>>
>> In that case, I'm curious about the results. Niels, I think you do have
>> the JPEG test suite already, don't you?
>
> I think it should be in your Richter-section in
> http://cdb.paradice-insight.us, you mean the Honolulu-pics, right?
That, plus the JPEG test suite (partially from the Waterloo test set,
and some other classics used for JPEG testing).
Greetings,
Thomas
Thomas Richter
A good place for such stuff is either the DCC conference, or the ICIP
conference. Both high-class, high-value conferences with the right
people to talk to.
So long,
Thomas
Thomas Richter
> LZW in TIFF has a variation in that I believe entire line-strides get
> delta-coded (with the line below) before LZWed. I think it's just legacy
> stuff. In theory I should have results for pixel/line/plane-interleave
> modes, but I mean who's really interested in TIFF results. :^)
(-:
> For floating-point TIFF becomes attractive again. It's very thin in
> that area. EXR, TIFF, JPEG2000 and PW. No more.
Update: In JPEG2000, we planned floating point for part-11, but since
nobody cared for a long time, this got delayed. Now in the meantime, we
did get *some* interest, and floating point will be (or actually, is
under standardization) retro-fit into part-2 now that we know how to do
it "right". JPEG2000 floating point compression will be fairly generic
and will be able to express a wide selection of possible floating point
encodings, amongst which you'll find well-known ones like IEEE single
precision and OpenGL "Half-Float". Thus, both will be supported. There
is currently not yet an implementation that supports them (only some
hacky experimentational code, which however, does not yet write the
proper bitstream to indicate floats).
JPEG XR *also* includes floating point, half float and single precision.
However, it is unable to compress single precision in a lossless way,
unlike JPEG2000.
As you state fully correctly, TIFF and EXR are the other candidates.
TIFF does not officially support half-float to my very knowledge, but it
is easy to "drill it up" and misuse its tags to express such data.
> And only EXR and PW do
> half-precision floats I believe. Also when I start to do 7-band
> infraband compression-tests (like in 5 years maybe :-D) there are not
> much systems that can do 7 planes. I was hoping I get N-dimensional KLT
> working. Anyway maybe PNG can do 7 planes too.
JPEG2000 and JPEG XR also do. The former because it is fairly generic
anyhow, and the latter through the N-channel "pixel format". JPEG 2000
is "limited" to 16383 channels, JPEG XR to 15 (which should be
sufficient for most, but not all applications).
Greetings,
Thomas
Niels Fröhling
>> is GraLIC known to perform worse on them or you just didn't check?
>
> Didn't check because the goal was to minimize compressed size, not the
> average bpp
Both units express the same in my results, they have just different magnitudes.
I do not "sum(bpp) / num_results", I do "sum(pixels * bpp) / num_pixels".
There are ways to rank compressors via standard-deviation, but then it'd be more
politics than math, if the compressor sucks badly on one of the 500 images it's
completely hidden away.
Ciao
Niels
Niels Fröhling
> That, plus the JPEG test suite (partially from the Waterloo test set,
> and some other classics used for JPEG testing).
The results with your name are the grayscale pictures you talk about. areal2,
bike.bw, texture etc. I didn't create a sub-corpus with grayscale versions of
the Honolulu pictures. Maybe I should?
Ciao
Niels
Alex Ratushnyak
> conference. Both high-class, high-value conferences with the right
> people to talk to.
The article I was talking about was never intended for a scientific
conference. 1/3 of it describes in layman's terms my approach (core
principles, the strategy). GraLIC, LPAQ, paq8hp-may2009 try to follow
those principles. I was asked to write in layman's terms, as you can
see here:
http://groups.google.com/group/hutter-prize/browse_thread/thread/e89443b54165caef
The second 1/3 shares some thoughts on applications other than data
compression, and only the last 1/3 contains some technical ideas.
By the way, the link to the demo version in the first message of this
thread is no longer valid, the Windows 32-bit executable is
downloadable here:
http://encode.dreamhosters.com/attachment.php?attachmentid=1264&d=1271744418
and here:
http://forum.compression.ru/download/file.php?id=8 (same file, other
site)
Niels Fröhling
> Update: In JPEG2000, we planned floating point for part-11, but since
> nobody cared for a long time, this got delayed. Now in the meantime, we
> did get *some* interest, and floating point will be (or actually, is
> under standardization) retro-fit into part-2 now that we know how to do
> it "right". JPEG2000 floating point compression will be fairly generic
> and will be able to express a wide selection of possible floating point
> encodings, amongst which you'll find well-known ones like IEEE single
> precision and OpenGL "Half-Float". Thus, both will be supported. There
> is currently not yet an implementation that supports them (only some
> hacky experimentational code, which however, does not yet write the
> proper bitstream to indicate floats).
That's a good development. I've read a paper about 3D-mesh compression which
uses wavelets for vertex-compression. Haven't really focused on it. Did you
consult floating-point compression use-cases to aquire generality? I suspect
images are the least occuring fp-data.
> JPEG XR *also* includes floating point, half float and single precision.
> However, it is unable to compress single precision in a lossless way,
> unlike JPEG2000.
Uh, how do you feed it? I created a PHM-format for NetPBM (Portable-Half-Map)
with "Ph" instead of "Pf". That's streightforward, but as long as EXR appears to
be the only reliable neutral container, and no compressor really does support
EXR, it's kind of nasty to be forced to write interfaces prior to use. And for
closed-source projects ... let's not talk about that. :^)
> As you state fully correctly, TIFF and EXR are the other candidates.
> TIFF does not officially support half-float to my very knowledge, but it
> is easy to "drill it up" and misuse its tags to express such data.
>
>> And only EXR and PW do half-precision floats I believe. Also when I
>> start to do 7-band infraband compression-tests (like in 5 years maybe
>> :-D) there are not much systems that can do 7 planes. I was hoping I
>> get N-dimensional KLT working. Anyway maybe PNG can do 7 planes too.
>
> JPEG2000 and JPEG XR also do. The former because it is fairly generic
> anyhow, and the latter through the N-channel "pixel format". JPEG 2000
> is "limited" to 16383 channels, JPEG XR to 15 (which should be
> sufficient for most, but not all applications).
The problem is always the IO, I still don't know how to exchange 7-plane data.
It's possible to use PNM P5s and use the page-feature (a file contains a much
planes as filesize/area), it's an official specs, but who cares of the
hobby-programmers. Not even Irfanview handles it. And it's one of the few
programs supporting pages (for TIFF and DjVu for example).
Ciao
Niels
Thomas Richter
> Thomas Richter wrote:
>
>> Update: In JPEG2000, we planned floating point for part-11, but since
>> nobody cared for a long time, this got delayed. Now in the meantime, we
>> did get *some* interest, and floating point will be (or actually, is
>> under standardization) retro-fit into part-2 now that we know how to do
>> it "right". JPEG2000 floating point compression will be fairly generic
>> and will be able to express a wide selection of possible floating point
>> encodings, amongst which you'll find well-known ones like IEEE single
>> precision and OpenGL "Half-Float". Thus, both will be supported. There
>> is currently not yet an implementation that supports them (only some
>> hacky experimentational code, which however, does not yet write the
>> proper bitstream to indicate floats).
>
> That's a good development. I've read a paper about 3D-mesh compression
> which uses wavelets for vertex-compression. Haven't really focused on
> it. Did you consult floating-point compression use-cases to aquire
> generality? I suspect images are the least occuring fp-data.
I considered HDR images as use case, for such applications the mapping
between ints and floats used in the code is provably optimal. Funny
enough, "casting" is "almost correct" except for sign handling. It is a
half-logarithmic map that fits nicely to Weber's law of eye sensitivity,
and the J2K rate-allocation minimizes the mean-square-relative-error
under this map.
Other applications might be medical or geodata. For such data, the map
is of course not ideal.
>> JPEG XR *also* includes floating point, half float and single precision.
>> However, it is unable to compress single precision in a lossless way,
>> unlike JPEG2000.
>
> Uh, how do you feed it? I created a PHM-format for NetPBM
> (Portable-Half-Map) with "Ph" instead of "Pf". That's streightforward,
> but as long as EXR appears to be the only reliable neutral container,
> and no compressor really does support EXR, it's kind of nasty to be
> forced to write interfaces prior to use. And for closed-source projects
> ... let's not talk about that. :^)
You feed it with TIFF, set the sample format to "floating point" and the
bits per sample to 16. It is not exactly valid tiff, but it expresses
the intent. pfm is not able to express 16bpp float, unfortunately.
Besides tiff, the JPEG committee "testing format" PGX includes support
(now), but there is not a toolchain like netpbm that supports this
format (except difftest_ng).
>> JPEG2000 and JPEG XR also do. The former because it is fairly generic
>> anyhow, and the latter through the N-channel "pixel format". JPEG 2000
>> is "limited" to 16383 channels, JPEG XR to 15 (which should be
>> sufficient for most, but not all applications).
>
> The problem is always the IO, I still don't know how to exchange
> 7-plane data.
PGX. Obviously. (-; TIFF can do this as well, likely.
> It's possible to use PNM P5s and use the page-feature (a
> file contains a much planes as filesize/area), it's an official specs,
> but who cares of the hobby-programmers. Not even Irfanview handles it.
> And it's one of the few programs supporting pages (for TIFF and DjVu for
> example).
Hmm, that I've never heard about. How does that work?
Greetings,
Thomas
Niels Fröhling
>> Uh, I guess I fixed that too. I had a lot of nice surprises and
>> adventures when I started making the 16bit pipeline.
>
> Any chance getting the source of the fixed version? I guess I could fix
> it myself, but I'm a lazy guy. (-;
Ah, let me see, JPEG is the only pending 16bit coder to test, so let me just
get into it and I'm sending you the diff.
BTW: you got any 16bit coders in mind besides JPEG, JPEG-XR, JPEG2000, LOCO,
PNG, TIFF, EXR? BMF2 can only do 16bit grey.
I also would appreciate any suggestions how to squeeze HDR (RGBE) into
JPEG2000. I believe I'm going to make all those grey-compressors compress
individuals planes (I'm too lazy to implement spectral CALIC), otherwise I just
test one compressor, that's boring.
> The question is the "scale" of the numbers, i.e. which number expresses
> maximal magnitude. In JPEG XR, 1.0 is the scale, i.e. expresses "full
> intensity" for floating point numbers. This convention has been adopted
> in JPEG 2000 now as well.
>
> difftest_ng does not yet have "mean relative error". Good to remind me,
> I'll add this -> this is equivalent to a logarithmic error.
In EXR it's also scale 1.0 with little over-/underflows, in the OpenEXR
samples images are very few with negative values, but stay below 1.0.
Hm, I'm not sure Greg (Ward) would agree with you (scale 1.0). The fun with
HDR is that they do not have a scale. They have an upper bound for the datatype.
But Greg expresses all his HDRIs in integer scales. One could think of a pixel
as exposure-accumulator, when you expose like 5 seconds you should be able to
get the according huge brightness (without clamping). That allows you to to step
through/manipulate the exposure time after the image has been made.
> 1.8. Please check your inbox.
Thanks!
>> That's a good development. I've read a paper about 3D-mesh compression
>> which uses wavelets for vertex-compression. Haven't really focused on
>> it. Did you consult floating-point compression use-cases to aquire
>> generality? I suspect images are the least occuring fp-data.
>
> I considered HDR images as use case, for such applications the mapping
> between ints and floats used in the code is provably optimal. Funny
> enough, "casting" is "almost correct" except for sign handling. It is a
> half-logarithmic map that fits nicely to Weber's law of eye sensitivity,
> and the J2K rate-allocation minimizes the mean-square-relative-error
> under this map.
Are you saying you integer-quantize "casted" floating points? If so I maybe
should give my reservations about it up and do it too ...
I also have my little reservations treating a HDR (RGBE) as 4-plane colospace
and lossy compress it. I can not entirely estimate the damage done in
RGBE-space. An error of 1 in RGB may be of magnitude (1)^127, and no way to make
it less, and error of 1 in E may be of magnitude 2^(1) on all the other channels
at once. A strict statistical signal-quality measure will run haywire with those
magnitudes.
On the other hand, I guess when the projection-space (range) is really large,
there is no big deal with large errors (larger than with 8bit bytes) as it's
relative more or less the same (1 in 256 <-> 256 in 65536 <-> 1^500 in 256^500).
Have to get a better feeling with those huge numbers for lossy quantities.
> Other applications might be medical or geodata. For such data, the map
> is of course not ideal.
Hm. Would be nice to have normal-compression in JPEG2000.
> You feed it with TIFF, set the sample format to "floating point" and the
> bits per sample to 16. It is not exactly valid tiff, but it expresses
> the intent. pfm is not able to express 16bpp float, unfortunately.
Hehe, same as I did with PNM, logic extension of the formats generality.
"Pf"/"PF" are the heads for fp-pnm, I just made "Ph"/"PH" up. Same with maxval,
I support maxvals upto 2^32, and read the PNMs as 32bit longs.
Prophet and mountain, he. ;^)
> Besides tiff, the JPEG committee "testing format" PGX includes support
> (now), but there is not a toolchain like netpbm that supports this
> format (except difftest_ng).
As long as it's raw and supporting variable planes and datatypes, would be
just fine. For some coder I have to point to raw data and simply do
calc(filelength - width * height * sizeof(datatype)) in the bash to get it, if
PGX can do that I'll add it.
>> It's possible to use PNM P5s and use the page-feature (a file contains
>> a much planes as filesize/area), it's an official specs, but who cares
>> of the hobby-programmers. Not even Irfanview handles it. And it's one
>> of the few programs supporting pages (for TIFF and DjVu for example).
>
> Hmm, that I've never heard about. How does that work?
Per definition any excess data (after width * height * sizeof(datattype)) in a
PNM is another image of the same configuration and so on. That works for all
PNM-types (P1-P6/Pf, ASCII or binary). You read the file as long as you have
data. In theory the interpretation is up to you, so you even may have animations
in a PNM, when you store consecutive frames. As you can annotate your PNMs you
can do this:
P6
100 200
65534
# colorspace: YCC
# frame: 1
...0x...
# frame: 2
# resync: 0.02 ms
...0x...
And so on. In some way it's a raw version of TIFF, tags eq. comments. Of course
there is no "comment registry and standardization".
I also just read after google search, that you can change headers inbetween:
P6
100 200
65534
...0x...
P6
200 100
65532
...0x...
Is a valid PNM-file and makes this: "cat *.ppm >merged.ppm" possible.
Ciao
Niels
Thomas Richter
> Thomas Richter wrote:
>
> >> Uh, I guess I fixed that too. I had a lot of nice surprises and
> >> adventures when I started making the 16bit pipeline.
> >
> > Any chance getting the source of the fixed version? I guess I could fix
> > it myself, but I'm a lazy guy. (-;
>
> Ah, let me see, JPEG is the only pending 16bit coder to test, so let me
> just get into it and I'm sending you the diff.
Thanks, would be appreciated!
> BTW: you got any 16bit coders in mind besides JPEG, JPEG-XR, JPEG2000,
> LOCO, PNG, TIFF, EXR? BMF2 can only do 16bit grey.
Nope, that's my list as well. Except that TIFF is hardly a compression
algorithm, rather a container for various compressors.
> I also would appreciate any suggestions how to squeeze HDR (RGBE) into
> JPEG2000. I believe I'm going to make all those grey-compressors
> compress individuals planes (I'm too lazy to implement spectral CALIC),
> otherwise I just test one compressor, that's boring.
Well, the current AMD 3 I'm working on will include provisions to encode
RGBE, just that I labeled them as "not recommended". The reason is that
JPEG2000 does not provide good means to preprocess this data to
something well compressible. The recommended way to encode HDR images is
to first convert them into separate floating point channels, and then
encode these. For RGBE, you would have four channels, but the color
channels contain non-continuous data (the data jumps whenever the
exponent channel changes) -> pretty bad for compression.
JPEG XR includes a pre-processor which first converts RGBE to float, and
that is not part of JPEG 2000, nor do I really see the necessity. RGBE
is not a very good format to begin with, so avoid it.
Sorry that I don't have an implementation for that yet - only some
hacked-up version that was good enough to verify the ideas.
> > The question is the "scale" of the numbers, i.e. which number expresses
> > maximal magnitude. In JPEG XR, 1.0 is the scale, i.e. expresses "full
> > intensity" for floating point numbers. This convention has been adopted
> > in JPEG 2000 now as well.
> >
> > difftest_ng does not yet have "mean relative error". Good to remind me,
> > I'll add this -> this is equivalent to a logarithmic error.
>
> In EXR it's also scale 1.0 with little over-/underflows, in the OpenEXR
> samples images are very few with negative values, but stay below 1.0.
> Hm, I'm not sure Greg (Ward) would agree with you (scale 1.0).
It is a "nominal scale" in the sense of how "maximal intensity" is
expressed, but of course you can represent samples that go beyond this
scale. The question is here rather how to represent color.
> The fun
> with HDR is that they do not have a scale. They have an upper bound for
> the datatype. But Greg expresses all his HDRIs in integer scales. One
> could think of a pixel as exposure-accumulator, when you expose like 5
> seconds you should be able to get the according huge brightness (without
> clamping). That allows you to to step through/manipulate the exposure
> time after the image has been made.
Sure enough, but you still need some "nominal" white and black point to
express the dimensions of the samples you recorded. This is what the
scale is good for, nothing else. Anyhow, it is up to the implementation
to interpret the samples - and I wanted to design this floating point
stuff in a way that it is compatible to JPEG XR. As a side effect, we'll
also get better file format for XR than the current TIFF-tag based mess,
something the Japanese folks requested.
>> I considered HDR images as use case, for such applications the mapping
>> between ints and floats used in the code is provably optimal. Funny
>> enough, "casting" is "almost correct" except for sign handling. It is a
>> half-logarithmic map that fits nicely to Weber's law of eye sensitivity,
>> and the J2K rate-allocation minimizes the mean-square-relative-error
>> under this map.
>
> Are you saying you integer-quantize "casted" floating points? If so I
> maybe should give my reservations about it up and do it too ...
It is "almost" casting in the sense that you need to represent negative
samples slightly differently - you need to adjust the sign-magnitude
representation of floating point to a two's complement representation;
which then works fine.
The reason why this is then a "good" way how to compress floating point
is threefold:
*) First, it can be shown that this type of casting is a
half-logarithmic map, which fits nicely to the almost-logarithmic
eye-sensitivity,
*) second, a mean-square error optimal code + casting map will give you
a mean-relative square error compressor for the floating point data
(nice enough again),
*) third, this mean relative square error is approximately identical to
square error in the log-domain, which is again approximately identical
to the "perceptive" error due to Weber's law, and which is again
approximately identical to a one-point limit of SSIM.
Thus, in the end, everything falls on the feet: SSIM approx. log error
approx. error in the Weber's domain approx. MSE optimal coding plus
casting map. Nice.
> I also have my little reservations treating a HDR (RGBE) as 4-plane
> colospace and lossy compress it. I can not entirely estimate the damage
> done in RGBE-space. An error of 1 in RGB may be of magnitude (1)^127,
> and no way to make it less, and error of 1 in E may be of magnitude
> 2^(1) on all the other channels at once. A strict statistical
> signal-quality measure will run haywire with those magnitudes.
It doesn't give rise to a good error measure, or rather, it is very hard
to control the image domain error due to the quantization domain error;
the option XR took is to first convert RGBE to a three-component float,
and then compress that, allowing you better control of the error.
> On the other hand, I guess when the projection-space (range) is really
> large, there is no big deal with large errors (larger than with 8bit
> bytes) as it's relative more or less the same (1 in 256 <-> 256 in 65536
> <-> 1^500 in 256^500).
> Have to get a better feeling with those huge numbers for lossy quantities.
The question is rather what the application for such floating point
formats is. If the application is to express HDR images, and then deploy
a tone mapping curve that fits approximately to the eye-sensitivity, the
casting approach = logarithmic map approach is nice. If the idea is
rather to view luminance windows from the image as you do in X-Ray
images (medical doctors tend to look at 8bpp luminance windows from
10-16bpp data), then a *linear* error distribution (rather than a
logarithmic error) would be better, and then you need a different
protocol. Probably, don't express it in float in first case, but rather
in a fixpoint or integer format.
>> Other applications might be medical or geodata. For such data, the map
>> is of course not ideal.
>
> Hm. Would be nice to have normal-compression in JPEG2000.
What do you mean "normal"? In the sense that the absolute error (instead
of the relative error) can be controlled for floating point data? Well,
there is no floating point format in first place which would you grant
that. They are all half-logarithmic.
People experimented with compressing mantissa and exponent separately,
but this is a *very bad* idea.
>> You feed it with TIFF, set the sample format to "floating point" and the
>> bits per sample to 16. It is not exactly valid tiff, but it expresses
>> the intent. pfm is not able to express 16bpp float, unfortunately.
>
> Hehe, same as I did with PNM, logic extension of the formats
> generality. "Pf"/"PF" are the heads for fp-pnm, I just made "Ph"/"PH"
> up. Same with maxval, I support maxvals upto 2^32, and read the PNMs as
> 32bit longs.
Yup, I understand. I don't support these, but then require users to go
to PGX ("almost raw") which includes (now) half-float, float, and up to
32bpp.
> Prophet and mountain, he. ;^)
Sure. Except that I rather touch "our own standard", which is PGX.
>> Besides tiff, the JPEG committee "testing format" PGX includes support
>> (now), but there is not a toolchain like netpbm that supports this
>> format (except difftest_ng).
>
> As long as it's raw and supporting variable planes and datatypes, would
> be just fine.
Sure, that's what it does. Raw, plus one additional header file per
plane, plus one "index" or "directory" file.
> For some coder I have to point to raw data and simply do
> calc(filelength - width * height * sizeof(datatype)) in the bash to get
> it, if PGX can do that I'll add it.
Sure.
>>> It's possible to use PNM P5s and use the page-feature (a file contains
>>> a much planes as filesize/area), it's an official specs, but who cares
>>> of the hobby-programmers. Not even Irfanview handles it. And it's one
>>> of the few programs supporting pages (for TIFF and DjVu for example).
>>
>> Hmm, that I've never heard about. How does that work?
>
> Per definition any excess data (after width * height *
> sizeof(datattype)) in a PNM is another image of the same configuration
> and so on. That works for all PNM-types (P1-P6/Pf, ASCII or binary). You
> read the file as long as you have data. In theory the interpretation is
> up to you, so you even may have animations in a PNM, when you store
> consecutive frames. As you can annotate your PNMs you can do this:
>
> P6
> 100 200
> 65534
> # colorspace: YCC
> # frame: 1
> ...0x...
> # frame: 2
> # resync: 0.02 ms
> ...0x...
>
> And so on. In some way it's a raw version of TIFF, tags eq. comments. Of
> course there is no "comment registry and standardization".
Ah, I see. Just concatenated PNMs.
> I also just read after google search, that you can change headers
> inbetween:
>
> P6
> 100 200
> 65534
> ...0x...
> P6
> 200 100
> 65532
> ...0x...
>
> Is a valid PNM-file and makes this: "cat *.ppm >merged.ppm" possible.
Yup, understood.
So long,
Thomas