Re: BTPC Extension - PyramidWorkshop
- From: Thomas Richter <thor@xxxxxxxxxxxxxxxxx>
- Date: Wed, 17 May 2006 18:17:17 +0200
Hi Niels,
PSNR-wise, I suppose? Or visually? Which metric did you use? As far
as the visual quality is concerned, it might very well be with the
default settings, i.e. no "visual weighting". As far as PSNR is
concerned, "maybe", but then it would be helpful if I could run these
tests myself. I would believe that this is pretty much image dependent.
PSNR is a no good for that, it's interesting for context-free
noise-channel measurements, so it's a property of _quantity_ not
quality. I mostly look at the difference-pictures (with my eyes).
Well, let's put it like this: Everyone agrees that PSNR is bad, and
everyone uses it due the lack of agreement on anything beyond PSNR.
Visual testing is fine, but to have reproducable results, one should
try to run somewhat more objective tests. For subjective quality
testing, a couple of ITU guidelines are available, but all that implies
that more than one person must look at the images - in fact quite a lot
more than one. (-;
For objective full reference testing, a couple of propositions are available that are, well, not quite as bad as PSNR, and neither quite
as good as one might hope for. A student of mine is currently playing
with SIM. Thus, at the time being, I afraid, PSNR measurements are still
the prime tool to convince someone, even though everyone (except
marketing people maybe) know to take these results with a grain (or
possibly a bunch of) salt.
I also utilize other properties shown here:
http://pyramidworkshop.cvs.sourceforge.net/pyramidworkshop/libBTPC-0.0.0/Structures/Still/Quality.cpp?revision=1.1&view=markup
Once I found a human tuned quality measure called Psomething (I not at
home so I've to look it up later [paper & implementation]) but never
trust that too much either.
It's an open problem.
All true, but subjective testing with one person (and the author) is actually worse. (-; For example, the ITU guidelines require you to
recruit people that are *not* experts in the field. If you have more
papers available on visual metrics, I would be interested, of course.
Invent an
overly complex and slow model for a big precision arithmetic coder
and it's done. The bigger the image the better for a self-adjusting
model.
Well, I thought JPEG2000 *is* an overly complex and slow model? (-;
;^) Not so complex as mine.
No, seriously. I would believe that it is possibly time for some newer
ideas beyond pyramid coding,
It's not subband-coding. The term 'Pyramid' came from the progressive
encoding which is 'pyramidal', the same way as JPEG-2000 is
'pyramidal', but the algorithm does not have bands in the classic
definition.
maybe something in the direction of image
segmentation. Filtering/predicition methods are more or less explored, I
would believe.
Everything is about statistics in the end. :)
Entropy coding is always the last step...
Some reasons why I like the BTPC/APT so much:
------- snip -----
The strength I saw with the method is the multi-resolutional
feature (not quiet exactly, as it's not a subband-pyramid, but
comparable in the sense that the BTPC-levels are nearest-
neighbour scales of the original images whereas subbands are
filtered scales of the original image).
I took care not to remove that essencial advantage over other
compression concepts and tried to extend it further. In the
moment it's possible to:
a) encode from higher to lower resolutions
b) decode from higher to lower resolutions
c) reconstruct (predicting missing levels by predictor-
banks) non-existant lower resolution including quantizer-
step-size adaptive dithering (never adds more noise than
a quantizer may introduce)
This is also true for the frame-compression, actually I do
not reference levels in a reference-frame that are lower than
the actual.
This gives the ability to code digitalized video for example
in as much resolutions as there are levels (by simply quiting
the lower levels) this is very excellent for limited/variable
size transmition-channels.
The question that then opens is how or where you perform the
motion prediction. Or "if". The question would then be how a
motion in the image domain appears in the BPC(?) domain, if
there is such a thing.
The system may check the transfer-
speed and adjust the amount of levels send dynamically.
Also in addition it gives the ability to decode the video
in a lower resolution which is excellent for limited/variable
processing power. The system may check the decoding speed and
adjust the amount of levels being decoded.
Switching back to higher levels is only possible by reaching
key-frames (which are temporal independent), but giving the
ability to smoothly raise the number of levels instead of
coding/decoding to full resolution immediatly. And all that in
addition to variable-bitrate coding.
This is extreme well scalable, to both time-factors: transfer
and display in a really easy and fine-granulated way.
------- snap -----
BTW, I always thought about predictive wavelets:
------- snip -----
Die basische Struktur von BTPC ist progressiv, dass heisst
(in 'wavelet'isch) du bekommt erstmal nur Low-Frequenzen,
Level fuer Level dann immer Hoehere. Die Prediktion wuerde so
funktionieren, dass Du (z.B.) das Haar-Wavelet fuer das
niedrigste Frenquenz-Band errechnest (das Band ist bekannt, wird
verlusstlos abgespeichert) und mit dem naechsten Level
differenzierst (das sind dann die Fehler-Werte die quantisiert
werden), durch die Rueckbildung erlangst Du dann den
'beschaedigten' naechst hoeheren Level den Du zur Korrektur des
vorher verwendeten Wavelets benutzt usw.
------- snap -----
Well, I afraid that's still "too sketchy" to give me an idea. Of course one can describe wavelets as a "prediction" scheme where the predicition is performed by "low-passes". There are several other "X-lets" that
use similar filtering techniques (beyond the mathematical properties
of wavelets) that are "prediction techniques" in some rough sense.
So long,
Thomas
.
- Follow-Ups:
- Re: BTPC Extension - PyramidWorkshop
- From: niels . froehling
- Re: BTPC Extension - PyramidWorkshop
- From: niels . froehling
- Re: BTPC Extension - PyramidWorkshop
- References:
- [ANN] BTPC Extension - PyramidWorkshop
- From: niels . froehling
- Re: [ANN] BTPC Extension - PyramidWorkshop
- From: Thomas Richter
- Re: BTPC Extension - PyramidWorkshop
- From: niels . froehling
- Re: BTPC Extension - PyramidWorkshop
- From: niels . froehling
- Re: BTPC Extension - PyramidWorkshop
- From: Thomas Richter
- Re: BTPC Extension - PyramidWorkshop
- From: niels . froehling
- [ANN] BTPC Extension - PyramidWorkshop
- Prev by Date: Re: BTPC Extension - PyramidWorkshop
- Next by Date: Re: jj2000 jpip
- Previous by thread: Re: BTPC Extension - PyramidWorkshop
- Next by thread: Re: BTPC Extension - PyramidWorkshop
- Index(es):