20 Years of JPEG Celebrated With Software Launch
Guido Vollbeding
(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
Guido Vollbeding
http://www.itu.int/ITU-T/newslog/20+Years+Of+JPEG+Celebrated+With+Software+Launch+.aspx
Michel Bardiaux
> 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.
>
I?). The PDF however is not extremely clear. Are the various results at
equal Q or equal PSNR?
>
> Regards
> Guido Vollbeding
> Organizer Independent JPEG Group
Cheers,
--
Michel Bardiaux
R&D Director
T +32 [0] 2 790 29 41
F +32 [0] 2 790 29 02
E mailto:mbar...@mediaxim.be
Mediaxim NV/SA
Vorstlaan 191 Boulevard du Souverain
Brussel 1160 Bruxelles
http://www.mediaxim.com/
Guido Vollbeding
>
> The PDF however is not extremely clear. Are the various results at
> equal Q or equal PSNR?
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.
> (I cant honestly say a 10% improvement is smashing, now can I?).
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:
direct: http://jpegclub.org/temp/ITU-T-JPEG-Plus-Proposal_R3.doc
Regards
Guido
Jim Leonard
> Michel Bardiaux wrote:
> >
> > The PDF however is not extremely clear. Are the various results at
> > equal Q or equal PSNR?
>
> 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.
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.
Guido Vollbeding
>
> 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?
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.
> More importantly, why would I want to start doing this *now*? None of
> my software on any platform can read these as of today.
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!
Thomas Richter
> Jim Leonard wrote:
>
>>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?
>
>
> 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.
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.
> 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!
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.
> 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.
>
>
>>More importantly, why would I want to start doing this *now*? None of
>>my software on any platform can read these as of today.
>
>
> 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.
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.
> 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!
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
Guido Vollbeding
>
> That means, I still cannot use Q15 for proprietry products
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/ .
> 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 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.
> Beating JPEG is actually easy. The standard is a bit old, and an overall
> renovation would be suitable.
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.
> 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.
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!
> 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.
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:
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 also haven't compared with the new Microsoft code yet, I just don't
> have it.
I have it!
But I can't tell about the details here because I had to sign kind of
non-disclosure agreements.
> 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.
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...
Thomas Richter
> 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/ .
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.
>>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 is the *real* JPEG organization, based on the *real* JPEG standard!
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".
> 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.
>
>
>>Beating JPEG is actually easy. The standard is a bit old, and an overall
>>renovation would be suitable.
>
>
> 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.
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?
> 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!
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?
> Of course you can't
> recognize this because you have not understood or ignore the basic DCT
> fundamentals.
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?
> 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.
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.
> Backwards-compatibility is exactly what YOU broke with your JPEG-2000
> thing!
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.
>>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.
>
>
> 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:
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.
> 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.
*Where* did I propagade anything? Since when do I marketing?
>>I also haven't compared with the new Microsoft code yet, I just don't
>>have it.
>
>
> I have it!
> But I can't tell about the details here because I had to sign kind of
> non-disclosure agreements.
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.
>>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.
>
>
> 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!
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?
> 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!
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.)
> And I can assure you that our results are superior to anything what
> you have seen so far. As said: Stay tuned...
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 your public presentation. You need to be more open to reach
this goal. What you're doing here comes over quite lousy, really. Cool
down, Guido. I'm *not* your enemy. If you want to "win" (whatever this
will mean), you shouldn't loose your head like this. Even worse, you
yourself are the largest enemy for a better standard. Please *work* on
the points I've made.
So long,
Thomas
Phil Carmody
> Thomas Richter wrote:
> > Beating JPEG is actually easy. The standard is a bit old, and an overall
> > renovation would be suitable.
>
> 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.
Dogma.
> > 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.
>
> 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.
Dogma.
Image compression shouldn't work on dogma, it should work on metrics.
> 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.
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
Jack Berlin
news:4eq6dmF...@news.dfncis.de...
<snip>
> 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.
<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."
Guido Vollbeding
>
> 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.
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.
> 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.
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.)
Thomas Richter
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
Marco Al
> 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).
Is this the same as SSIM, or is it a newer algorithm?
Marco
Thomas Richter
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
Thomas Richter
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
Marco Al
> Marco Al wrote:
>> Is this the same as SSIM, or is it a newer algorithm?
>
> 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.
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
Jim Leonard
> > 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.
>
> As soon as it is in the public IJG library, it will go its way to success,
> no doubt.
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!
Guido Vollbeding
>
> > As soon as it is in the public IJG library, it will go its way to success,
> > no doubt.
>
> 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.
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.
> 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?
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.
> 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,
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.
Thomas Richter
> Thomas Richter wrote:
>
>> Marco Al wrote:
>
>
>>> Is this the same as SSIM, or is it a newer algorithm?
>>
>>
>> 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.
>
>
> If you are talking about the universal image quality index I don't quite
> see the point.
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
> 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.
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.
> 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.
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
Thomas Richter
> 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.
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?
> 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?
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.)
> 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.
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. (-;
>>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!
>
> I have suggested to use another file extension (.jpp or .ipg) for the
> extended files, so they can be recognized without failure.
This argument also applies to the proposed windows compression, to
JPEG2000, to GIF, to PNG, to PPM,...
> 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.
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".
> 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.
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!)
> 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.
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
Guido Vollbeding
>
> 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?
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.
Thomas Richter
> Thomas Richter wrote:
>
>>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?
>
>
> 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 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.
> 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.
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.
> The second problem of your approach is the type of images which you select
> for your evaluations.
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?
> 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.
So which test corpse would you accept if "your own" test corpse isn't
good enough? (-;
> If you accept the output from common mainstream digital cameras as
> appropriate evaluation material, you are on the wrong way.
And I'm not. (-:
> 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).
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.)
> 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).
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. (-:
> 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.
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
Guido Vollbeding
>
> > I am not going to support JPEG-2000 because I have found it to be inferior!
>
> 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.
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.
> 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 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?
> 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.
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...
Michael Schöberl
> extended files, so they can be recognized without failure.
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
Thomas Richter
>>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.
>
>
> 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.
So do I, Guido, so do I.
> But instead you are still searching for and demanding better measurements.
> It doesn't work that way.
It works exactly this way. That's the way how science works: By finding
objective grounds for claims. Otherwise, we can of course agree that
"JPEG-1 is better for you than for me", but what can we derive from this
insight? Nothing.
> You must *first* see for yourself, and *then* might find a good measurement
> someday which matches your visual experience.
So do I. I stated more than once what I'm able to see. Now, aparently,
we agree to disagree, so we need some objective ground, otherwise
there's no arguing.
> But without visual experience all your measurements will be useless.
Except that I personally cannot make *objective* measurements. I can
make *subjective* ones. Very nice, but only helps myself. And as my
subjective results are different from yours, no conclusions whatsoever
can be drawn. Thus, no knowledge gained, no lesson learned, and no clue
whatsoever what to do better the next time.
> I have a visual experience which is more worth than any of your measurements.
Why do you continuously disallow me to make my own subjective tests? My
visual experience is just different. Don't you think I've never looked
at the images? Why are Guido-tests the only acceptable tests?
> 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.
You're trained to JPEG-1. Of course. So that's a lousy test. You need
unexperienced people, or customers from the street, if you want to say
so, and ask them about what they see and don't see. Otherwise, you will
look for artefacts you're not familiar with, and I look for artefacts
I'm not familiar with, and in the end we cannot conclude anything.
Point is, I cannot run these tests, I don't have the means to do that. I
can neither pay the equipment, nor the people. That's exactly the regime
of full-reference objective computer based tests - and a research field.
You seem to deny the usefulness of these tests as only the Guido-metric
is the real metric. For you - of course it is. For anyone else - likely
not. You cannot generalize from your own visual experience, that's the
point.
>>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 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?
I've never said you shouldn't do this. Of course you should! Of course
WE should. Of course the ITU and ISO should in common. But for that we
first need to agree what is "good" and what is "bad". And for these
tests, "Guido" is a bad visual standard. Not because of you
specifically, but because it is a norm that is based on one single observer.
> 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?
Nothing's wrong with doing so, except that you're so focussed on one
single technology. That's why I say that you yourself are the largest
obstacle in finding improvements - you wouldn't accept anything but DCT.
And that's a very bad starting position for making progress.
For example, why was ITU-T.851 necessary? There's no new idea in this
standard whatsoever.
> 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?
Quite the contrary, I don't say that you should throw things away. Keep
JPG what it is! It does a good job! What I'm saying is that if you want
to improve, you need to widen your horizon. Of course any new standard
must measure against JPEG. It must also measure against JPEG2000. And
measure definitely also means "beyond PSNR". But I *insist* on "measure"
and not a "Guido metric". Of course, people providing the metric must
make sure that this has a good correlation to visual impact. And of
course just measuring against PSNR is an error. PSNR, however, can
*also* tell a story, namely whether the overall codec design is sane, as
there are a couple of interesting theoretical results on it.
> 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?
Since long ago, Guido, since long ago. There's nothing to argue about that.
>>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.
>
>
> 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?
I do care. The committee cares. For example, the UCL has an initiative
about an OpenJPEG codec (google for it). I haven't looked at it, but
these are people that know how to do their job. You can also check with
the JJ. Otherwise, several notably better codecs exist on the market.
You can also get a test version if you need to - thus claiming being
unable to find a good one just means that you're unwilling to look, I
afraid.
> Your complaints are simply useless as long as you can't recommend
> something better.
A recommendation. Ok, fine, here we go, my personal hit-list (from best
to worst.)
a) The Pegasus codec. (-: Well, that's mine of course. No surprise. Note
the (-:.
b) The Kakadu codec. I think you might get an academic licence as much
as you could get a test version of "my" code.
c) The JJ2000
d) The Jasper
where c) and d) definitely in that order. I haven't tested against
OpenJPEG myself, so I can't make a suggestion where to put it on this
list. Probably between b) and c) as I'm aware of a couple of minor JJ bugs.
> 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.
Huh, since when doesn't it work? Of course it works. It's also sold, but
in different areas.
> 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.
Of course we do have something like that. You can buy JPEG2000 from a
couple of people. University of New South Wales, Kakadu (IIRC). Pegasus
Imaging, Aware, LuraTech. You can get test versions for free from most
of these people.
> And I have told you why I am not going to support your standard - I simply
> don't consider it reasonable.
The problem is that this is pretty much prejustice. You failed to
provide *objective* reasons. Instead, you consider it cool to run
personal attacks against anyone who doesn't share your p.o.v. - it
doesn't work that way. My view on all the claims you've made here is
that you've now maneuvered yourself successfully into a position of no
return. Stop it, for yourself.
> 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.
There are reasons. To some degree that there's no widely available free
codec, right. To some degree, too, that the available FREE ones are -
well - not really what I like them to be. To the major degree, however,
that the problem JPEG-1 attacks doesn't exist anymore.
Consider we had a standard - just consider - that would compress the
images to half the size we archive with JPEG-1/JPEG2000 today. (No,
that's not Microsoft - that's just marketing.) Would this be successful?
My personal opinion: No. There's no point in doing so, because there's
no problem in having a 100MB image. Go to the next MediaMarkt, Cicruit
City or Radio Shack or whatever, buy the USB stick with 4Gig, problem
solved. (For M$, the situation is of course a bit different, they can
force people to use whatever they want people to use, but that's then
again a different story.)
Problems lie elsewhere today.
Should we stop doing image compression? Maybe. But possibly, we should
understand where the problems lie, and should design compression schemes
such that they solve the problems the people have. JPEG2000 part 9 is a
good example where this principle applies. "Just" compress my images,
well, JPEG-1 does it, no big deal.
> 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.
Well, except that the market niche you're targetting at is probably
occupied already. Which "new problems" are you able to solve you cannot
solve with existing technology today? As Jack put it: "This boad sailed
away long ago." It's really that. ITU-T.851, for example, was pretty
much pointless after all.(Any new solutions for new problems? No.)
So maybe you do have new ideas, why not. As said, I'm not the one who
will stop anyone, I can only learn.
> 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.
Aren't they? The point being is that you seem to have no clue how things
do work here at ISO, so why do you imply this? It's an open committee,
ideas welcome. Just not warmed-up old ideas. Make something cool, new,
prove that, and you're welcome.
> 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...
Shrug. I see the success of JPEG-1, but I don't see how drilling that
idea up to infinity should have success. But then, I don't stop it, go
along and see yourself. What I'm seeing is no real improvement on this
road. It requires smarter ideas, and especially, it requires finding the
problems people really have.
Here's an idea for you, and something ITU and ISO should probably care
about: Standardize something like Open-DNG. An extensible,
well-accepted, open, raw-image file format. Wouldn't that be something
cool to have, based on the official grounds of ISO and ITU?
So long,
Thomas
Michael Schöberl
> about: Standardize something like Open-DNG. An extensible,
> well-accepted, open, raw-image file format. Wouldn't that be something
> cool to have, based on the official grounds of ISO and ITU?
This looks promising as the available solutions for compressing raw-data
do not look that powerful ...
- koh, mukherjee, mitra ("new efficient methods...")
just split the image in 4 parts ...
or apply a lossy deinterlacing filter
- Lee, Ortega ("a novel approach..")
rotate the image by 45° (uuh - the dataflow!)
but I'm sure Guido will protest as he considers Bayer to be inferior and
probably not even worth looking at it ... just google for guido foveon!
I guess he still compares 3 Mpixel Foveon (with 9M sensor elements) with
3M Bayer (with just 3M sensor elements) ...
bye,
Michael
Guido Vollbeding
>
> 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!
Michael,
please read my earlier posts in this thread.
There was following pointer:
direct: http://jpegclub.org/temp/ITU-T-JPEG-Plus-Proposal_R3.doc
There is currently a "Roadmap" for further developments.
The T.851 with Q15 is approved and finished.
By the way, Istvan Sebestyen told at the meeting that he has registered
a new file extension for this purpose, I think .jpa.
But I think this addition alone is not important enough.
I have other important suggestions in the proposal, and these are not so
far away from library support for endusers as you may think.
Some people already thought that the Proposal were a Draft Recommendation,
so it has some substance. The basic items are clear, some minor tests
are still required.
But the main work for library support comes already with v7! v7 contains
the basic algorithms, namely the scaled DCTs. The format extension
features are relatively easy to realize on top of this scaling support.
And the scaling support is already used in various applications based on
my preleiminary version on http://jpegclub.org . Note that this version
is already close to release regarding the scaling features.
It was deliberate that I added the new "Sudoku" extension proposal as an
Annex in this document. Because I feel this requires some more
implementation effort, although the basic idea is clear. The other
features can be realized more quickly and do not require substantial
additional implementation effort beyond v7. My plan is to provide the
given extension features with a v8 next year.
> 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 ;-)
I consider this an advantage and a sign to be on the right track.
Do you know what Henry Ford said about "so-called" experts?
"Bricolage is very important; from books you cannot learn anything
practical. That's why I never hire an authorised expert.
If I wanted to destroy the competition, I would overwhelm them with
experts. We don't have so-called 'experts' here."
So that's how things work in the ISO JPEG committee: They have hundreds
of "authorised experts", but that is exactly the reason that they fail
in reality. Because these are only "intellectual" experts, and intellect
alone has no root in reality and is stupid. You must add intuition to
intellect, and become intelligent. Intelligence is not the same as
intellect. So all those experts are intellectual, but they are not
intelligent. Most education today *prevents* people from being
intelligent, unfortunately.
There is also a nice saying from German writer Wilhelm Busch
(sorry, too lazy to translate now):
Wer anderen etwas vorgedacht,
wird jahrelang erst ausgelacht.
Begreift man die Entdeckung endlich,
so nennt sie jeder selbstverstaendlich.
Wilhelm Busch
Marco Al
> 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.
I think you are confusing SSIM with multi-scale SSIM. The original SSIM
was already a single scale algorithm, multi-scale SSIM came later.
> Well, in the end, all what counts is whether it correlates well with the
> mean opinion score.
In the end sure, but in the meantime the concept of basing quality
metrics on gratings experiments retarded the development of image
quality metrics for a decade in my opinion.
> 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.
It has been independently compared against the Visible Difference
Predictor algorithm BTW.
> 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.
SSIM wasn't part of either phase of course.
Marco
Brian Raiter
> like to.
Urk. I'm pretty sure you meant to say "corpus" instead of "corpse".
Those two words started from the same root, but, somewhat like Guido
and yourself, wound up in very different places.
(Apologies if the malapropism was intentional on your part.)
b
Guido Vollbeding
>
> > Here's an idea for you, and something ITU and ISO should probably care
> > about: Standardize something like Open-DNG. An extensible,
> > well-accepted, open, raw-image file format. Wouldn't that be something
> > cool to have, based on the official grounds of ISO and ITU?
>
> probably not even worth looking at it ... just google for guido foveon!
> I guess he still compares 3 Mpixel Foveon (with 9M sensor elements) with
> 3M Bayer (with just 3M sensor elements) ...
Michael,
you have absolutely hit the point, congratulations, you seem to be
intelligent :-)...
I can hardly imagine anything more obsolete than this DNG initiative.
Why establish an obsolete image capture technology which loses two thirds
of essential image information in the first place in a distorting way?
This is the most stupid idea you could accept.
The Foveon sensor is still the only acceptable image capture technology
that exists today (well, aside from 3-Chip video cameras).
And you don't need such crappy approach like DNG for a *reasonable*
image capture technology.
You need a crappy solution only for a crappy technology.
By the way, do you know how the analog color film was invented?
This story tells a lot.
The first practical color film process (Kodachrome) was developed in 1935
by the two professional musicians Leopold Godowsky and Leopold Mannes,
after many well-known scientists had been searching unsuccessfully for
a practical color photography process for more than half a century!
They were just "amateurs" on this field, and they were invited to perform
their experiments in the Kodak Labs in Rochester, where the established
scientists were just good enough to assist their work.
See also
http://www.bu.edu/prc/GODOWSKY/godowsk2.htm
That's how important inventions are made...
And of course I have also contact to Foveon developers and supported
them to improve their JPEG output:
http://jpegclub.org/foveon/
http://jpegclub.org/foveon/index2.html
By the way, the example resolution numbers on
are not arbitrarily chosen, they are related to the only acceptable
digital still camera technology available today.
So what Foveon/Sigma need is better JPEG features, but not DNG.
Jack Berlin
> 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.
You have got to be kidding me, and yourself! There was a huge vacuum at the
time in digital imaging, and DCT on 8 x 8 blocks of pixels was the only good
solution out there. And it was and is a great solution. This was the world
of 286 and 386 computers with limited RAM, bulletin boards (pre-internet
dial up) full of GIFs that didn't look so good (especially with skin
tones!), 8 bit displays, TARGA boards, 1.5 MB diskette drives and no CD
ROMs, 40 megabyte hard drives and $2,000 scanners considered low end! There
were companies pushing proprietary DCT solutions all over the place, like
Telephoto (Alice Boards), Storm, Xing and yes, Pegasus, plus a few others I
forget. Many of those folks, including us, got together and standardized
the format. There was no IJG at that time. The JPEG standard would have
been just as widespread, with or without IJG, and all Tom Lane and IJG did
was miss out on a commercial success. The vacuum was going to be filled
regardless. JPEG was already very successful before the IJG library finally
improved enough to be commercially acceptable. Lots and lots of work and
support gratis which I am sure the world appreciates. Certainly IJG saved
companies millions of dollars in license fees (some of which they gave back
to Forgent if they weren't a Pegasus customer, so sometimes 'free ain't
free'). JPEG was the only way to handle true color photo images in the
early 1990's and nothing was going to stop its success. The principal
reason of that success was that the compression worked well and worked fast,
and absolutely nothing else did.
But, as Microsoft proves where it has a monopoly, 'free' drives away
innovation. Instead of lots of Pegasus' competing to build better JPEG code
the world ended up with Pegasus and IJG. Where did lossless rotate,
lossless crop, region of interest decoding, thumbnail decoding, lossless
hue, tint, brighten, contrast, and ELS Coder (ten years' before it now is
supposed to be a good idea says you) JPEG come from first? Not IJG, but
Pegasus, and soon copied. IJG's implementation of progressive JPEG killed
the format on the launching pad. IJG's progressive decompression uses many
times more memory than Pegasus which made things very difficult, and then
what did we get from the browsers (yes, Netscape was IJG), was a
decompression engine that waited until almost the whole 'progressive' file
was downloaded to start decoding. That missed the whole point of
progressive I think. A commercial company never would have allowed that to
happen. So people turned to Wavelet with one of the strongest reasons being
progressive decoding and region of interest decoding, all of which could
have, should have been done with JPEG, given a bit of competition.
IJG has certainly played a huge role in the adoption of JPEG, much more so
than Pegasus, and certainly hastened that adoption; but, also most certainly
helped open the door to competition from wavelets (JPEG 2000) by hampering
good, healthy competition in the JPEG space. IJG drove the JPEG standard to
the lowest common denominator, because who is silly enough to compete with
free? (Other than the crazy folks at Pegasus that is. Don't get me wrong,
as Pegasus survived and thrived in this environment, so thanks very much.)
Meanwhile, JPEG 2000 is not gaining much traction for the exact reason that
your new JPEG won't. The vacuum that existed in 1989-1992 has been mostly
filled. Why didn't PNG supplant GIF even though GIF cost license fees? It
helps to be there first and be entrenched. Of course, JPEG 2000 has speed
issues compared to JPEG, but even if it didn't and had a 25% to 50%
compression advantage (which in my vast experience it does, and more on high
grey images), it still would face a very uphill battle because of the
world's "if it works, don't fix it" mentality, and no one can argue that
JPEG doesn't work, and work really superbly. JPEG 2000 and arithmetic coded
JPEG both offer advantages, and both will have trouble gaining any market
share (except that JPEG 2000 is dominating in the medical PACS environment
now).
So, just because IE is 90% of the browser market doesn't mean they are the
principal reason the internet was successful, it was just free and 'good
enough'. Same with Excel and spreadsheets. Word and word processors. IJG
and JPEG. The widespread use of a free product is only proof that it is
cheaper than something else, and that it drove away costlier products. Get
over yourself!
jack
Thomas Richter
> Michael Schöberl wrote:
>
>>>Here's an idea for you, and something ITU and ISO should probably care
>>>about: Standardize something like Open-DNG. An extensible,
>>>well-accepted, open, raw-image file format. Wouldn't that be something
>>>cool to have, based on the official grounds of ISO and ITU?
>>
>>but I'm sure Guido will protest as he considers Bayer to be inferior and
>>probably not even worth looking at it ... just google for guido foveon!
>>I guess he still compares 3 Mpixel Foveon (with 9M sensor elements) with
>>3M Bayer (with just 3M sensor elements) ...
>
>
> Michael,
> you have absolutely hit the point, congratulations, you seem to be
> intelligent :-)...
> I can hardly imagine anything more obsolete than this DNG initiative.
> Why establish an obsolete image capture technology which loses two thirds
> of essential image information in the first place in a distorting way?
You don't get the point. A raw image format should be able to store data
regardless of the sensor used to capture it. A standardization efford
should standardize for the needs of the customers instead of forcing a
specific technology. So you're starting from the wrong end. And I also
have the specific feeling that your strong arguing against one and pro
another technology is probably based on weak grounds. I haven't heard
good reasons here either.
> are not arbitrarily chosen, they are related to the only acceptable
> digital still camera technology available today.
> So what Foveon/Sigma need is better JPEG features, but not DNG.
Except that customers aren't asking for that. (-: Lossy image
compression, well, it's not really accepted in the in the high-end
market. Face it.
So long,
Thomas
Thomas Richter
> Thomas Richter wrote:
>
>> 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.
>
>
> I think you are confusing SSIM with multi-scale SSIM. The original SSIM
> was already a single scale algorithm, multi-scale SSIM came later.
I'm talking about the single-scale variant here.
>> Well, in the end, all what counts is whether it correlates well with the
>> mean opinion score.
>
>
> In the end sure, but in the meantime the concept of basing quality
> metrics on gratings experiments retarded the development of image
> quality metrics for a decade in my opinion.
Well, I don't know. This seems to be a bit simple. For example, things
like the CSF of the human eye are known for long, but SIM doesn't have
it. I rather see SIM as a compromise between having a metric that is
closer to the visual impression than PSNR and yet simple enough so an
algorithm can optimize for it. Try to write an image compression that
uses some advanced multi-channel approach to optimize quality - you're
pulling your hairs out! On the other hand, if you analyze what SIM does,
you'll find that it's also nothing but a low/high-pass filtering of the
image due to the windowing approach, so it's less different from
"classical" approaches than Simoncelli would possibly like to admit. /-:
>> 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.
>
> It has been independently compared against the Visible Difference
> Predictor algorithm BTW.
>
>> 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.
>
> SSIM wasn't part of either phase of course.
Yes, right.
So long,
Thomas
Jasen Betts
> Guido Vollbeding wrote:
>> > 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.
>>
>> As soon as it is in the public IJG library, it will go its way to success,
>> no doubt.
>
> 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.
If support is added to the IJG library (libjpeg) there is no need
to "go back" to add support. Dynamically linked programs will
inherit support as soon as the new library is installed, and
statically linked ones will only need to be re-compiled (no edits
to the sources needed).
> 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!
That is unless your software has been upgraded when you weren't looking :-)
Bye.
Jasen
Michael Schöberl
> of essential image information in the first place in a distorting way?
but that is *your* opinion ...
I'm working on real implementations and there are practical problems
(with 3-chip and probably with foveon as well) that make us use
bayer-patterns ...
> This is the most stupid idea you could accept.
it is wide-spread, well understood and there is a lot of know-how for
bayer-reconstruction ... I don't care about foveon beeing theoretically
better (however you define that) I just need to develop appropriate
solutions for our customers ...
but this is getting OT - EOD
concernig the compression:
I can see applications für JPEG2000 (for lossy compression) and some
need for maybe some different lossless algorithms ... I currently don't
see any reason for putting effort in implementing the new PEG+ algorithm.
But I'm open to better algorithms and I'll sure be watching the research
but maybe I'll skip that marketing babbling ...
bye,
Michael
Guido Vollbeding
>
> You don't get the point. A raw image format should be able to store data
> regardless of the sensor used to capture it. A standardization efford
> should standardize for the needs of the customers instead of forcing a
> specific technology. So you're starting from the wrong end. And I also
> have the specific feeling that your strong arguing against one and pro
> another technology is probably based on weak grounds. I haven't heard
> good reasons here either.
If you accept this inferior Bayer pattern technology, and can't tell the
difference, then this tells a lot about your image quality assessment
ability.
In my eyes this disqualifies you (and other crowd) for reasonable image
compression research. You could equally suggest to crop the 8 bits color
sample input to 4 bits to achieve a 50% data reduction. The Bayer pattern
approach is not much different: throwing away two thirds of essential
picture information in the first place. Nice compression tool, you may
say, that provides me with a 67% data reduction (in the RAW/DNG formats).
But that is not the objective of reasonable image compression - you have
missed the subject if you think so.
> > So what Foveon/Sigma need is better JPEG features, but not DNG.
>
> Except that customers aren't asking for that. (-: Lossy image
> compression, well, it's not really accepted in the in the high-end
> market. Face it.
The Sigma camera with the Foveon sensor is actually the only digital
camera on the market which writes only raw lossless images and no JPEG!
They use a proprietary .X3F format with lossless compression.
Note that I suggest a new seamless lossless coding mode in my JPEG+
proposal, so they could use this instead of their proprietary scheme.
That I mean with "better JPEG features".
The Foveon raw is a true-color format, not crippled as the Bayer pattern,
and thus does not require extra "DNG" efforts.
Foveon have spoken long before about "digital negatives" with their X3F
format. And that is a TRUE negative, not crippled!
Foveon are the "Man and God" of the digital age.
Guido Vollbeding
>
> the world ended up with Pegasus and IJG. Where did lossless rotate,
> lossless crop, region of interest decoding, thumbnail decoding, lossless
> hue, tint, brighten, contrast, and ELS Coder (ten years' before it now is
> supposed to be a good idea says you) JPEG come from first? Not IJG, but
> Pegasus, and soon copied.
Jack, you pervert the facts. Whose code is open and can thus be easily copied?
I can assure you that I invented the lossless rotation independently, just
because I couldn't find a solution anywhere else. Pegasus is not relevant to
me because they have no sources. But interestingly, after lossless rotation
provision in the IJG library, Pegasus also announced similar features.
So it's obvious who copied whom. And lossless crop, thumbnail decoding were
all introduced independently by IJG. As said, I don't care about Pegasus
because they have no sources.
By the way, you can read my article about lossless rotation derivation from
http://jpegclub.org . That may give you something to learn about JPEG and DCT.
> IJG's implementation of progressive JPEG killed
> the format on the launching pad. IJG's progressive decompression uses many
> times more memory than Pegasus which made things very difficult, and then
> what did we get from the browsers (yes, Netscape was IJG), was a
> decompression engine that waited until almost the whole 'progressive' file
> was downloaded to start decoding.
Jack, this shows that you are absolutely clueless here.
It was not Netscape, but Microsoft who ignored the progressive display
opportunities in their IE! I have version 4.78 of Netscape Communicator
of 2001 running here with perfect progressive JPEG display!
It is Microsoft's Internet Explorer which fails badly here.
So talk about Microsoft's ignorance...
But that is what you probably can't grasp because according to your world
picture Microsoft as a commercial company should do it right and not allow
bad application.
With such "expertise" as shown here by you and other folks it is not
surprising that you fail with your efforts.
Henry Ford was right - with such experts you can only fail. I'm not
going to fail, and I'm glad that I don't need to care about you "experts".
Guido Vollbeding
>
> By the way, you can read my article about lossless rotation derivation from
> http://jpegclub.org . That may give you something to learn about JPEG and DCT.
And here is a list of applications which provided the lossless rotation feature
after it was available with IJG:
http://jpegclub.org/losslessapps.html
Thomas Richter
>>You don't get the point. A raw image format should be able to store data
>>regardless of the sensor used to capture it. A standardization efford
>>should standardize for the needs of the customers instead of forcing a
>>specific technology. So you're starting from the wrong end. And I also
>>have the specific feeling that your strong arguing against one and pro
>>another technology is probably based on weak grounds. I haven't heard
>>good reasons here either.
>
>
> If you accept this inferior Bayer pattern technology, and can't tell the
> difference, then this tells a lot about your image quality assessment
> ability.
I *do not care* about the technology used in the camera, and a standard
should be able to support any technology in use. Hey, I do not even
*own* a digital camera. I bought one a couple of month ago, and returned
it a week later because the image quality left a lot of things to
deserve. (That was a Sony DSC-W5. Avoid the model.) The aparent sensor
noise was one problem of just many. The sensor *type* wouldn't even have
mattered for this camera much either. The optical system is just a more
important, and often underestimated weak point in the camera market
today. What does it help to have a 9 MPixel sensor of whatever type if
the optics is just weak. This specific model had color aperation, focus
problems and, due to the tiny sensor elements, wasn't very light
sensitive. If the exposure time in normal lighting conditions is 1/8th
of a second (compared to 1/100th for an analog film for comparable
conditions) then I personally don't want it. But that *still* means that
cameras like this are bought, sold and used, and it still means we
should care about. I don't want to buy one. And I still use my analog
camera. It's a cheap model, but the images are considerably better. And
I'm definitely not a professional photographer.
> In my eyes this disqualifies you (and other crowd) for reasonable image
> compression research. You could equally suggest to crop the 8 bits color
> sample input to 4 bits to achieve a 50% data reduction. The Bayer pattern
> approach is not much different: throwing away two thirds of essential
> picture information in the first place. Nice compression tool, you may
> say, that provides me with a 67% data reduction (in the RAW/DNG formats).
Guido, you still don't get the point. A standardization efford shouldn't
enforce people to use a specific technology. Even if I standardize a
lossless way to store Bayer pattern, I still wouldn't want to swap my
current analog camera with similar priced digital model. For photos of
the same quality, you've to pay a bit more on the digital market. And
the sensor pattern array - oh well, that's just one of many points,
likely not even the most important one.
> But that is not the objective of reasonable image compression - you have
> missed the subject if you think so.
>
>
>>>So what Foveon/Sigma need is better JPEG features, but not DNG.
>>
>>Except that customers aren't asking for that. (-: Lossy image
>>compression, well, it's not really accepted in the in the high-end
>>market. Face it.
>
>
> The Sigma camera with the Foveon sensor is actually the only digital
> camera on the market which writes only raw lossless images and no JPEG!
Of course you can write lossless Bayer pattern images. Where's the
problem with that? It requires a computation step to turn this into a
"visible" photo, but that can be either done by a simple algorithm in
the camera, or something smart and hand-tuned in your desktop, so it
makes pretty much sense to store this lossless. Even then, I'm not
totally convinced that Foveon is optimal. I'm not a digital sensor
expert (neither are you, though), but placing sensors like in a Foveon
sensor means of course that even *less* light arrives at each sensor
element, meaning again that the exposure time goes up, or the noise goes
up, neither of which is tolerable. The current race for "MegaPixel" is
actually much more of a problem than the choice of the pattern. Optical
systems cannot keep up with the "marketing resolution" of the sensor, so
why do that? Even a 5MPixel Foveon sensor doesn't have five megapixel
resolution behind an optical system, even if you like to make us think
so. It requires a high-end lense system to make use of this and to be
able to exploit the aparent higher resolution you like us to sell.
You're pretty much short-sighted. Your optical/mental system isn't right
in focus so to say. (-;
> They use a proprietary .X3F format with lossless compression.
> Note that I suggest a new seamless lossless coding mode in my JPEG+
> proposal, so they could use this instead of their proprietary scheme.
> That I mean with "better JPEG features".
> The Foveon raw is a true-color format, not crippled as the Bayer pattern,
> and thus does not require extra "DNG" efforts.
> Foveon have spoken long before about "digital negatives" with their X3F
> format. And that is a TRUE negative, not crippled!
> Foveon are the "Man and God" of the digital age.
Oh my.
So long,
Thomas
Guido Vollbeding
>
> > Foveon are the "Man and God" of the digital age.
>
> Oh my.
I hope you got it right:
"Man and God" here refers to "Mannes and Godowsky", the color film inventors,
see earlier post.
If you use an analog film camera, then that is the result of the
Mannes/Godowsky invention from 1935.
Nobody knows that, but that is the fact.
The Mannes/Godowsky ("Kodachrome") color film was the color photography
invention that lasted.
There were several other attempts, for example "Autochrome" which has some
similarity with Bayer patterns.
Autochrome didn't last, and Bayer won't last as well, so why bother?
Guido Vollbeding
>
> The current race for "MegaPixel" is actually much more of a problem
The actual race for "MegaPixel" is exactly the result of stupidity.
It is stupidity par excellence.
Those people can't find a more reasonable capture technique, and that's
why their only choice is to increase the "MegaPixel" count.
But it doesn't help, because regardless how many "Megapixels" they use,
the result is a crippled image with only one third of essential picture
information.
So why should we follow the most stupid people in the world?
You may do so if you want, but I won't.
> than the choice of the pattern.
There is NO choice of the pattern!
You must get away with the pattern!
Autochrome with its filtering approach disappeared in analog color
photography, but you can choose several other films today:
Kodachrome, Fujichrome, Agfachrome, etc.
They all share the same basic principle as introduced with Kodachrome in
1935: layered color.
In digital photography you have two options: 3-chip technology, as used
today in professional video, or layered color as introduced in 2002 by
Foveon.
The 3-way photography was also used in movie film before Kodachrome was
invented in 1935. But it has several disadvantages: expensive, bulky,
registration (color alignment) problems. See for example:
http://www.widescreenmuseum.com/oldcolor/technicolor6.htm
The Kodachrome film 1935 solved all these problems.
There were also attempts to do 3-way still photography - about hundred
years ago by Russian photographer Sergei Mikhailovich Prokudin-Gorskii.
The results look very nice for this age:
http://www.loc.gov/exhibits/empire/
mihai cartoaje
Here, Thomas/ISO/SC29, please measure for me, what do you think about
these ideas...
(I am top-posting because in Links it is hard to delete text.)
Thomas Richter
> http://groups.google.com/group/media-player/browse_thread/thread/75e0134caaf6a8ed/
>
> Here, Thomas/ISO/SC29, please measure for me, what do you think about
> these ideas...
Well, for that I first of course need to read them. (-; To give a very
quick review, the poster mentiones that this is SPIHT related and a
Daubchies 4,4 spec. the Haar wavelet?
Well, SPIHT always performed comparable with JPEG2000 on the
measurements I've done, and the ideas are approximately comparable with
the additional point of SPIHT having an inter-plane correlation JPEG2000
sacrifized for higher flexibility. If this is the case, then there's
probably not too much of a new idea in it.
What I think is worth looking at are image compression algorithms that
go beyond the "linear filtering plus context modelling" approach.
All that, with proper warnings applied, I haven't checked the code (yet).
So long,
Thomas
Marco Al
> For example, things
> like the CSF of the human eye are known for long, but SIM doesn't have
> it.
What is known that CSF measurements for sine gratings can be used very
well to predict your sensitivity to noise when you are watching sine
gratings ;)
From that you can't really derive the way the HVS works though, it's a
result of how the HVS works ... and there are a lot of different
conceivable ways which result in those measurements for sine gratings.
The case for a local frequency space as a good way to build a HVS model
is pretty weak, it's just very convenient because you get an easy
mapping to the sine grating experiments.
I think a multi-resolution edge transform gives a far more useful
representation (wavelets are close to a multi-resolution edge
representation, as long as you don't decompose the high pass bands ...
which you generally don't).
> I rather see SIM as a compromise between having a metric that is
> closer to the visual impression than PSNR and yet simple enough so an
> algorithm can optimize for it. Try to write an image compression that
> uses some advanced multi-channel approach to optimize quality - you're
> pulling your hairs out! On the other hand, if you analyze what SIM does,
> you'll find that it's also nothing but a low/high-pass filtering of the
> image due to the windowing approach, so it's less different from
> "classical" approaches than Simoncelli would possibly like to admit. /-:
I don't see how windowing + error pooling is at all like low/high pass
filtering, but apart from that ... one man's high pass filter is another
man's edge detector. The classical approaches give special significance
to oscillatory patterns rather than edges.
Marco
Thomas Richter
> Thomas Richter wrote:
>
>> For example, things like the CSF of the human eye are known for long,
>> but SIM doesn't have it.
>
>
> What is known that CSF measurements for sine gratings can be used very
> well to predict your sensitivity to noise when you are watching sine
> gratings ;)
True enough, but if we assume that the human eye is approximately linear
for small amplitude derivations (and given Taylor's formula,
*everything* smooth is approximately linear), we can decompose
edges/structures into linear superpositions of sine gratings. Of course,
we then have masking phenomenas, so "linear" superposition is not quite
what's going on here.
Another problem of SIM (the single scale one, I mean) is that it misses
one aparent feature of natural images, namely (limited) scale invariance.
> From that you can't really derive the way the HVS works though, it's a
> result of how the HVS works ... and there are a lot of different
> conceivable ways which result in those measurements for sine gratings.
> The case for a local frequency space as a good way to build a HVS model
> is pretty weak, it's just very convenient because you get an easy
> mapping to the sine grating experiments.
Well, it maps to the one classical tool of signal processing, namely
Fourier analysis. Which isn't all, of course, but the first hammer you
try on what looks like a nail.
> I think a multi-resolution edge transform gives a far more useful
> representation (wavelets are close to a multi-resolution edge
> representation, as long as you don't decompose the high pass bands ...
> which you generally don't).
In so far at least as it is one of the basic features of the sensors
(ehem) within the human eye. Edge detection, moving edge detection by
coupled inhibition.
>> I rather see SIM as a compromise between having a metric that is
>> closer to the visual impression than PSNR and yet simple enough so an
>> algorithm can optimize for it. Try to write an image compression that
>> uses some advanced multi-channel approach to optimize quality - you're
>> pulling your hairs out! On the other hand, if you analyze what SIM
>> does, you'll find that it's also nothing but a low/high-pass filtering
>> of the image due to the windowing approach, so it's less different
>> from "classical" approaches than Simoncelli would possibly like to
>> admit. /-:
>
>
> I don't see how windowing + error pooling is at all like low/high pass
> filtering, but apart from that ... one man's high pass filter is another
> man's edge detector. The classical approaches give special significance
> to oscillatory patterns rather than edges.
Well, if you run a windowing algorithm, and then measure the "structural
similarity" on the window'ed, normalized data as SIM does, it is easy to
see that this is just the mean square error on a high-pass filter. The
luminance part is a low-pass filtered image where the filter size is the
size of the window. So it's to some degree also "channel building and
error pooling". The motivation is probably different. Also, the model
has a couple of free parameters that have to be choosen reasonably - the
window size. This should be in some relation to the viewing distance of
a typical observer (as in: Which structures am I able to see? What is
"average luminance").
Anyhow. I don't want to talk bad about it, but its probably less
original and has problems by itself. It cannot be much worse than PSNR
on the other hand. (-;
So long,
Thomas
Jack Berlin
perverted the facts!
You said: "I don't care about Pegasus because they have no sources."
Perhaps a huge case of "not invented here" syndrome? You sure it's not the
Independent JPEG Individuals? Note that Henry Ford didn't give away his
cars my friend. Believe me that Pegasus is quite interested in whatever
anyone does in image compression and if we find a good idea we are always
happy to use it if there are no IP issues. However, I can't think of
anything much we have ever learned from IJG code, open or not, but we
probably did learn a few things from Tom's implementation in the early days.
I never suggested you copied our code, just our ideas. We innovated because
we were commercially motivated to do so. You have established the value of
your services at zero, and we think we (and you) are worth more than that.
I am sure you are a great programmer, very knowledgeable in JPEG and very
pivotal in the support of the IJG source code that is used by so many
people. I would be happy to shake your hand about that.
You posted your note on this newsgroup about lossless rotate of JPEG on
5/14/97. Pegasus first shipped a working DLL with lossless JPEG rotate on
7/16/96. According to your jpegclub.org link, "Lossless rotation and
related transforms have been added to the IJG software with release 6b of
27-Mar-1998." And if I remember correctly this was only after you and Tom
had quite the public argument over how to implement.
Other Pegasus release dates:
requantize JPEG 8/7/97
combine two jpeg's (join) 3/20/98
lossless crop 3/30/98
overlay two jpeg's (merge) 4/20/98
brightness/contrast/color adjust 6/26/98
Let us know if we can show you how to reduce the memory use in the IJG
progressive JPEG decoder. Seriously, it killed the format. Our decoder
uses many times less memory, and in Win 95 this was a real issue. Your
Netscape 4.78 in 2001 was another case of "too late". They offered
progressive JPEG support starting in their version 2. We offered a Netscape
plugin for years that worked correctly, but we, of course, did not get much
market penetration.
Thanks for the not so nice wishes for our success. We are doing fine, thank
you very much, and what IJG does or doesn't do has no influence whatsoever.
On the other hand I have no such ill wishes for you and I wish you all the
success in the world. It won't be financial, but whatever it is that makes
you feel successful, I hope it happens. I even hope the new JPEG extension
takes hold, though I have my doubts, because new formats provide financial
opportunities to Pegasus.
But, I do want facts posted here, not distortions.
Good luck,
jack
--
http://www.pegasusimaging.com/ - Pegasus - The BETTER JPEG People!
--
"Guido Vollbeding" <gu...@jpegclub.org> wrote in message
news:44910BEB...@jpegclub.org...
Guido Vollbeding
the idea for the lossless rotation feature arose because I had a practical
need for it, and I worked under Linux, so Pegasus was no option.
And don't get me wrong: I'm not *wishing* you failure, I just see the
reality that you failed with your JPEG-2000 approach. And your error is
that you continue this mistake and don't stop it. That's why you *must*
fail eventually! I have nothing against commercial success, if it is
based on reasonable technology. But JPEG-2000 is not reasonable and is
inferior compared to DCT based JPEG. With my JPEG-Plus proposal I also
intend to "enable new marketing and business activities for the benefit
of a wide range of participants". That is especially for you, because
you can offer updates and new applications to your customers.
Everybody else can easily see that the JPEG-2000 approach did not hold
what the marketing claims. When will you realize this and draw the
conclusions? So that is why you will fail, and I only point it out to
you and show a reasonable alternative which cannot fail, because it
builds on established success. Other people can easily see this, only
you are blind to get the message and to react appropriately:
So that's what I tell you: If you want success, then you must stop the
mistaken JPEG-2000 route, and set on a more reasonable alternative.
Otherwise you will be doomed to failure.
It's *your* choice.
I don't need to care about you, because I can go the way without you.
But I don't wish you failure, that's why the hints.
Michael Schöberl
> today in professional video, or layered color as introduced in 2002 by
> Foveon.
sorry - but that is just plain wrong ... there are real (tm) high-end
cameras with bayer-sensors as well
and again - you do not throw away any *information* that comes to your
sensor - your optical path has an optical low pass filter that prevents
aliasing ... I'm sure you've heard of the sampling theorem before?
You throw away some energy with your colour-filters (and get a lower
sensitivity compared to b/w sensors) but that does not influence the
information ... but that happens with foveon as well
and certainly noone (well - some consumer marketing guys might) claims
to get a resolution of 4 MPixel out of a 4 MPixel bayer sensor ... but
I'm sure it is more than just 1 MPixel
I know - there is a consumer market where cameras are just cheap and
offer reduced image quality for a reasonable price ... looks like the
price/quality ratio is good enough for people to buy those
bye,
Michael
mihai cartoaje
version.
Jack Berlin
Actually, Pegasus stopped participating in the standards process many years'
ago as it was so dominated by bigger companies on a mission for their own
causes that we decided we could either pay to have no real say, or not pay
and have no say. We are content to follow in this case.
We support standards based image compression that is commercially used.
Period. We support JPEG, JPEG 2000, JPEG LS, Lossless JPEG, JPIP, JBIG 2
and WSQ, and probably others. We support JPEG 2000, starting many years'
ago, because certain large customers demanded it. If the demand shows up
for you JPEG + addition, we will support it too. We are not biased in any
way, and try to advise our customers to what they need without the 'DCT vs
wavelet' bigotry. A format's success or failure won't lay at our feet, just
like JPEG's success is not attributed to IJG. It will depend on whether
there is a commercial need or not. Remember, just because your code is
free, the applications using IJG are mostly not free, and the application's
success is based on profit.
Please let me know if you have any further questions.
Best wishes,
jack
--
Pegasus - BETTER DIGITAL IMAGING!
http://www.pegasusimaging.com/
"Guido Vollbeding" <gu...@jpegclub.org> wrote in message
news:44926406...@jpegclub.org...
Marco Al
> and again - you do not throw away any *information* that comes to your
> sensor - your optical path has an optical low pass filter that prevents
> aliasing ... I'm sure you've heard of the sampling theorem before?
I'm loathe to backup Guido, but the Nyquist-Shannon sampling theorem
doesn't apply to image capture ... a truly critically sampled image
would look like crap, it would have ringing all over the place.
What some (all?) bayer sensor cameras have are blur filters (optical
diffusers) in front of the sensor (a lens with the exactly correct
spherical aberration could work too). Because of the trade off between
removing aliasing/moire and resolution I would guess most cameras leave
some aliasing/moire in place though.
It would be nice if the sampling theorem applied. Demosaicing would be
as simple as using a sinc filter to resample the different color planes
... instead it is an ill posed inverse problem.
Marco
mihai cartoaje
h0 = 1/2 1/2 1/2 1/2
h1 = -1/sqrt(2) 1/sqrt(2) 0 0
h2 = -1/2 -1/2 1/2 1/2
h3 = 0 0 -1/srtq(2) 1/sqrt(2)
Setting h1' = (h1 + h3) / sqrt(2),
h1' = -1/2 1/2 -1/2 1/2
and setting h3' = (-h1 + h3) / sqrt(2),
h3' = 1/2 -1/2 -1/2 1/2
and setting h1'' = 2/sqrt(5) h1' - 1/sqrt(5) h2,
h1''= -1/sqrt(20) 3/sqrt(2) -3/sqrt(2) 1/sqrt(20)
and setting h2' = 1/sqrt(5) h1' + 2/sqrt(5) h2,
h2' = -3/sqrt(20) -1/sqrt(20) 1/sqrt(20) 3/sqrt(20)
we get the transformation,
h0 = 1/2 1/2 1/2 1/2
h1''= -1/sqrt(20) 3/sqrt(20) -3/sqrt(20) 1/sqrt(20)
h2' = -3/sqrt(20) -1/sqrt(20) 1/sqrt(20) 3/sqrt(20)
h3' = 1/2 -1/2 -1/2 1/2
This modification can be applied at all levels of the transformation.
It can be implemented using O(log(n)) extra memory when reconstructing
the image (my codec writes bits in the reverse order they are read, so
when compressing it has to keep a buffer of all the written bits). I
posted a test codec and sample image compressed 10:1 at,
http://groups.google.com/group/media-player
I also have a version which handles non-square images if it is more
convenient.
mihai cartoaje
c^1_2j = ( c^0_2j + c^0_(2j+1) ) /sqrt(2)
c^1_(2j+1) = ( - c^0_2j + c^0_(2j+1) ) / sqrt(2)
for i > 1,
c^i_(2^i j) = ( c^(i-1)_(2^i j) + c^(i-1)_(2^i j + 2^(i-1)) / sqrt(2)
c^i_(2^i j + 3*2^(i-2)) = (- c^(i-1)_(2^i j + 2^(i-2)) +
c^(i-1)_(2^i j + 3*2^(i-2)) ) / sqrt(2)
t1^i_j = ( c^(i-1)+(2^i j + 2^(i-2)) + c^(i-1)_(2^i j + 3*2^(i-2)) ) /
sqrt(2)
t2^i_j = ( -c^(i-1)_(2^i j) + c^(i-1)_(2^i j + 2^(i-1))) / sqrt(2)
c^i_(2^i j + 2^(i-2)) = (2 t1^i_j - t2^i_j) / sqrt(5)
c^i_(2^i j + 2^(i-1)) = t1^i_j / sqrt(5)
+ 2 t2^i_j /sqrt(5)
mihai cartoaje
> t1^i_j = ( c^(i-1)+(2^i j + 2^(i-2)) + c^(i-1)_(2^i j + 3*2^(i-2)) ) /
> sqrt(2)
I meant,
t1^i_j = ( c^(i-1)_(2^i j + 2^(i-2)) + c^(i-1)_(2^i j + 3 * 2^(i-2)) )
/ sqrt(2)