Science and Technology news... :: View topic

V. van Beveren · Guest

Hey everyone,

I>ve noticed MS has published a 'JPEG successor' called HD Photo. I was
wondering why would there be a need for such a thing. What are the
current shortcommings of JPEG? I know JPEG has some patent 'issues',
but other than that I always believed its a pretty competent format.

Now, I>m not asking this without some additional agenda. I>ve developed
a transform which can be used for image-compression. Its a modified
version hair transform, esepcially designed to handle gradients.

Unfortunatly my first tests compress only to about 150% (using a
DEFLATE on the output of the transform) the size of a JPEG having
similar quality, but then again, I did not spend much time optimizing
the whole thing. There may be room for lots of improvements, or it
might just not be as suitable as a DCT :).

Information about a 1D version of the transform can be found on my blog
here:
http://vanbeveren.byethost13.com/?p=33
Inlcuding a download of the audiocompressor written in Java. Note that
the transform was never meant for audio, so doesn>t perform as good as
MP3, but maybe it has uses.

So I was also wondering:
- Would it actually be useful to make a JPEG successor (using a lossy
compression scheme) - looking at patent issues and maybe outdated
feature set?
- If one would make a successor to JPEG, what additional features
should it have?

Thanks,
Vincent

Industrial One · Guest

Thomas, is JPEG2000 the successor to the original JPEG? I kept hearing
that it>s experimental and should be avoided, that it fucks up the
edges of an image with ringing artifacts. Would you recommend me using
it?

As for measuring technical quality for development of AIC, PSNR SUCKS
and I can>t see how it>s a reliable method to determine quality in any
way. I tried it with these 2 nearly-identical anime videos, trying to
find out what exactly is different (scenes that match were rated 0% by
the PSNR algorithm) and 10,000 frames later it kept reporting high
levels of noise. After 20 trials of copy-pasting the frame of video#2
onto video#1 on MSPaint, I noticed that the last vertical 1x384-pixel
edge of the video was slightly tinted with green...

I suggest you have real people judge how presentable an image is
instead of a retarded algorithm.

Thomas Richter · Guest

V. van Beveren wrote:

[quote]I>ve noticed MS has published a 'JPEG successor' called HD Photo.
[/quote]
No, it will be called JPEG-XR. HDPhoto is the internal name for it.

[quote]I was
wondering why would there be a need for such a thing. What are the
current shortcommings of JPEG? I know JPEG has some patent 'issues', but
other than that I always believed its a pretty competent format.
[/quote]
Well, the reasons are debatable. MS made the following points: First of
all, *lossy* JPEG is limited to either 8 bit per channel, or 12 bit per
channel. Modern digital photography can take shots at beyond 8 bit per
pixel, enabling users something called "HDR photography", i.e. instead
of an "ready to view image", you shoot a "digital negative" which, after
applying a suitable color transformation depending on the intention of
the photographer, becomes an image to be viewed on your monitor at 8bpp.

For this intention, *8bpp* JPEG would not be sufficient - for today>s
cameras, 12bpp JPEG - which is also standardized - would be fully
sufficient - that>s about the current sensor resolution.

A second argument is that JPEG-XR defines the reconstruction process bit
by bit, unlike JPEG which allows some derivations in the inverse DCT
process, and thus not all decoders will reconstruct your codestream to
the identical image. Furthermore, this format integrates lossless
compression as a special case of lossy compression.

The reason why I think this is debatable is that a) there is a format
already that does that - JPEG2000, b) "raw" photography is already in
the market, though not standardized by vendors, potentially
intentionally to bind consumers to their products, c) storage data is
cheap, so why bother, and d) "baseline" JPEG-XR without any additional
improvements made by vendors does not perform very well, as shown by
independent tests. On the pro-side, you possibly have it already on your
desktop, and MS will keep pushing it, so it will become implemented in
cameras, unlike JPEG2000.

That is, if *all* you care are *images* as such, there is no problem to
be solved anymore. However, if you need more than that, for example,
transmit images dynamically, pull out scales, recode them, ensure
minimal errors under processing, etc, then bets are open again. That is,
the demands & requirements move actually away from the sole target of
*compressing* images, as rather *processing* them in this domain
efficiently.

[quote]Now, I>m not asking this without some additional agenda. I>ve developed
a transform which can be used for image-compression. Its a modified
version hair transform, esepcially designed to handle gradients.

Unfortunatly my first tests compress only to about 150% (using a DEFLATE
on the output of the transform) the size of a JPEG having similar
quality, but then again, I did not spend much time optimizing the whole
thing. There may be room for lots of improvements, or it might just not
be as suitable as a DCT :).
[/quote]
Look, I>m sorry to disappoint you, but I doubt this design is quite up
to date. The statistical model implied by deflate is not at all suitable
for image compression. Deflate is fine for sequential text processing,
but not for a 2D image, besides it is not at all designed to do
processing in the compressed domain. I would recommend to go into some
reading how and why the JPEG family performs, and into some recent
experimental codecs using edgelets, curvelets and similar techniques.
There>s a whole conference on things like that going on actually next
week where stuff like that is discussed.

[quote]So I was also wondering:
- Would it actually be useful to make a JPEG successor (using a lossy
compression scheme) - looking at patent issues and maybe outdated
feature set?
[/quote]
There is already one, and now a second one. And, we - the JPEG - are
looking for a third one, even though this might not happen within years
to come, and our intention with that is more to define seriously what a
"good image" actually will be. PSNR is *not* a good metric.

[quote]- If one would make a successor to JPEG, what additional features should
it have?
[/quote]
Well, for that, the JPEG released a "call for contributions &
requirements" for "AIC", Advanced Image Coding. Should be public, or
become public soon, on www.jpeg.org. It>s all in there. I>m not
repeating it all here. Check for example the introduction of the
JPEG2000 standard to get some of the goals we had for that.

So long,
Thomas

V. van Beveren · Guest

[quote]I>ve noticed MS has published a 'JPEG successor' called HD Photo.

No, it will be called JPEG-XR. HDPhoto is the internal name for it.
[/quote]
So, it will be standardized by the JPEG? I didn>t know, I thought it
was a compatitor of JPEG 2000.

[quote]I was wondering why would there be a need for such a thing. What are the
current shortcommings of JPEG? I know JPEG has some patent 'issues', but
other than that I always believed its a pretty competent format.

For this intention, *8bpp* JPEG would not be sufficient - for today>s
cameras, 12bpp JPEG - which is also standardized - would be fully sufficient
- that>s about the current sensor resolution.
[/quote]
Yes, I would enable higher bpp rates. I thought about 12bpp, maybe even
16bpp, though that is probably only usefull for medical and scientific
imaging.

[quote]
A second argument is that JPEG-XR defines the reconstruction process bit by
bit, unlike JPEG which allows some derivations in the inverse DCT process,
and thus not all decoders will reconstruct your codestream to the identical
image. Furthermore, this format integrates lossless compression as a special
case of lossy compression.
[/quote]
The transform I have come up with its also defined bit by bit, so every
decoder must decode it exactly in the same way. There are no
floating-point operations in it.

[quote]
The reason why I think this is debatable is that a) there is a format already
that does that - JPEG2000, b) "raw" photography is already in the market,
though not standardized by vendors, potentially intentionally to bind
consumers to their products, c) storage data is cheap, so why bother, and d)
"baseline" JPEG-XR without any additional improvements made by vendors does
not perform very well, as shown by independent tests. On the pro-side, you
possibly have it already on your desktop, and MS will keep pushing it, so it
will become implemented in cameras, unlike JPEG2000.
[/quote]
Yes, MS would do that. Thats why I though about creating a
compatitor... a standard by MS, is not really a standard at all... (I
think).

[quote]That is, if *all* you care are *images* as such, there is no problem to be
solved anymore. However, if you need more than that, for example, transmit
images dynamically, pull out scales, recode them, ensure minimal errors under
processing, etc, then bets are open again. That is, the demands &
requirements move actually away from the sole target of *compressing* images,
as rather *processing* them in this domain efficiently.
[/quote]
Could you eleborate on this a bit. What do you mean with transmit
images dynamically?

[quote]Unfortunatly my first tests compress only to about 150% (using a DEFLATE on
the output of the transform) the size of a JPEG having similar quality, but
then again, I did not spend much time optimizing the whole thing. There may
be room for lots of improvements, or it might just not be as suitable as a
DCT :).

Look, I>m sorry to disappoint you, but I doubt this design is quite up to
date. The statistical model implied by deflate is not at all suitable for
image compression. Deflate is fine for sequential text processing, but not
for a 2D image, besides it is not at all designed to do processing in the
compressed domain.
[/quote]
The DEFLATE algorithm is used to encode the residual frequencies. PNG
uses it too, though it doens>t work in the frequency domain. The
encoder roughly works like this?:

Currently the encoder works liek this (but its nots really just an
initial version): The image is chopped up into little blocks (say 4x4,
or 8x8, but I tried up to 128x128). This transform is lossless, and
transforms into some kind of frequeny domain. Then the image is
quantinized, and the LSB are thrown away. Residual frequency blocks are
futher reduced by comparing and substracting previously encoded blocks.
The final signal is futher compressed with the DEFLATE algorithm. I
tried a normal Huffman, but it didn>t perform as well as I hoped. I was
also thinking about using rice encoding.

I>m still working on it, maybe adding a window, and using overlaying to
recude the errors near the borders of the blocks. I also tried to
transform te entire image in one transform, but it was very hard to
manage. The advantage though is that there where no blocks, and no
block artifacts.

In everything I want to keep the encoder complexity to a managable
state. I>m not a mathematicien, but the concept was something I just
thought of, so its worth a try. I think it could perform very well on
photos and maybe even video. But its hard for me to get the maximum out
of it, or even assess in which conditions (if at all) it performs
better than a DCT. But I do think it has potential, becuase it doesn>t
handle the image as a set of sines, but as gradients and edges.

[quote]
There is already one, and now a second one. And, we - the JPEG - are looking
for a third one, even though this might not happen within years to come, and
our intention with that is more to define seriously what a "good image"
actually will be. PSNR is *not* a good metric.

- If one would make a successor to JPEG, what additional features should it
have?

Well, for that, the JPEG released a "call for contributions & requirements"
for "AIC", Advanced Image Coding. Should be public, or become public soon, on
www.jpeg.org. It>s all in there. I>m not repeating it all here. Check for
example the introduction of the JPEG2000 standard to get some of the goals we
had for that.
[/quote]
I will. If you are interested in the transform I can send you the
sourcecode.

Thanks for your reply Thomas.

Greetings,
Vincent

V. van Beveren · Guest

Sorry for all the typoes, I should have re-read it.

Thomas Richter · Guest

Industrial One wrote:
[quote]Thomas, is JPEG2000 the successor to the original JPEG?
[/quote]
Yes.

[quote]I kept hearing
that it>s experimental and should be avoided,
[/quote]
No, and no. It>s neither experimental, nor should it be avoided. What
you should avoid are the not-so-well-done reference implementations that
barely do the absolute minimum, or close to the absolute minimum. If
you>ve been in the movies lately and went to a rather modern theater,
you>ve seen JPEG2000 in action already.

[quote]that it fucks up the
edges of an image with ringing artifacts. Would you recommend me using
it?
[/quote]
Yes.

[quote]As for measuring technical quality for development of AIC, PSNR SUCKS
and I can>t see how it>s a reliable method to determine quality in any
way.
[/quote]
Sure enough, we all know. And that also is part of the problem with the
JPEG2000 implementations you find out in the wild - most of them are
just optimal to PSNR, and optimize for PSNR - which is just the wrong
thing - as you say.

[quote]I tried it with these 2 nearly-identical anime videos, trying to
find out what exactly is different (scenes that match were rated 0% by
the PSNR algorithm) and 10,000 frames later it kept reporting high
levels of noise. After 20 trials of copy-pasting the frame of video#2
onto video#1 on MSPaint, I noticed that the last vertical 1x384-pixel
edge of the video was slightly tinted with green...
[/quote]
*Video* quality evaluation is just another thing, it>s even more
complex, because you also have temporal aspects to consider.

[quote]I suggest you have real people judge how presentable an image is
instead of a retarded algorithm.
[/quote]
That is called "subjective testing", and is of course a very important
tool we>re also applying in JPEG-XR testing, for example. The short
answer is that under these tests, optimized JPEG2000 performs best, and
unoptimized JPEG-XR performs worst. For the long story, you would need
to read our (Chaker and mine) paper, came out in the SPIE conference
this year.

However, doing subjective tests is only half the job done - how do you
write an algorithm that optimizes for this definition? You surely do not
want to work on your digital camera to tune all the parameters manually
to make the image look good - that should be done by an algorithm. And
that>s exactly where the problem starts: Without a mathematical
approximation of "quality", one cannot implement an algorithm that
avoids image artifacts.

So long,
Thomas

Thomas Richter · Guest

V. van Beveren wrote:
[quote]I>ve noticed MS has published a 'JPEG successor' called HD Photo.

No, it will be called JPEG-XR. HDPhoto is the internal name for it.

So, it will be standardized by the JPEG? I didn>t know, I thought it was
a compatitor of JPEG 2000.
[/quote]
Yes, it actually *is* under standardization of the JPEG (more or less
"next week", to be precise, as that>s when the next meeting is taking
place). In that sense, it is a competitor of JPEG2000.

[quote]I was wondering why would there be a need for such a thing. What are
the current shortcommings of JPEG? I know JPEG has some patent
'issues', but other than that I always believed its a pretty
competent format.

For this intention, *8bpp* JPEG would not be sufficient - for today>s
cameras, 12bpp JPEG - which is also standardized - would be fully
sufficient - that>s about the current sensor resolution.

Yes, I would enable higher bpp rates. I thought about 12bpp, maybe even
16bpp, though that is probably only usefull for medical and scientific
imaging.
[/quote]
It surely is, but as said, that field is already taken by JPEG2000
(medical for example). Even then, one can do images with up to 16000
components, for example for spectral data or sensing applications.

[quote]The reason why I think this is debatable is that a) there is a format
already that does that - JPEG2000, b) "raw" photography is already in
the market, though not standardized by vendors, potentially
intentionally to bind consumers to their products, c) storage data is
cheap, so why bother, and d) "baseline" JPEG-XR without any additional
improvements made by vendors does not perform very well, as shown by
independent tests. On the pro-side, you possibly have it already on
your desktop, and MS will keep pushing it, so it will become
implemented in cameras, unlike JPEG2000.

Yes, MS would do that. Thats why I though about creating a compatitor...
a standard by MS, is not really a standard at all... (I think).
[/quote]
It is a standard because it>s standardized - MS brought that up to the
committee, we>re doing it. As always, the standard is not coming out
exactly as it came in, we had to tweak a bit here and there, but there
you go...

[quote]That is, if *all* you care are *images* as such, there is no problem
to be solved anymore. However, if you need more than that, for
example, transmit images dynamically, pull out scales, recode them,
ensure minimal errors under processing, etc, then bets are open again.
That is, the demands & requirements move actually away from the sole
target of *compressing* images, as rather *processing* them in this
domain efficiently.

Could you eleborate on this a bit. What do you mean with transmit images
dynamically?
[/quote]
Browsing interactively. That is, you do have a very huge image on a
server, and you want a user to pull out a part of the image in a lower
resolution or smaller scale over the internet without having to transmit
all of the data. Think of "Google Earth" like an example. JPEG2000 does
allow for such operations, and that>s an issue in medical applications
where you usually have large images (X-rays etc.). Another part of the
JPEG2000 standard defines the protocol by which you can do that (in
addition to how to encode the image), and the image compression is done
in such a way to make this easy. "Deflate" is very ill-suited for this
because you cannot pull out a "piece in the middle". JPEG2000 "EBCOT" is.

[quote]Look, I>m sorry to disappoint you, but I doubt this design is quite up
to date. The statistical model implied by deflate is not at all
suitable for image compression. Deflate is fine for sequential text
processing, but not for a 2D image, besides it is not at all designed
to do processing in the compressed domain.

The DEFLATE algorithm is used to encode the residual frequencies. PNG
uses it too, though it doens>t work in the frequency domain.
[/quote]
Who said that PNG is a good compressor - it isn>t. It>s just an easy one.

[quote]The encoder
roughly works like this?:

Currently the encoder works liek this (but its nots really just an
initial version): The image is chopped up into little blocks (say 4x4,
or 8x8, but I tried up to 128x128).
[/quote]
Note that on a lossy transform you>ll then get artifacts at the
boundaries. That>s why JPEG2000 uses wavelets - no blocks in the image
domain - and JPEG-XR uses an overlap-transform that goes across block
boundaries. Don>t do that, people did that in the 80' and 90', ancient
technology.

[quote]This transform is lossless, and
transforms into some kind of frequeny domain. Then the image is
quantinized, and the LSB are thrown away.
[/quote]
Why only allow a division by a power of 2? This type of quantization is
usually too coarse to give you a good file size control.

[quote]Residual frequency blocks are
futher reduced by comparing and substracting previously encoded blocks.
The final signal is futher compressed with the DEFLATE algorithm.
[/quote]
That way, you have no direct control over the output rate. For example,
in JPEG2000 you can tell the encoder to make the file so-and-so bytes
large, and it will hit that rate by a precision of a couple of 100
bytes. You cannot do that with an algorithm like DEFLATE unless you
DEFLATE over and over again while altering the quantization.

[quote]I
tried a normal Huffman, but it didn>t perform as well as I hoped. I was
also thinking about using rice encoding.
[/quote]
DEFLATE is not your method of choice. Use a context-based first-order
adaptive entropy encoder. If it must be, adaptive huffman, but
arithmetic works better.

[quote]I>m still working on it, maybe adding a window, and using overlaying to
recude the errors near the borders of the blocks. I also tried to
transform te entire image in one transform, but it was very hard to
manage. The advantage though is that there where no blocks, and no block
artifacts.
[/quote]
So why do blocks? There>s an entire class of transforms out that do that.

[quote]In everything I want to keep the encoder complexity to a managable
state. I>m not a mathematicien, but the concept was something I just
thought of, so its worth a try. I think it could perform very well on
photos and maybe even video. But its hard for me to get the maximum out
of it, or even assess in which conditions (if at all) it performs better
than a DCT.
[/quote]
Well, that>s part of the problem - to really achieve well, you need a
stronger background than you currently have. If you like this field, I>d
suggest to work on this - really, not personal, I>m only saying that if
you want to do better, you need to know more.

[quote]But I do think it has potential, becuase it doesn>t handle
the image as a set of sines, but as gradients and edges.
[/quote]
Edgelets? Curvelets? Fractal compression? (-; You>re not the first here,
you know... (-; not at all.

[quote]Well, for that, the JPEG released a "call for contributions &
requirements" for "AIC", Advanced Image Coding. Should be public, or
become public soon, on www.jpeg.org. It>s all in there. I>m not
repeating it all here. Check for example the introduction of the
JPEG2000 standard to get some of the goals we had for that.

I will. If you are interested in the transform I can send you the
sourcecode.
[/quote]
Too loaded with work. Did JPEG work the last two days, will do science
on the ICIP (image compression conference) next week, there>s not much
time left except for sleeping & eating this week. (-:

So long,
Thomas

Industrial One · Guest

On Oct 10, 4:44 pm, Thomas Richter <t...@math.tu-berlin.de> wrote:
[quote]No, and no. It>s neither experimental, nor should it be avoided. What
you should avoid are the not-so-well-done reference implementations that
barely do the absolute minimum, or close to the absolute minimum. If
you>ve been in the movies lately and went to a rather modern theater,
you>ve seen JPEG2000 in action already.
[/quote]
Ok, what application would you recommend. Is there a DLL that I can
integrate into MSPaint? About movie tehatres, don>t they use MPEG2?

[quote]*Video* quality evaluation is just another thing, it>s even more
complex, because you also have temporal aspects to consider.
[/quote]
Yeah, but seriously: a single tinted line on the left, that>s like
0.5% of the video. According to PSNR, that somehow constitutes high
decibels of noise? How would you evaluate quality at all with that
dipshitted algorith?

[quote]That is called "subjective testing", and is of course a very important
tool we>re also applying in JPEG-XR testing, for example. The short
answer is that under these tests, optimized JPEG2000 performs best, and
unoptimized JPEG-XR performs worst. For the long story, you would need
to read our (Chaker and mine) paper, came out in the SPIE conference
this year.
[/quote]
Link?

[quote]However, doing subjective tests is only half the job done - how do you
write an algorithm that optimizes for this definition? You surely do not
want to work on your digital camera to tune all the parameters manually
to make the image look good - that should be done by an algorithm. And
that>s exactly where the problem starts: Without a mathematical
approximation of "quality", one cannot implement an algorithm that
avoids image artifacts.
[/quote]
No, I meant, try whatever new JPEG algorithm on an image and do
subjective tests to determine the efficiency. Build another algorithm
that uses a different transform method and do subjective tests on that
one -- if the efficiency is better than the previous, trash the
previous.

As for mathematically defining quality, that>s a hard one. I guess
someone can program an app to ignore some regions with minor
differences in chroma that wouldn>t be noticed by the eye and focus on
regions that really stand out. But the success of that project would
probably be directly tied with psycho-optics or whatever the study is
called. What does the eye perceive with more and less accuracy?

Thomas Richter · Guest

Industrial One wrote:
[quote]On Oct 10, 4:44 pm, Thomas Richter <t...@math.tu-berlin.de> wrote:
No, and no. It>s neither experimental, nor should it be avoided. What
you should avoid are the not-so-well-done reference implementations that
barely do the absolute minimum, or close to the absolute minimum. If
you>ve been in the movies lately and went to a rather modern theater,
you>ve seen JPEG2000 in action already.

Ok, what application would you recommend.
[/quote]
Mine, of course. (-: www.jpg.com. It>s commercial, though, and no, I do
not hand out copies for free - I don>t own them in first place, I only
wrote (good parts) of them.

[quote]Is there a DLL that I can
integrate into MSPaint?
[/quote]
No, who cares about MSPaint? But there>s a plugin for Photoshop (and my
private Linux .so plus patch for "xv", but no, you cannot have those,
nor are they available).

[quote]About movie tehatres, don>t they use MPEG2?
[/quote]
No. They use DCI, which is a wrapper around JPEG2000, including for
example heavy encryption. MPEG2 is harder to edit and requires recoding
for editing, JPEG2000 can be edited frame by frame, which is one of the
reasons why it had been picked.

[quote]*Video* quality evaluation is just another thing, it>s even more
complex, because you also have temporal aspects to consider.

Yeah, but seriously: a single tinted line on the left, that>s like
0.5% of the video. According to PSNR, that somehow constitutes high
decibels of noise? How would you evaluate quality at all with that
dipshitted algorith?
[/quote]
You know how PSNR works. It is also used a lot as "quick>n dirty" algorithm.

[quote]That is called "subjective testing", and is of course a very important
tool we>re also applying in JPEG-XR testing, for example. The short
answer is that under these tests, optimized JPEG2000 performs best, and
unoptimized JPEG-XR performs worst. For the long story, you would need
to read our (Chaker and mine) paper, came out in the SPIE conference
this year.

Link?
[/quote]
For that, you would need to buy the proceedings from SPIE, which are
copyrighted. If your mail is valid, I could send you the preprint.

[quote]However, doing subjective tests is only half the job done - how do you
write an algorithm that optimizes for this definition? You surely do not
want to work on your digital camera to tune all the parameters manually
to make the image look good - that should be done by an algorithm. And
that>s exactly where the problem starts: Without a mathematical
approximation of "quality", one cannot implement an algorithm that
avoids image artifacts.

No, I meant, try whatever new JPEG algorithm on an image and do
subjective tests to determine the efficiency.
[/quote]
That *is* of course done (and done right now). However, things aren>t
that easy, improvements are made pretty often, which would require more
subjective testing than anyone can pay for, and tiny improvements often
add up only so little to subjective test results that their impact is
lost in the noise, even though in total their effect may add up. In
either event, subjective tests would help little, or would not be possible.

[quote]Build another algorithm
that uses a different transform method and do subjective tests on that
one -- if the efficiency is better than the previous, trash the
previous.
[/quote]
It>s sometimes not even possible to ditch the old. Why don>t you ditch
JPEG then? The ISO cannot "disallow" JPEG because there>s a new one. We
can only say that we no longer work on it. (-:

[quote]As for mathematically defining quality, that>s a hard one. I guess
someone can program an app to ignore some regions with minor
differences in chroma that wouldn>t be noticed by the eye and focus on
regions that really stand out. But the success of that project would
probably be directly tied with psycho-optics or whatever the study is
called. What does the eye perceive with more and less accuracy?
[/quote]
Several effects are known - frequency dependency of the eye, masking,
effects of color. Adding them all up to a consistent model is one of the
problems right here.

So long,
Thomas

Industrial One · Guest

On Oct 12, 3:21 am, Thomas Richter <t...@math.tu-berlin.de> wrote:
[quote]Industrial One wrote:
Ok, what application would you recommend.

Mine, of course. (-:www.jpg.com. It>s commercial, though, and no, I do
not hand out copies for free - I don>t own them in first place, I only
wrote (good parts) of them.
[/quote]
I don>t have a credit card, but after I>ve remedied my bad credit
rating I>ll buy it if it>s for a reasonable price. How much? But first
tell me if WinXP already came with it, 'cuz mine is a legal copy so
chances are I>ve already paid for your work.

[quote]Is there a DLL that I can
integrate into MSPaint?

No, who cares about MSPaint? But there>s a plugin for Photoshop (and my
private Linux .so plus patch for "xv", but no, you cannot have those,
nor are they available).
[/quote]
MSPaint is the most ideal general purpose image viewing/processing app
for me as it loads instantly and I don>t need any features besides the
basic shit MSPaint already offers. Everything else I got in Corel
Photoshop, though I seriously need to update as my copy is outdated as
f ck (1996.)

[quote]About movie tehatres, don>t they use MPEG2?

No. They use DCI, which is a wrapper around JPEG2000, including for
example heavy encryption. MPEG2 is harder to edit and requires recoding
for editing, JPEG2000 can be edited frame by frame, which is one of the
reasons why it had been picked.
[/quote]
No, it only requires recoding of the ref frames in the keyframe
interval, not more than about 15. I don>t see how it>s a problem, esp
if high bitrates are used. But meh, I didn>t know they used motion
JPEG.

[quote]For that, you would need to buy the proceedings from SPIE, which are
copyrighted. If your mail is valid, I could send you the preprint.
[/quote]
Go ahead.

[quote]No, I meant, try whatever new JPEG algorithm on an image and do
subjective tests to determine the efficiency.

That *is* of course done (and done right now). However, things aren>t
that easy, improvements are made pretty often, which would require more
subjective testing than anyone can pay for, and tiny improvements often
add up only so little to subjective test results that their impact is
lost in the noise, even though in total their effect may add up. In
either event, subjective tests would help little, or would not be possible.
[/quote]
Damn, I see. What are you guys gonna do?

[quote]It>s sometimes not even possible to ditch the old. Why don>t you ditch
JPEG then? The ISO cannot "disallow" JPEG because there>s a new one. We
can only say that we no longer work on it. (-:
[/quote]
I meant whatever unreleased prototype tweak you guys are making to the
future JPEG, but nvm.

[quote]As for mathematically defining quality, that>s a hard one. I guess
someone can program an app to ignore some regions with minor
differences in chroma that wouldn>t be noticed by the eye and focus on
regions that really stand out. But the success of that project would
probably be directly tied with psycho-optics or whatever the study is
called. What does the eye perceive with more and less accuracy?

Several effects are known - frequency dependency of the eye, masking,
effects of color. Adding them all up to a consistent model is one of the
problems right here.

So long,
Thomas
[/quote]
I got an idea. You guys have the psychovisual stats where it lists how
much a pixel can change in chroma or how many pixels in a row can
before the eye confidently perceives it. Build an application that
splits the image into regions -- not square but object segmentation
bordered by the edges, then split THAT into blocks and have the app
rate the block>s "diversion" from the original, both in light and
chroma. Then for the edges, apply a different, more sensitive
algorithm that determines if the diversion is constant or if there>s a
shifting pattern of high and low noise that may constitute "ringing."
Then add the blocks up and determine the stability of the organization
of the different regions and how well they compare to the original.

Thomas Richter · Guest

Industrial One wrote:
[quote]On Oct 12, 3:21 am, Thomas Richter <t...@math.tu-berlin.de> wrote:
Industrial One wrote:
Ok, what application would you recommend.
Mine, of course. (-:www.jpg.com. It>s commercial, though, and no, I do
not hand out copies for free - I don>t own them in first place, I only
wrote (good parts) of them.

I don>t have a credit card, but after I>ve remedied my bad credit
rating I>ll buy it if it>s for a reasonable price. How much? But first
tell me if WinXP already came with it, 'cuz mine is a legal copy so
chances are I>ve already paid for your work.
[/quote]
There>s a trial version on the page somewhere you can download for free
which contains an "annoyance requester", but is otherwise functional.
It>s not announced as JPEG2000, but something like "MedKit" or so, it>s
used for medical images. Don>t ask me where specific you can find it, sorry.

[quote]About movie tehatres, don>t they use MPEG2?
No. They use DCI, which is a wrapper around JPEG2000, including for
example heavy encryption. MPEG2 is harder to edit and requires recoding
for editing, JPEG2000 can be edited frame by frame, which is one of the
reasons why it had been picked.

No, it only requires recoding of the ref frames in the keyframe
interval, not more than about 15. I don>t see how it>s a problem, esp
if high bitrates are used. But meh, I didn>t know they used motion
JPEG.
[/quote]
MotionJPEG2000. As said, for editing purposes. Those guys are afraid of
any quality loss that would be induced by editing and re-encoding up to
the next I-frame, so it>s not done this way.

[quote]For that, you would need to buy the proceedings from SPIE, which are
copyrighted. If your mail is valid, I could send you the preprint.

Go ahead.
[/quote]
Check your inbox. You should have it by now. The JPEG2000 in there is
the one you get from Pegasus (probably newer than the versions on the
web page).

[quote]No, I meant, try whatever new JPEG algorithm on an image and do
subjective tests to determine the efficiency.
That *is* of course done (and done right now). However, things aren>t
that easy, improvements are made pretty often, which would require more
subjective testing than anyone can pay for, and tiny improvements often
add up only so little to subjective test results that their impact is
lost in the noise, even though in total their effect may add up. In
either event, subjective tests would help little, or would not be possible.

Damn, I see. What are you guys gonna do?
[/quote]
What we did in the past is first to evaluate prototypes subjectively,
and then improving them based on the PSNR-scores. Bad idea - people only
looked at PSNR. What we are now going to do is the "Advanced Image
Coding" work item of the JPEG (just passed, I>ve got the votes
yesterday) where we will hopefully design a couple of useful metrics
everyone can then use and test against, hopefully giving better
correlation than PSNR.

[quote]It>s sometimes not even possible to ditch the old. Why don>t you ditch
JPEG then? The ISO cannot "disallow" JPEG because there>s a new one. We
can only say that we no longer work on it. (-:

I meant whatever unreleased prototype tweak you guys are making to the
future JPEG, but nvm.
[/quote]
Well, see above. Those decisions have been based on PSNR in the past,
with the result that JPEG2000 is - unless their vendors know better -
PSNR optimal with all the implied results. Luckely, the design is
flexible enough to tune it to other metrics without leaving the standard.

[quote]As for mathematically defining quality, that>s a hard one. I guess
someone can program an app to ignore some regions with minor
differences in chroma that wouldn>t be noticed by the eye and focus on
regions that really stand out. But the success of that project would
probably be directly tied with psycho-optics or whatever the study is
called. What does the eye perceive with more and less accuracy?
Several effects are known - frequency dependency of the eye, masking,
effects of color. Adding them all up to a consistent model is one of the
problems right here.

So long,
Thomas

I got an idea. You guys have the psychovisual stats where it lists how
much a pixel can change in chroma or how many pixels in a row can
before the eye confidently perceives it.
[/quote]
More complicated than that, but approximately. You find the receipt for
one of the metrics in the paper.

[quote]Build an application that
splits the image into regions -- not square but object segmentation
bordered by the edges, then split THAT into blocks and have the app
rate the block>s "diversion" from the original, both in light and
chroma. Then for the edges, apply a different, more sensitive
algorithm that determines if the diversion is constant or if there>s a
shifting pattern of high and low noise that may constitute "ringing."
[/quote]
Well, we don>t split images. The problem with any block-based algorithm
is that you cannot detect artifacts along the edges, which is why a
lapped DCT, a wavelet or something in that spirit is used.

[quote]Then add the blocks up and determine the stability of the organization
of the different regions and how well they compare to the original.
[/quote]
That>s called the "Error Pooling" step. There are various approaches to
that, often based on a Minkowski-metric (mathematically, an l^p space
metric). You find more about it in the paper and the references within.

So long,
Thomas

Industrial One · Guest

On Oct 15, 2:12 pm, Thomas Richter <t...@math.tu-berlin.de> wrote:
[quote]Industrial One wrote:
On Oct 12, 3:21 am, Thomas Richter <t...@math.tu-berlin.de> wrote:
Industrial One wrote:
Ok, what application would you recommend.
Mine, of course. (-:www.jpg.com. It>s commercial, though, and no, I do
not hand out copies for free - I don>t own them in first place, I only
wrote (good parts) of them.

I don>t have a credit card, but after I>ve remedied my bad credit
rating I>ll buy it if it>s for a reasonable price. How much? But first
tell me if WinXP already came with it, 'cuz mine is a legal copy so
chances are I>ve already paid for your work.

There>s a trial version on the page somewhere you can download for free
which contains an "annoyance requester", but is otherwise functional.
It>s not announced as JPEG2000, but something like "MedKit" or so, it>s
used for medical images. Don>t ask me where specific you can find it, sorry.
[/quote]
Which page? jpg.com?

[quote]About movie tehatres, don>t they use MPEG2?
No. They use DCI, which is a wrapper around JPEG2000, including for
example heavy encryption. MPEG2 is harder to edit and requires recoding
for editing, JPEG2000 can be edited frame by frame, which is one of the
reasons why it had been picked.

No, it only requires recoding of the ref frames in the keyframe
interval, not more than about 15. I don>t see how it>s a problem, esp
if high bitrates are used. But meh, I didn>t know they used motion
JPEG.

MotionJPEG2000. As said, for editing purposes. Those guys are afraid of
any quality loss that would be induced by editing and re-encoding up to
the next I-frame, so it>s not done this way.

For that, you would need to buy the proceedings from SPIE, which are
copyrighted. If your mail is valid, I could send you the preprint.

Go ahead.

Check your inbox. You should have it by now. The JPEG2000 in there is
the one you get from Pegasus (probably newer than the versions on the
web page).
[/quote]
Interesting. Really coming out of the matrix of outdated evaluation
methods, eh? I always see SSIM as the optional, alternative-to-PSNR
evaluator of your output on x264 encoding. I never bothered to try it
out as I did PSNR, what limitations of PSNR does SSIM resolve?

[quote]What we did in the past is first to evaluate prototypes subjectively,
and then improving them based on the PSNR-scores. Bad idea - people only
looked at PSNR. What we are now going to do is the "Advanced Image
Coding" work item of the JPEG (just passed, I>ve got the votes
yesterday) where we will hopefully design a couple of useful metrics
everyone can then use and test against, hopefully giving better
correlation than PSNR.
[/quote]
I see.

[quote]I got an idea. You guys have the psychovisual stats where it lists how
much a pixel can change in chroma or how many pixels in a row can
before the eye confidently perceives it.

More complicated than that, but approximately. You find the receipt for
one of the metrics in the paper.

Build an application that
splits the image into regions -- not square but object segmentation
bordered by the edges, then split THAT into blocks and have the app
rate the block>s "diversion" from the original, both in light and
chroma. Then for the edges, apply a different, more sensitive
algorithm that determines if the diversion is constant or if there>s a
shifting pattern of high and low noise that may constitute "ringing."

Well, we don>t split images. The problem with any block-based algorithm
is that you cannot detect artifacts along the edges, which is why a
lapped DCT, a wavelet or something in that spirit is used.

Then add the blocks up and determine the stability of the organization
of the different regions and how well they compare to the original.

That>s called the "Error Pooling" step. There are various approaches to
that, often based on a Minkowski-metric (mathematically, an l^p space
metric). You find more about it in the paper and the references within.

So long,
Thomas
[/quote]
Heh, I didn>t think my paragraph would be any more than commonsense to
the committee. But any future algorithm must be more content-aware of
the image instead of treating it linearly as a series of blocks. If
parts of the image can be correctly segmented by an application, then
it>s a start for REAL quality evaluation. However, I got no idea how
that wavelet algorithm or whatever works, but you say it can
compensate for the edges.


www.GetXFactor.com Leading Technology, Science, Agriculture News and information	Part of the Identityscape.com network... getxfactor.com jmoodmusic.com smartbusinesschoices.com mintdepot.com lowfaresalways.com evangelicalview.com shoppingpodder.com soproudlywehail.com webnews.ws currenthumor.com

Science and Technology news... Forum Index -> Compression Forum
Page 1 of 1