[FFmpeg-devel] donation for snow

[Michael Niedermayer]

On Thu, Nov 20, 2008 at 04:23:45PM -0800, Jason Garrett-Glaser wrote:
> > Anyway, iam not trying to defend j2k or wavelets but you are hand picking
> > images and parameters to make j2k look like crap, this surely does confirm
> > that j2k can be very significantly worse than jpeg but says little about the
> > average behavior. Which may or may not be better than h264, though iam pretty
> > sure jpeg2k will perform vastly better than its predecessor jpeg on the
> > average natural image.
> 
> I would have tweaked JPEG2K much harder than I did, but the software
> didn't allow any significant changes to parameters.  I'm still looking
> for a good JPEG2K encoder that is both good quality-wise and versatile
> as x264 is, so that it can be appropriately tweaked.
> 

> As you hinted, I also strongly suspect that x264 is much better at
> encoding H.264 than that JPEG2K encoder is at encoding JPEG2K, so its
> still not an entirely fair test.  But its hard when there don't seem
> to be any good ones... and before you say "write one," if I was going
> to write one, I would write a better image format ;)

yes, i of course agree with you on all these points ...

one thing that could be done would be post processing with overcomplete
wavelets or some cyclically shifted wavelet, mplayer contains a filter for
that, similarly -vf spp=XY should help jpeg, it also might be interresting
to try the "wrong" pp like spp for j2k or h264 ...
not that i thin pp would change the difference between j2k & jpeg in this
comparission in j2ks favor ...

and last, iam curious how intra only snow does against j2k, though i dont
expect it to do much better for the kind of test image you used.

and speaking of writing better formats, i had a few ideas for a better
video codec (KLT, adaptive OBMC, intra frame MC, ...) that i should
implement ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081121/eb6163f7/attachment.pgp>