ITU-T together with the Independent Joint Photographic Expert Group
(IJG) is celebrating the twentieth anniversary of the formation of
the CCITT/ITU-T and ISO Joint Photographic Expert Group (JPEG) with
the release of an alpha version of software for a new more efficient
compression scheme. The new ITU extension to JPEG known as ITU-T
Recommendation T.851 means that compression is increased such that
images will take-up less space on people’s hard drives or digital
cameras.

The program available here <http://ftp3.itu.ch/jpeg1x/> allows users
to input image files for compression at a more efficient rate than
that currently offered. The group responsible for producing the open
source software is inviting people to test and contribute to the
development of the project.

Recently, and capitalizing on the ‘toolbox’ concept of the original
JPEG design, ITU-T approved ITU-T Rec. T.851, a royalty-free extension
that adds to T.81, more commonly known as JPEG, an alternative
compression method using so-called Q15 arithmetic coding. Q15 provides
not only higher compression ratios for stored and transmitted images,
but - compared to the original arithmetic coding in JPEG - also lower
latency for compressing and displaying images. T.851 also extends the
color precision of JPEG to maximum 16 bits per color component, which
is seen as essential in applications such as medical imaging,
professional photography and high quality printing.

Founded in 1986 by its parent bodies, the then ITU CCITT Study Group
VIII and the ISO/TC97/SC2/WG8 group, JPEG continues today under the
auspices of ISO/IEC JTC1 SC29/WG1 and ITU-T Study Group 16. The most
famous product of JPEG was ITU-T Recommendation T.81 | ISO/IEC 10918-1,
which specifies a process for digital compression and coding of
continuous-tone still images, and is more commonly known by the name
of the group, JPEG. This is the most used format for storing and
transmitting photographs on the Internet, in digital photography and
in many other image compression applications, and it was approved in
1992 first by ITU-T (then CCITT) and later by ISO/IEC.

Work on the new compression algorithm was started in 2004 by ITU-T
Study Group 16. The aim was to allow users to take advantage of recent
technological advances, with the addition to the JPEG suite of an
alternative, royalty free coder that would allow even better image
compression efficiency and lower latency. The successful completion
of this first phase of the work resulted in the publication of the
specification ITU-T Rec. T.851 after approval in September 2005.
Experts from SG 16 say to stay tuned for further developments.

Regards
Guido Vollbeding
Organizer Independent JPEG Group

Sorry, forgot the source:

  http://www.itu.int/ITU-T/newslog/20+Years+Of+JPEG+Celebrated+With+Sof...

Regards
Guido Vollbeding
Organizer Independent JPEG Group

Interesting! (I cant honestly say a 10% improvement is smashing, now can
I?). The PDF however is not extremely clear. Are the various results at
equal Q or equal PSNR?

Cheers,
--
Michel Bardiaux
R&D Director
T +32 [0] 2 790 29 41
F +32 [0] 2 790 29 02
E mailto:mbardi...@mediaxim.be

Mediaxim NV/SA
Vorstlaan 191 Boulevard du Souverain
Brussel 1160 Bruxelles
http://www.mediaxim.com/

The image quality is exactly the same in all cases, since the difference
is only in the final lossless entropy coding stage.
You can losslessly transcode any given JPEG file with the provided
patched "jpegtran" to the new arithmetic variant (option "-arithmetic")
and vice versa, without any change in image quality.

But notice the last paragraph:  This is only the *first* phase result,
and "Experts from SG 16 say to stay tuned for further developments."!

You can see part of these "further developments" in my contributed
proposal, latest Revision 3:

  http://jpegclub.org/temp/

  direct: http://jpegclub.org/temp/ITU-T-JPEG-Plus-Proposal_R3.doc

Regards
Guido

I'm confused; I was under the impression that there were patent issues
surrounding arithmetic coding and that's why huffman was used.  If
that's the case, how can we switch to arithmetic coding now?  How does
the new method differ from the one that had patent issues?

More importantly, why would I want to start doing this *now*?  None of
my software on any platform can read these as of today.

Jim, the main objective of introducing the *new* arithmetic coding
method with T.851 is to get away with the patent issues!
T.851 defines an *alternative* arithmetic coder (Q15) for use with JPEG.
JPEG always had an arithmetic coder (QM) - but it was not used due to
patent encumbrance.  One of the main objectives for the T.851
introduction was to provide an absolutely free arithmetic coder with Q15.
It removes some of the patented QM features (such as conditional exchange)
and compensates for compression performance with use of an alternative
probability estimation table ("Fast Attack") and bit-stuffing technique
instead of byte-stuffing (also regarding the latency issue).

The T.851 Q15 coder is freed from third-party patents beyond some still
owned by IBM.  See also notice on http://ftp3.itu.ch/jpeg1x/ .
I have met with Joan Mitchell from IBM at the Geneva meeting, and she
showed me with all trust and confidence that IBM is really "playing nice"
and making it really free, and furthermore that the relevant IBM patents
expire anyway next year at the latest!
My impression was that if I can trust anyone from those folks, then Joan
Mitchell at most.  There is similar experience from Tom Lane with her in
the past.

So I'm confident that we can safely go with this result.

Most of the software uses the free IJG library for JPEG processing, so
as soon as it is available with one of the next IJG releases, it can
be commonly used.

Unfortunately, the given Q15 implementation is not yet stable enough for
public application.  It requires the same level of stability as my initial
QM implementation to be included in a public IJG package.  Only when this
is achieved will there be no barrier for common application.

So far I did only rough bug fixing of the given code patch, and I have
added the progressive mode support.  There must be done more tweaking
in the next time to improve the code.

The reason that we come up *now* with the message is (a) to celebrate the
twentieth anniversary of JPEG, and (b) as a response to recent claims
from Microsoft that they could beat JPEG.  They cannot!

Regards
Guido Vollbeding
Organizer Independent JPEG Group

Since when is Q15 "absolutely free"? It isn't. Of course do we have
patents on Q15, but luckely these patents are held by IBM and IBM grants
royality free access to the patents for international standards. This is
different for MQ and QM coder where additional relevant patents exist
(IIRC, the MSB/LSB interchange is a Mitsubishi patent). That means, I
still cannot use Q15 for proprietry products - which would be my
definition of "free". That doesn't mean things are bad - they aren't -
just that the statement is incorrect.

As far as IBM is concerned, and as far as Joan is concerned, I'm feeling
confident that things will work out nicely. Interesting enough, the
reason why QM didn't became accepted is partly because noone thrusted
IBM back then. And, as a historic side remark, the one reason why IBM
was back then even willing to give the QM patents away was that Pegasus
was offering the ELS-coder as arithmetic coder option.

Though it would still not be JPEG, it's a different standard - to be
precise an ITU-recommendation - based on JPEG resp. the identical
ITU-recommendation. That doesn't mean much, of course, it's just a
different number and a different organization. It will depend on the
market whether it will be accepted or not. I don't know, but we will
see. No speculation from my place.

Beating JPEG is actually easy. The standard is a bit old, and an overall
renovation would be suitable. Back in the old days, a couple of
compromises had to be made to make it suitable for the hardware back
then. The question really is, why drilling up an old working horse that
does the job fine by introducing marginal improvements that generate
bitstreams that are not backwards-compatible if instead we can throw it
away and start from scratch.

I haven't compared the Q15 implementation with the QM implementation, so
I cannot present numbers right now. Given that both are approximately
comparable, the mentioned improvement isn't able to match with even
existing standards today, as measurements on QM show. So the question
really is, why do that? However, I'm with the ITU in the sense that I
see no point in *not* defining a standard, so let's see how it goes.

I also haven't compared with the new Microsoft code yet, I just don't
have it. A new round of comparisons would really be suitable and I would
be curious to see the results with Microsoft's code. One thing for sure,
the 50% higher compression than JPEG as advertised by M$ is definitely
marketing hype. I would belive it's better than JPEG-1 (no blocking),
maybe it's better than JPEG2000, it would require testing to make
statements. Statements like "They cannot!" *at this time* come
definitely too early and are as much marketing hype as the hot air from
Redmond.

So long,
        Thomas

You can use Q15 as part of that ITU Recommendation for any kind of products
you want!  That is noted on http://ftp3.itu.ch/jpeg1x/ .

It is the *real* JPEG organization, based on the *real* JPEG standard!
It is the *ISO* part of JPEG which went wrong and got corrupted and created
a totally different animal "JPEG-2000" which has nothing to do with the
original JPEG standard!
J2K is a totally different technique, they just were clever enough to
apply the name "JPEG" to it because JPEG was so successful.  They could do
this because at that time (in the mid and late ninetees) the original JPEG
inventors had largely left the JPEG committee to do other things, and there
was a "vacuum" to fill.  So basically JPEG-2000 is a hoax.

Wrong!  There were several attempts in the past to beat JPEG, and they all
have failed, and they *must* fail, because none of the challengers have
understood the basic JPEG (DCT) fundamentals.

Thomas, sorry, but here you show your complete ignorance!
The opposite of what you say is true:  The original JPEG DCT approach is
the *only* appropriate solution for image coding!  Of course you can't
recognize this because you have not understood or ignore the basic DCT
fundamentals.
You will never achieve any advance without basic understanding of DCT
fundamentals, and that's why all those attempts must fail.
And of course WE WILL be backwards-compatible:  our new decoders will
seamlessly read "old" JPEG files without any problem, the encoders can
optionally output old streams, or you can transcode between different
flavors.
Backwards-compatibility is exactly what YOU broke with your JPEG-2000
thing!

Thomas, it is said in the message:  This is only the *first* phase result,
and "Experts from SG 16 say to stay tuned for further developments."!

These "further developments" will be more important than that first result!
You can find something about this in my contributed proposal, latest
Revision 3:

  http://jpegclub.org/temp/

  direct: http://jpegclub.org/temp/ITU-T-JPEG-Plus-Proposal_R3.doc

But of course if you read this, and if you would understand it, then you
could not continue to propagate your misleading statements.
So better keep on ignoring it if you want to maintain your opinion.

I have it!
But I can't tell about the details here because I had to sign kind of
non-disclosure agreements.

JPEG-2000 is obsolete and will lose even more ground (if it ever had any)
after this WM Photo attempt, because WMP is more related to traditional
JPEG technology than JPEG-2000/Wavelets.
The developers of this WM Photo are, similar to JPEG-2000 proponents and
other folks, not aware of the basic DCT properties for image coding.
Therefore they *cannot* beat our actual JPEG-Plus approach!
The original JPEG-1 was only an initial approach.  They found the right
technique (DCT), rather by accident so to say, but they had no basic
understanding of DCT fundamentals, and thus couldn't exploit all of its
potential.
That is exactly what we do now with our JPEG-Plus approach:
For the first time present an appropriate exploitation of basic DCT
properties and thus approach its full potential!
And I can assure you that our results are superior to anything what
you have seen so far.  As said:  Stay tuned...

Regards
Guido Vollbeding
Organizer Independent JPEG Group

So it's not. Thanks. Read the "as part of that...". Not that I would
care, that's wonderful! It's just not "free". Please be very careful
what you say.

JPEG is the name ISO gremium. What you've here in the ITU is of course
the collection of the original JPEG-1 developers and engineers we all
accept and salute to. Noone doubts that they've done a good job. But
that still doesn't make them the "JPEG".

Still no measurements? Wierd enough. You should have contact to Mr.
Sebestyen, don't you? Didn't he show me the measurements on the ITU test
corpse? I wonder why not? Have he told you about the aparent IJG loss at
high bitrates in the PSNR plot?

Interesting. So why do I find so many other interesting developments,
even here in this group, that use other ideas that also work fine and
even better than JPEG-1.

"Ignorance" is the property of not being able to listen to opinions
beyond the own one. I've never been ignorant against new developments as
I really try to estimate their quality. Something you have never been
able to. I still lack to see any comparison or measurement you've made.
Why is this so? Why are you so "ignorant", in this meaning of the word.

I'm not trying to convince you of anything. All I'm trying is getting
some facts out of you. Isn't that exactly the meaning of "ignorance"
when one closes his eyes even though measurable/repeatable data speaks
against one?

No, of course not. I'm doing mathematics for >10 years and still haven't
learned Fourier. Beyond any "basics", the final decision about the
quality of an idea should be found in experiments, I'm physicist enough
to use this as ultima ratio. And it's exactly this experimental approach
that's the basics of all sciences. So why do you ignore to measure?
Afraid of the result?

And I still can't read it with existing codecs. That's quite a
difference. It will depend on how successful the resulting standard will
be. I don't know.

It's a different standard. So what? Why's that so bad? In the same
sense, there's nothing bad about the ITU approach. Keep on working on
this, please. We need engaged people. But stop making wrong claims.
That's simply not JPEG-1. And again, that doesn't make it better or
worse at all.

Thanks, I know this for quite a while. I'm always doing my homeworks,
you should know this. (-: Just a comment: To make this acceptable as a
standard, reduce the "Ego" part in this writing, the style is
unacceptable. Make it technical, not political. I made a long list of
comments on this. Most of the comments were: "Nice idea, please backup
by data." In ISO, this is called "core experiments". You should run
some. Please also run JPEG2000 in parallel. Not to convince you, but
just to get an idea about where you are.

*Where* did I propagade anything? Since when do I marketing?

Hmm. Does this imply that measurements cannot be published? This would
be pretty unprofessional. If your NDA would allow, please publish
measurements on this. Code isn't probably even not required.

If they *cannot* in the same sense JPEG2000 *cannot*? Wierd. Why do my
charts look so different than your opinion? Where's the problem? If you
don't like my plots, what's so hard making your own? If you don't thrust
my measurement process, why don't run your own? Is there anything
substantial you could add to backup your claim? Where's the meat?
Where's the data?

Not quite. The JPEG+ approach (please do not use this name! It is
definitely *NOT* JPEG, or possibly "not yet") still lacks some
flexibility that would be useful. I see that you understood parts of the
canvas system in JPEG2000 (good, useful), but parts of why the canvas
system differs from the sample/image system seems to be missing there.
JPEG-1 made the mistake to confuse the canvas system with the sample
system, this could be nicely avoided once you're trying your own approach.

The scaling system is nice, but probably not optimal (beyond your claims
being so, the resulting cosine subsampling filters created by the DCT is
not the "best" transformation for that, and I know my mathematics.)

I always will, Guido. You should know me, I'm doing my homeworks.

A side remark: You seem to believe you're talking to a strong JPEG2000
proponent and your personal enemy, for whatever reason that might be.
I'm neither the first, nor the second. I'm an engineering guy who's
interested in the developments. Why do you believe that I - as a member
of JPEG - must be an enemy of JPEG-1? I wonder why you're so badly
informed, you should know my position from Mr. Sebestyen. If you don't
believe me, ask him.

If I'm the enemy of something, then that's unscientific approaches to
problems. That is, generating a lot of hot air. I don't like marketing
folks. Why do you confuse me with these guys? Why do you make *exactly*
the same mistakes than these guys? That is, make claims, works,
"BrandX is better Conglom-O" Better in which sense? Measured how?

In other words, I've no doubt that JPEG2000 can be beaten, but for that,
please don't underestimate what you've do to. You need not only be a bit
smarter concerning the choice of the technology (be open!, and I do not
necessarely meaning wavelets!) you also need to be a bit smarter
concerning ...

read more »

Dogma.

Dogma.

Image compression shouldn't work on dogma, it should work on metrics.

He didn't question whether your (new) decoders would be backwards
compatible (with old streams), he questioned, or asserted the
negative, whether the (new) bitstreams would be backward compatible
(with old decoders). Your missing of the point was legendary.

Phil
--
The man who is always worrying about whether or not his soul would be
damned generally has a soul that isn't worth a damn.
-- Oliver Wendell Holmes, Sr. (1809-1894), American physician and writer

news:4eq6dmF1c5aunU1@news.dfncis.de...

<snip>

<snip>

Thomas, funny you should mention the ELS Coder.   Pegasus offered this to
the "Independent JPEG Group" in 1997 and they wanted no part of arithmetic
coding then, when it would have really made a difference.  Now, no chance.
Just no way to get this into Internet Explorer now, and without that and
other third party viewing support, there will be no adoption.  Sorry Guido,
this boat sailed a long time ago.

Snippets from this news group in 1997:

Sept. 26, 1997:

"We offer a DCT coder that uses our arithmetic coder instead of
huffman, yielding as much as 14% LOSSLESS size improvement over jpeg,
and LOSSLESS conversion back and forth.  We have customers that need
that extra file savings and are willing to pay for it.  (ePIC image
compression)  People are not lined up at our door, however.  Our entropy
coder is offered to the world license/royalty free though, if anyone
else wants to use it. "

October 9, 1997:

"Tom, I believe (I have not asked any
of our scientists) that "all" we did was replace "optimized huffman"
with our ELS arithmetic coder and we are seeing an average of 9%
additional lossless compression.  On larger, highly compressed images
the conversion can yield an additional 20%; and on smaller, under
compressed images only a few percent.  For comparison, the ELS coder
seems to do a slightly better job than the Q coder version owned by
IBM.  The "lossless" translation means exactly what you said; the
ability to go between standard jpeg and Pegasus PIC as often as you want
without any additional loss to the file.  Pegasus does not consider this
format proprietary as we have offered the ELS coder to the standards
groups and the public license and royalty free.  9% on every jpeg in the
world might free up a little bandwidth and a few gig.
Anyway, a good discussion for comp.compression, I think, and anyone that
wants is welcome to check it out."

I don't know what happened then, I'm not Tom Lane, I took over the IJG lead
from him only last year.
Now we have a result, and I think we all should accept it as is.
A benefit with Q15 is that it uses the same statistical modelling as QM,
so it does not deviate too much from the original standard.
By the way, in the course of our JPEG enhancement work at ITU we will also
introduce slight improvements in the statistical modelling part,
particularly the DC coding, which also improves our new seamless lossless
modes.
Note that the given proposal only expresses the features from *my* part
(IJG).
There are more features particularly proposed by Joan Mitchell regarding
other improvements.
Note also that the given proposal document is just in "Information for
discussion" style, with more background information than is appropriate
for a formal standard.  This is not a draft for the real Recommendation,
although it may seem so.  I wrote it after reading the T.851 spec,
so it got a nice Recommendation style.  It's close, but it's not.
Joan Mitchell has declared to be editor for the real draft, which will
be rewritten from scratch.  She was also original JPEG editor!
The new extensions might be formally standardized just as additional
parts within the given T.851 framework.
So there are optimal conditions to make it a success, with original JPEG
staff, ITU, and IJG support.  ITU makes the standard (recommendation),
IJG makes the reference software.  And all your existing JPEG files will
be further supported.  You are not *forced* to use the new features, but
there will be good reasons to use them.
Of course, your codecs should be updated, but this will be a simple
drop-in replacement for the application developer.  The new features
where designed in such a way that many of them can be used in given
environments without extra handling.

As soon as it is in the public IJG library, it will go its way to success,
no doubt.
That will not happen now, as said, but next year at the latest (with release
v8).  This year we have to do v7.  So there is no need to hurry, it's just
for information now that everybody knows what's going to happen.

And regarding Microsoft support:
I took part in the ITU-T Study Group 16 meeting in Geneva where I met with
Joan Mitchell and Istvan Sebestyen, the driving forces behind the JPEG
enhancement efforts and T.851 in particular in the ITU team.
At the same time and same place there was a meeting of the "Joint Video
Team" (between ISO MPEG and ITU-T VCEG - Video Coding Experts Group),
and I was kindly invited by the Chairs of this group (Thomas Wiegand,
editor of H.264/Advanced Video Coding/MPEG-4 part 10, and Gary Sullivan
from Microsoft, Rapporteur of AVC) to present the proposal also in this
meeting, because they noticed it and thought (like I also thought)
it might be interesting also for the video coding people.
This presentation in the Video Group (together with Joan Mitchell) was
a particular highlight.  The Video Group (JVT) is a much larger group
with more than 200 participants, and interesting discussions developed
there.

As mentioned, I have also received from Microsoft their "Device Porting
Kit" for the WM Photo format.  So I don't need to speculate about its
features.
The reality is that there are actually three serious attempts for
advanced image coding:
The JPEG-2000, the WM Photo, and our JPEG+ attempt.
Regardless how good or bad the WM Photo is, if Microsoft tries to
push it with introduction of their next operating system Windows
Vista, it will have some relevance.
Furthermore, with the appearance of WMP, the JPEG-2000 attempt will
lose more ground, because WMP is more related to traditional JPEG
technology than JPEG-2000/Wavelets.
The best response (and my advice) for ISO would be to let the
JPEG-2000 be as is and join our JPEG+ attempt.  But that is
their decision, we don't need to care about ISO and JPEG-2000.

Microsoft could at most achieve only some market share with WMP
on their Windows environments, and they could never prevent the
common use of JPEG everywhere (even without our attempts).
They could also not prevent the success of Linux.
So if they are only a bit realistic, they must accept the common
use of JPEG, and they must accept our JPEG+ attempts.
Likewise we must accept their attempts in their own environments.
So there will be some form of co-existence anyway, and then it is
best to accept this and make the best out of it.
Since I am confident that we have a very strong substance and
potential with our JPEG+ attempt in contrast to others, we can
easily accept and even support Microsoft's WMP attempt - we will
not lose our substance.
In order to gain any market share at all with their WMP in
consideration of JPEG and our JPEG+ attempts, Microsoft would be
well advised to take any support they can get to make the best
out of it, and not risk mistakes.
By the way, we have some "Microsofties" in the Independent JPEG
Group as well - they are well advised to follow and support our
attempts.

So while the WMP introduction will certainly be a debacle for the
JPEG-2000 folks (you can see them shiver now...), we can easily
accept it and go our drawn way further.
We take it as a challenge and inspiration to push our developments.
(That's why I quickly put down the "Sudoku" extension proposal.)

Regards
Guido Vollbeding
Organizer Independent JPEG Group

Hi group,

replying to myself, in case anyone cares:

I just put the mentioned PSNR measurements on

http://www.math.tu-berlin.de/~thor/img/

The plots measured the PSNR for various JPEG and JPEG2000 quality
options on the ITU-T test set, and a couple of additional images.
The codecs used are here the IJG-codec with arithmetic QM coding
option, and the Pegasus JPEG2000 codec.

I tested this with the JPEG-1 QM-coder, *NOT* Q15. Thus, be a bit
careful when interpreting the results. I haven't had the time yet
to run it on Q15 and the new ITU-T recommendation, yet.

Sorry for not having the web-space to host the images itself. It's
a full DVD of images, compressed to the given quality, with JPEG2000,
and JPEG-1. If you're interested, let me know and we'll work out how to
host these images as we all know PSNR is just one aspect of image
qualtiy.

Several aspects worth mentioning on the plots in case you do nt want
to study them in full detail:

o) Interestingly, JPEG2000 *always* outperforms JPEG-1 baseline and
JPEG-1 with QM coder. This came part of a surprise to me because I
would have expected that JPEG2000 would loose for small images and
high-rates, at least that's my visual experience.

o) Interestingly, the PSNR gap between JPEG-1 and JPEG2000 *opens* for
larger rates. That is, JPEG-1 looses at increasing the rate. This
also came as a surprise to me. What is especially remarkable about this
is that on some images, the slope of the PSNR-curve for JPEG-1 in the
high-bit regime does not have the expected slope of ~6dB/bit, which is
however a very general result that even goes back to Shannon and should
hold for any reasonable (transform-)quantizer. (Hand-waving argument:
This slope is just the result of having a square in the error measure).
This means that somehow the quantizer isn't controlled optimally. It
would be interesting to see whether this is a JPEG-1 flaw or an
implementation flaw in IJG. As JPEG-1 allows you to define the quantizer
the way you like, possibly the latter. I haven't tried to research this yet.

Last but not least, we all know that PSNR != quality, so again, be very
careful when interpreting these results. As a side remark, a student of
mine, Felix, is currently preparing similar comparison curves but using
SIM as quality metric (Simoncelli's similarity index). There is
currently only preliminary data, so I haven't put that on the web. On
the images we did run tests on up to now, the overall picture (ehem) is
the same, i.e. JPEG2000 outperforms JPEG-1. These measurements do not
yet include JPEG-1 QM or newer ITU-T recommendations, which is part why
all this is pretty much preliminary. As soon as Felix has more data,
we'll see how it goes. I would believe/hope that due to the better
correlation to visual quality the graphs match my experiences better.
One thing we did test already is that "visual weighting" (one of the
encoder options of JPEG2000) does improve SIM, but not PSNR, so that's a
good indicator that it is "sane enough".

So long,
        Thomas

Is this the same as SSIM, or is it a newer algorithm?

Marco

It's an earlier one, and the first step towards SSIM (that is, likely
more will follow from our side). SSIM is built on top of SIM.

Concerning measurements, I've updated the measurements on

http://www.math.tu-berlin.de/~thor/img/

to include ITU-T Rec. T.851, see the other post.

So long,
        Thomas

Hi group, new measurements on:

http://www.math.tu-berlin.de/~thor/img/

this time including ITU-T Rec. T.851.

In case you don't want to go thru all the graphs, here a short
conclusion:

The Q15 in ITU-T T.851 behaives almost like the QM coder in JPEG-1
and the improvement over baseline JPEG-1 in PSNR is mostly around 5% to
10%.

However, I've found some images where ITU-T T.851 actually performs
worse than JPEG-1, especially in the high-rate regime. (E.g., see the
statistics of the bike3 image). Whether that's a bug in the current
implementation or the consequence of the bitstuffing or the lack of
the MSB/LSB interchange in Q15 is currently unknown.

In none of the images, ITU-T T.851 outperformed JPEG2000, and it almost
never came close to it. It is closer to JPEG-1 than to JPEG2000. Some of
the problems detected in JPEG-1 also hold for T.851, unfortunately,
which is of course not a suprise.

The PSNR gap between ITU-T T.851 and JPEG2000 opens for larger rates,
which came as a surprise for me. Especially, T.851 as JPEG-1 do not
always follow the hi-bitrate approximation for higher rates, thus
there`s definitely a problem somewhere, likely in the quantizer
settings. Likely the lack of any suitable R/D optimization within the
code, and can likely be fixed by computing the quantizer settings
smarter than the current simple scaling.

So long,
        Thomas

If you are talking about the universal image quality index I don't quite
see the point. For a student it might be good to compare it against SSIM
to understand where the problems lay with UQI (it could not deal with
with areas of the image where the variance was very low). As a benchmark
though you might as well start with SSIM right off, if you have
implemented one then implementing the other only takes some trivial
alterations. SSIM is simply better.

As an aside, I like SSIM ... in my opinion it showed that most of the
old assumptions about spatial channels and inter channel masking were
complete bunk.

Marco

The world does not revolve around open-source software, Mr. Vollbeding.
 Who will go back and add support for this format to all of my older
software for which no source exists?  Nobody.

I think the previous poster put it best when he mentioned that this
ship sailed a long time ago.  When broadband costs $50 a month or less,
and when hard drives cost $100 for 320GB, there is simply no need for
an improved yet incompatible JPEG standard that squeezes an additional
5% out of a file.  Did anyone attempt to point this out to you before
you began this endeavor?

You know what will happen the first time I attempt to download one of
these new files?  It will not decode properly in my software, and I
will assume the JPEG is broken, and I will delete it.  And so will
millions of other people.  And don't suggest people put up two versions
of the image, that defeats the whole purpose of trying to save space in
the first place!

Jim,
the availability of the free IJG library is the principal reason that the
JPEG format achieved universal adoption in the world!
It is due to the efforts of the Independent JPEG Group that most of your
"older software" can deal fine with JPEG images.

Jim,
I did not initiate the current T.851 result - I just take it as a *first
step* towards an overall updated JPEG standard, as described before.
Why should we leave this field to other obsolete attempts, particularly
this ignorant, corrupt, and stupid JPEG-2000 crowd?
You see that there *are* such attempts, and there *are* useful applications
for it.
So what we with ITU and IJG try is to provide a reasonable solution for
advanced image coding requirements with maximum compatibility to existing
JPEG standards, and thus continue the success story of original JPEG.
You can not expect such reasonable and successful results from JPEG-2000
like approaches - they are doomed to fail for various reasons as mentioned
before.

Jim,
I have suggested to use another file extension (.jpp or .ipg) for the
extended files, so they can be recognized without failure.
By the way, a similar situation arose when progressive JPEG support was
introduced in the IJG library - it caused some failures first, but it
was finally accepted by people - simply because it was supported by IJG,
and even without a new file extension.
You won't be forced to use our new extensions.
But the fact that it is supported by IJG gives people confidence that this
is a way of being universally adopted and going to success eventually.
Something what you cannot expect from approaches like JPEG-2000 - it
failed to achieve common adoption, for good reasons.  But we are not
JPEG-2000.
We use the same established DCT based technology as people are familiar
with, and there are options to losslessly transcode between old and new
formats.  So even if you get a new format file, you may likely be able
to transcode it to a form recognizable by older software.
But more importantly, you will not be forced to throw away all your
existing JPEG images.  Do *not* throw away your existing JPEG images -
they are not as bad as other folks want to make you believe, we will
continue to support them seamlessly without problem.

Regards
Guido Vollbeding
Organizer Independent JPEG Group

No, it's not UQI. It's a stabilized version of UQI. It doesn't have
scales in it, though, but it doesn't have the instability problem.

  For a student it might be good to compare it against SSIM

I agree. On the other hand, it opens a hend-and-egg problem. SSIM
requires some scaling filter, and as such we should probably not using
the same kind of filtering as in the JPEG2000 itself. Otherwise, what
are we measuring?

Anyhow, yes, SSIM will definitely follow, but we need to be a bit
careful, and I need to think first how to do deal with it.

Well, in the end, all what counts is whether it correlates well with the
mean opinion score. I found the graphs presented by Simoncelli et all
not completely convincing, but then again, we should measure and compare
ourselves as well. This is a longer term project I'm running.

There has been recently a call for a visual video metric, and the
outcome of the first round was that there was nothing that did really
considerably better than PSNR. There were some results in the second
round with considerable improvements, but the ideas found here target
really at video, and less at still images.

So long,
        Thomas

This is all correct, but besides the point. The situation *now* is quite
different from the situation *then*. On the other hand, I don't think
anyone need to really *care* about this problem. It is not the matter of
a standard to estimate how successful it might be, so why fighting about
this point? We'll see how it goes anyhow. The point being is that as an
incompable exension beyond the existing standard that is neither able
outperform other incompatible existing standards - why do you care?

Or to put it differently, *IF* you think that IJG is succesful *because*
it is IJG and free and all the like, why don't you extend the IJG codec
to support JPEG2000 as well? I don't think its an overall problem to
integrate this into the code, it performs better than any of the
extensions JPEG-1 and ITU-T provided so far, so what's so special about
ITU here?

So what's the *real* reason? I haven't seen a technical one - my
measurements speak against your claims - I haven't seen a political one
- you could support JPEG2000 right away if you would like to and the
same arguments you brought for T.851 or its successors would carry over
unaltered - so what is it?

Guido, you're running near the edge of collecting a trial for slander.

*If* you have arguments, why can't you just give *technical* arguments
for them? Why do you think ISO/JPEG/SC29 will stick with JPEG2000 on and
on? The road goes ever on and on...

You know, I believe that you're just running out of arguments. People
get angry and unlogical if they are frightened and find no other means
to defend themselves. So why that? Why not just propose a couple of good
ideas, post a test codec, "Here, Thomas/ISO/SC29, please measure for me,
what do you think about these ideas...". Instead, you drive everyone
nuts. I just don't get it.

Or, while you're trying to fix things, here's a simple research task for
you: Try to understand why the R/D slope of JPEG-1 isn't optimal for
high rates. It should have a slope of approximately 6dB/bit. Why doesn't
it? Can this be fixed within JPEG-1? (Hint: Check for the quantizer.)

First of all, I don't think "failed" really applies. It found its
market, but outside of all-day general purpose image compression because
*that* is a problem that simply doesn't exist anymore. JPEG-1 does the
job considerably well, people are more and more asking for "raw" image
formats rather than "more compressed" ones. Thus, the whaddayouwant
improvement of JPEG2000 or ITU T.851 or whatever ITU-T.XXX we are going
to see really didn't and doesn't matter for *these* applications.
JPEG2000 gains some market were it provides features JPEG-1 failed to
deliver (e.g. interactive image browsing, huge image handling), and this
  is just natural. It solves *here* problems people have. Similar, any
newer standard that solves the same problems will have to deal with a
market niche already occupied. And concerning the kind of compatibility
IJG will provide with newer versions - we can do that right away today.
Check the first two bytes of the codestream, decode as JPEG1 or
JPEG2000. Just the same kind of story. (-;

This argument also applies to the proposed windows compression, to
JPEG2000, to GIF, to PNG, to PPM,...

And again, you miss the point. The side conditions *now* and the
conditions *then* were considerably different. You cannot compare
today's situation with the market twenty years ago. Note again that I'm
not trying to stop anyone, please go ahead, I would just prefer an
overall approach where we would do research because we do research, and
not use DCT "because Guido likes it".

So you're using it because you are familiar with? Isn't that kind of a
weak argument if you want to develop a new standard? Shouldn't it be
part of a scientific research approach to go beyond what people are
familiar with? (And yes, this of course implies going beyond wavelets!)

I don't think anyone believes they are bad in any way. But your
continuous claim of JPEG1 being superiour is just provably wrong
either. So why the heck are you getting so emotional? Where is your
problem with accepting that newer standards outperformed the one IJG put
forward years ago? So would probably any newer standard outperform
JPEG2000. The world just moves on.

So long,
        Thomas

Thomas, sorry, you didn't get the point.  And that's why I don't think it
is useful to argue with you any further.  Anyway, I just put my explanation
of the subject here for you, not assuming that you understand it.

I am not going to support JPEG-2000 because I have found it to be inferior!
And many other people who *tried* it in practice on *real* images under
*reasonable* conditions came to a similar conclusion, that's why it isn't
commonly adopted.  So this is my own experience and the experience of many
other people who tried to use it.

Your proplem is that you are looking PSNR tables, rate-distortion curves,
and so on, but I and other people in application are looking *real* images.
That is the simple difference, and the reason that we come to different
conclusions.  No-one in practice looks at PSNR tables and rate-distortion
curves, but rather on existing images.  Instead of researching for other
measurement indicators, you should just sit down and watch real *images*,
with your biological eyes as measurement indicator.
That makes all the difference.

The second problem of your approach is the type of images which you select
for your evaluations.
I have already told you that you were using the wrong type of images
for your evaluations.  On that basis you must of course come to wrong
conclusions.
If you accept the output from common mainstream digital cameras as
appropriate evaluation material, you are on the wrong way.
I have seen that some of the smarter researchers have already recognized
such images to be inappropriate and using some more appropriate material.
In such more advanced research papers you find references like the "Kodak
Reference Image Set" (originating from Kodak Photo CD).

The problem with today's mainstream digital cameras is that they use an
inferior, defective type of sensor technology which filters off two thirds
of essential image information in the first place (mosaic color filter
array or Bayer pattern mask).
The missing information must then be interpolated after image capture.
So these images are largely artifacts and already distorted, before any
further processing can take place.  Those images are far away from natural
source images and thus are not appropriate input to "photographic" image
compression schemes.
Of course, the type of distortion introduced by this defective capture
technology kind of matches the Wavelet artifacts - smoothing (washing)
out the image details.  But combining two defective and artificial
image technologies doesn't make the results good.
People who like rather sharp and crisp images have problems with such
mosaic images as well as with Wavelet processed images.
People with inferior vision, and there seem to be quite a lot, may not
complain about the inferior results, while for people with superior
vision the same results appear unacceptable.
Therefore, people with superior vision use the DCT for image compression,
because it better preserves the sharpness, and likewise prefer digital
cameras with non-defective sensors (Sigma SD9/SD10 with Foveon full-color
sensor technology).
So if you are searching for better image quality measurement indicators,
please take that into account.  Otherwise I prefer to judge image quality
with my naked eyes - which has so far proven to be a more reliable
indicator than any of your measurement results.

Regards
Guido Vollbeding
Organizer Independent JPEG Group

And you continuously claim so, and failed to deliver any proof for it.
If this is the central point of your argumentation - and if it is - then
please provide facts that backup your claim.

And of course I know that this makes a difference. And of course we're
currently measuring with something different now for exactly that
reason. Guido, everyone in the community knows that PSNR isn't a visual
metric. So do I. So do I see that JPEG2000 falls behind on some images.
But unlike your claim, not on all images. My finding is that it doesn't
perform well on all images, and that's what I also have posted here from
time to time:
Does not well for small images, does not well for high-contrast images.
Does well for large images, does well for flat images. I also explicitly
stated this in the ISO/ITU meeting, and I explicitly made measurements
to see this.

("Well/bad" heree as whether there's an advantage to JPEG-1.)

So, what's your proposal for a visual metric, what shall we use? I
cannot run an ITU-T BT.800 test, I don't have the means to do that. So
we need to do this somehow objectively, a full-reference visual metric.
My first attempt in doing so is SIM (Simoncelli Structural Similarity).
This is a pretty simple one, but first things first, you need to start
from somewhere.

As said, and as already posted, it's a bit too early to post results,
but on the measurements we have at the current time, things work very
much alike like PSNR, interestingly. There's no image where JPEG-1
outperformed JPEG2000. I've one image where for one certain bitrate
JPEG-1 performs better. But then again, this is JPEG2000 in PSNR-optimal
mode and not in visual-optimal mode, so again, too early to say anything.

Thus, I propose and highly suggest to do the following:

a) If you have proposals for objective, full reference visual metrics,
please let me know. From our side, SSIM is definitely next after SIM
measurements are complete. If you know anything else you would like to
put forward, *please* let me know.

b) Until measurements are complete, let's stick to the facts we have
right now. I do not want to argue about better or worse until we really
know what better or worse is. PSNR like it is better, without any doubt,
this is *proven*.

c) Whatever the result is, is the result. I'm tired of arguing. If the
result is pro-JPEG1, then so might it be. If it is pro-JPEG2000, so
might it be. I also stated exactly that in the ITU/ISO meeting, and
people accepted this.

If you have images where you find that JPEG2000 is worse, it would then
be interesting to know which codec this is, and in which mode it is
driven. Unfortunately, due to a lot of "marketing hype", people push
PSNR too much and thus use the codec in PSNR optimal mode. This is of
course wrong. And again, people use the jasper code, which is also not
an optimal choice. Actually, it's IMHO the worst choice, but then others
might have other opinions.

These are the *same* images ITU-T used for JPEG-1 testing. I actually
haven't made *any* choice here, and on purpose. I asked Mr. Sebestyen
explicitly whether the JPEG-1 test images are available, and I got them,
and the results are what you see. The test images contain a couple of
classics (goldhill, areal) some compound/hard images (fax-images, color
fax), etc... All in a pretty good quality. Isn't it just fair that we
use the same means to measure JPEG2000 than ITU/ISO back then choose for
evaluating JPEG-1?

So which test corpse would you accept if "your own" test corpse isn't
good enough? (-;

And I'm not. (-:

We can also measure on this corpse if you like to. No problem. The PSNR
results are, even though they're not in my web page right now, rather
the same. Want to see it? No problem, I'll modify my script, download
the images, and let the system compute for a couple of hours. Would you
then stop depating? (I also wonder why I do have to do the job anyhow,
but so might it be.)

Might be right or wrong, and might be a different argument. Might even
be an argument pro-JPEG2000 since it works better on the images the
consumer sees. Whatever. It's not an argument con my measurements since
that's not what I've used for measuring. (-:

Actually, have you checked the recently posted measurements? You should
definitely know the images used there. All the old common stuff and in
fact the same test set ITU-T uses. Thus, your point is taken, and I
agree that test images are important, and I agree that we should have a
good ground for testing, and I agree that consumer camera images are
just one facet of many others, and I agree that we should test a lot on
other images.

However, this argument simply doesn't apply since my test set is in
majority not from this source. It's in majority from your source.

Point taken? (-;

So long,
        Thomas

Thomas, again:  This is not a point to argue, and I cannot backup my claim
on basis of what you would accept.
I cannot give you my eyes for vision - you can only use your own eyes.
And that's what I recommend:  Just use your own eyes.
But instead you are still searching for and demanding better measurements.
It doesn't work that way.
You must *first* see for yourself, and *then* might find a good measurement
someday which matches your visual experience.
But without visual experience all your measurements will be useless.

I have a visual experience which is more worth than any of your measurements.
Because I had to look at millions of images over many years.  And I'm looking
nature, so I can well recognize defects and differences.

So that's why we make efforts to improve JPEG-1 on the "not so well" cases
(see "Sudoku" extension proposal to address large images, for example).
Why shouldn't we do this?  We have a well established technology which does
well in many cases, and now we are going to improve it for other cases.
What's wrong with this way?  Why should we throw away our established
substance and switch over to something completely different only because
some strange people present nice PSNR tables and rate-distortion graphs?
Again, the point is not in having nice-looking PSNR tables and
rate-distortion graphs, the point is in having nice-looking images.
When will you realize this?

The jasper code was just the first code which was freely available.
I see you constantly complaining about bad J2K codes people use.
But why don't you care to provide something better instead of complaining?
Your complaints are simply useless as long as you can't recommend
something better.
And what is the purpose to have a standard which looks good on paper
but is useless in practice?  It doesn't work that way - there are plenty
of useless standards on paper, but what counts is whether and how they
are applied in practice.
And that is the point of the Independent JPEG Group:
We choose a reasonable standard, and make it available for application.
If you don't have something like that for your standard, then it is simply
obsolete.
And I have told you why I am not going to support your standard - I simply
don't consider it reasonable.
And apparently nobody else appeared so far to do something for your standard
similar to what the IJG does for the JPEG standard.  That's your problem.
Please think about it, there are reasons.
And instead of supporting J2K, I have found my own ideas how to improve the
given technology for more applications.  That seems reasonable to me, and
nobody else seems to do it for me, so that's why I'm going to put that in
a standards extension with ITU.

I think you ISO JPEG and JPEG-2000 folks have just a different approach
of how things should work, but apparently things do not work that way.
I have made some experiences of how things work - I see the reality,
I see the success, and I see how to continue that success story...

Regards
Guido Vollbeding
Organizer Independent JPEG Group

maybe you should clarify a little ...

the press release sounds like the decision for DCT+Q15 is final for
T.851. You make claims concerning the coding performance and I got the
impression that this is a new standard that is ready for use (whereever
someone might think it should be used - I don't want to judge on that)

In this thread you are talking about further changes and improvements
... It makes me feel you are far from a final version and still
conducting "core experiments" as Thomas calls them ... It might be
interesting as a research topic but this is far from talking about
library support for endusers!

I understand that the process of standardization is going on and on and
that there are new applications and fields which need different
solutions. I don't care if the idea behind all this is DCT or anything
else - the algorithm and complexity just needs to match the application
in the end ...
Somehow I get the impression that a lot of experts do not agree with you
and there are even jokes coming up to call that new format PEG instead
of JPEG ;-)

bye,
Michael