| |
 |
|
|
Science Forum Index » Compression Forum » GLICBAWLS for 16 bit graylevel PGMs
Page 1 of 1
|
| Author |
Message |
| Antonio Pasini |
 Posted: Sat Apr 12, 2008 10:05 am |
|
|
|
Guest
|
Is there an implementation of GLICBAWLS that works well for 16 bit/pixel
graylevel PGM files ?
I cannot recompile from the sources under WinXP/VC9 (from here:
http://web.archive.org/web/20020604145417/http://byron.csse.monash.edu.au/glicbawls/index.html)
Under Ubuntu 7.10,last GCC, it works.
I can decode the "lenna.glic" image correctly.
On a 12 bpp PGM image, instead, it decodes correctly just the first half
of the image, then all goes black.
Anyone has done some tests at 12/16 bpp with this ? |
|
|
| Back to top |
|
| Guest |
| Posted: Mon Apr 14, 2008 9:48 pm |
|
|
|
|
Quote: Is there an implementation of GLICBAWLS that works well for 16 bit/pixel
graylevel PGM files ?
I cannot recompile from the sources under WinXP/VC9 (from here:http://web.archive.org/web/20020604145417/http://byron.csse.monash.ed...)
This implementation of the algorithm is a _FUN_-project, besides that
fun he had to create this minimal-size code, I'm not so sure if Bernd
would find it so funny if it is being used in a serious manner. And
speaking of serious, I should suggest not to use code that can't be
understood, thus can't be extended, thus can't be fixed if it breaks
under some libc or kernel; maybe handing over to a client a possible
trojan (just from the principle, I don't imply there is one inside),
worst to a friend, even worst to yourself.
That one implementation is not to be used, really.
Quote: Under Ubuntu 7.10,last GCC, it works.
I can decode the "lenna.glic" image correctly.
On a 12 bpp PGM image, instead, it decodes correctly just the first half
of the image, then all goes black.
Anyone has done some tests at 12/16 bpp with this ?
The algorithm itself is simple enough to be implemented by yourself
in 15 minutes if you allready have an LS-solver. There are enough out
there BTW. You will find out allmost immediatly, that it's too slow to
be used seriously (GLICBALWS uses the _whole_ previous picture for
finding the matrix-solution), or you implement if for GPUs and make a
fat graphics-board a requirement.
The was some little interest in this kind of algorithm in the
scientific comunity, for using it as some sort of upper-bound for
compressing [greyscale] images. The is a revision of the algorithm
(which includes readable code, for learning, and no decompressor-
source  from Xin Li called "Edge-Directed Prediction for Lossless
Compression of Natural Images". This is a really useable one, but ...
it's not better than CALIC.
While the time CALIC was developed much scientists believed the
algorithm was way to complex (and so then too slow) that CALIC can be
used in a serious way for storing pictures, they have to be proven
wrong by time.
CALIC still is one of the most amazing image compressors, because it
is actually *simple*, much simpler than the other algorithms around,
that produce amazing compression results, while actually compressing
extremely well. GLICBAWLS and CALIC have a compression ratio of ca.
1:1.1 (CALIC is roughly 1.1 times the size of the GLICBAWLS), but an
runtime ratio of ca. 15000:1 (GLICBAWLS is fiveteenthousand times
slower than CALIC).
So as conclusion I would suggest you to use GLICBAWLS soley as a tool
to verify effectivity, the same way as log2-order-0-entropy is used to
verify the effectivity of arithmetic coders.
Ciao
Niels |
|
|
| Back to top |
|
| Antonio Pasini |
| Posted: Tue Apr 15, 2008 12:12 pm |
|
|
|
Guest
|
Il 15/04/2008 9.48, spamtrap@adsignum.com ha scritto:
Quote: Is there an implementation of GLICBAWLS that works well for 16 bit/pixel
graylevel PGM files ?
This implementation of the algorithm is a _FUN_-project, besides that
fun he had to create this minimal-size code, I'm not so sure if Bernd
would find it so funny if it is being used in a serious manner.
Yeah, I agree; it's a almost work of art.
I'm also doing a fun project, to understand what could be done, if any
time limit is removed. I'm testing whatever I found around that I like
 . On my day job I have an interest in image compression, but I know
it's too slow for practical purposes. Nevertheless, I just wrote a note
to the author, just for curiosity.
At day job, we use much less demanding compression algorithms ("cheap"
embedded platform).
Quote: The was some little interest in this kind of algorithm in the
scientific comunity, for using it as some sort of upper-bound for
compressing [greyscale] images.
Exactly. I'm using LOCO so far as a lossless reference, but I was
curious to see what glicbawls could do.
The is a revision of the algorithm
Quote: (which includes readable code, for learning, and no decompressor-
source from Xin Li called "Edge-Directed Prediction for Lossless
Compression of Natural Images". This is a really useable one, but ...
it's not better than CALIC.
thanks for the pointer.
Quote: CALIC still is one of the most amazing image compressors, because it
is actually *simple*, much simpler than the other algorithms around,
CALIC was one at the bottom of my reading list...
Evidently, I misunderstood some papers, I was thinking it was much
slower than Glicbalws.
Thanks Niels for clarifying that to me. |
|
|
| Back to top |
|
| |
|
Page 1 of 1
All times are GMT - 5 Hours
The time now is Fri Jul 25, 2008 5:26 pm
|
|
