|
| Science Forum Index » Compression Forum » JPEG XR draft specification? |
|
Page 1 of 2 Goto page 1, 2 Next |
|
| Author |
Message |
| Pete Fraser |
 Posted: Wed Nov 07, 2007 1:24 pm |
|
|
|
Guest
|
Anybody know if there's a draft spec for this
available anywhere?
I've read the HD Photo bitstream spec that comes
with the DPK, but it's a bit thin. |
|
|
| Back to top |
|
|
|
| Thomas Richter |
| Posted: Thu Nov 08, 2007 4:01 am |
|
|
|
Guest
|
Pete Fraser schrieb:
[quote:55967a0009]Anybody know if there's a draft spec for this
available anywhere?
[/quote:55967a0009]
Not yet officially released, but a draft is circulated in the
JPEG for review (meaning, "yes, I have a draft", and no, "I cannot hand
it out right now").
[quote:55967a0009]I've read the HD Photo bitstream spec that comes
with the DPK, but it's a bit thin.
[/quote:55967a0009]
It all takes its time. Please stay tuned. Probably we'll be able to
release a committee draft after the next meeting (up to next week,
actually).
So long,
Thomas |
|
|
| Back to top |
|
|
|
| Pete Fraser |
| Posted: Thu Nov 08, 2007 1:50 pm |
|
|
|
Guest
|
"Thomas Richter" <thor@math.tu-berlin.de> wrote in message
news:fgufh8$mi5$1@infosun2.rus.uni-stuttgart.de...
[quote:2b9f09dc36]Pete Fraser schrieb:
Anybody know if there's a draft spec for this
available anywhere?
Not yet officially released, but a draft is circulated in the
JPEG for review (meaning, "yes, I have a draft", and no, "I cannot hand
it out right now").
It all takes its time. Please stay tuned. Probably we'll be able to
release a committee draft after the next meeting (up to next week,
actually).
[/quote:2b9f09dc36]
Thanks Thomas.
When the draft is released where would I buy it (ITU / ISO)?
Or is it something that will be downloadable? |
|
|
| Back to top |
|
|
|
| Pete Fraser |
| Posted: Fri Nov 09, 2007 2:29 am |
|
|
|
Guest
|
"erpy" <info@forwardgames.com> wrote in message
news:4733c2f6$0$10629$4fafbaef@reader2.news.tin.it...
[quote:574688cf6f]What's your opinion about Microsoft's stuff ?
It doesn't look too good to me...as of now. I've seen much better (in
terms of quality/ratio) algorithms at Siggraph in the past years...all
ready and working.
[/quote:574688cf6f]
It looks reasonable, though I have not spent much time
playing with it. I'm reading the Tran, Liu and Topiwala
SPIE paper, and the MS stuff seems to come out
quite well in it. The MS stuff looks quite good in the
Moscow SU papers also.
I may end up building a hardware encoder.
I haven't blocked it out yet, but my gut feeling is that
the MS stuff is fairly simple to implement. I'm not sure
how it will compare with AVC-Intra in terms of compexity.
If I leave off a couple of the AVC intra prediction modes
things might be easy there also.
The only JPEG 2000 widget that I built just glued together
6 ADV202s in an FPGA (that was about six years ago).
At the time I looked at building everything in FPGAs, and
it looked like it would hurt my head (and cost a lot).
I've skipped the last few Siggraphs. Which algorithms
did you see that particularly impressed you? |
|
|
| Back to top |
|
|
|
| Thomas Richter |
| Posted: Fri Nov 09, 2007 8:31 am |
|
|
|
Guest
|
erpy wrote:
[quote:d678a7fcd7]What's your opinion about Microsoft's stuff ?
It doesn't look too good to me...as of now. I've seen much better (in
terms of quality/ratio) algorithms at Siggraph in the past years...all
ready and working.
[/quote:d678a7fcd7]
It really depends on how you define quality. If you define it as PSNR,
HDPhoto is reasonable, worse than JPEG2000, but better than JPEG-1. It's
closer to JPEG2000 in this respect.
If you check with various HSV-adaptive metrics, that is, metrics that
are more tuned towards human vision, the current HDPhoto implementation
we had for testing purposes did not come out very well. In fact, it came
out worst. These objective tests seem to be backed up quite well by
subjective testing, so there's still lots of stuff to do to tune HDPhoto
to HSV, or to see to which degree this is actually possible.
[quote:d678a7fcd7]...likely this will end up just like Jpeg2000 (!?)
[/quote:d678a7fcd7]
JPEG2000 is actually deployed in medical imaging and digital cinema.
So long,
Thomas |
|
|
| Back to top |
|
|
|
| erpy |
| Posted: Fri Nov 09, 2007 8:36 am |
|
|
|
Guest
|
Pete Fraser ha scritto:
[quote:e6a99f2bc9]"erpy" <info@forwardgames.com> wrote in message
news:4733c2f6$0$10629$4fafbaef@reader2.news.tin.it...
What's your opinion about Microsoft's stuff ?
It doesn't look too good to me...as of now. I've seen much better (in
terms of quality/ratio) algorithms at Siggraph in the past years...all
ready and working.
It looks reasonable, though I have not spent much time
playing with it. I'm reading the Tran, Liu and Topiwala
SPIE paper, and the MS stuff seems to come out
quite well in it. The MS stuff looks quite good in the
Moscow SU papers also.
I may end up building a hardware encoder.
I haven't blocked it out yet, but my gut feeling is that
the MS stuff is fairly simple to implement. I'm not sure
how it will compare with AVC-Intra in terms of compexity.
If I leave off a couple of the AVC intra prediction modes
things might be easy there also.
The only JPEG 2000 widget that I built just glued together
6 ADV202s in an FPGA (that was about six years ago).
At the time I looked at building everything in FPGAs, and
it looked like it would hurt my head (and cost a lot).
I've skipped the last few Siggraphs. Which algorithms
did you see that particularly impressed you?
[/quote:e6a99f2bc9]
Well, Greg Ward himself proposed an extension to Jpeg for HDR. (which he
named "JPEG-HDR")
As Thomas said, PSNR is useless when HDR kicks in....and HD Photo looks
quite bad when the white point starts to be quite high.
To this respect, also Mantiuk et al. proposed similar extensions for
motion pictures, with MPEG-HDR.
IMHO Microsoft overlooked the importance of HDR and did not consulted
too much with HDR fathers. (namely, Ward and Debevec) ;)
Best,
E. |
|
|
| Back to top |
|
|
|
| Thomas Richter |
| Posted: Fri Nov 09, 2007 8:50 am |
|
|
|
Guest
|
Pete Fraser wrote:
[quote:7cfe17b4b8]"erpy" <info@forwardgames.com> wrote in message
news:4733c2f6$0$10629$4fafbaef@reader2.news.tin.it...
What's your opinion about Microsoft's stuff ?
It doesn't look too good to me...as of now. I've seen much better (in
terms of quality/ratio) algorithms at Siggraph in the past years...all
ready and working.
It looks reasonable, though I have not spent much time
playing with it. I'm reading the Tran, Liu and Topiwala
SPIE paper, and the MS stuff seems to come out
quite well in it. The MS stuff looks quite good in the
Moscow SU papers also.
[/quote:7cfe17b4b8]
It depends on what they've measured. Presumably, PSNR? I would
suggest to also check for papers that go for other metrics, like
M-SSIM. There's been a paper on this year's SPIE by Ebrahimi et al.
where they basically reproduced the measurements I did for the JPEG
a bit before, and the HDPhoto implemention used then for testing - the
MS one - does not look too hot in these terms. Actually, it came out
pretty bad. Note, however, that the current implementation is tuned to
PSNR and does little to address the properties of the HSV, so this is
pretty premature. There is still lots of room for improvement, likely.
All this has to be estimated, measured and evaluated. That's why
standardization takes so long, we need to be careful.
[quote:7cfe17b4b8]I may end up building a hardware encoder.
I haven't blocked it out yet, but my gut feeling is that
the MS stuff is fairly simple to implement. I'm not sure
how it will compare with AVC-Intra in terms of compexity.
If I leave off a couple of the AVC intra prediction modes
things might be easy there also.
[/quote:7cfe17b4b8]
Software based complexity measurements have been performed already.
Of course, JPEG2000 is by this time now more mature than HDPhoto,
please keep this in mind. Anyhow, the result of these tests
were that your mileage differs a lot. For low bitrates, JPEG2000 is
actually faster than HDPhoto, but its much stronger dependent on
the bitrate than HDPhoto, so the situation reverses for higher
bitrates. The break-even is on average at about 1bpp, but also heavily
depending on the image. We did use the best available optimized versions
for this test, not the MS version. (Actually, the Pegasus code is used
on both sides here because that was fastest available).
MS kept a much better view on hardware implementations, but as I'm not
a hardware expert, it is unknown to me in which respect this is easier
than JPEG2000.
[quote:7cfe17b4b8]The only JPEG 2000 widget that I built just glued together
6 ADV202s in an FPGA (that was about six years ago).
At the time I looked at building everything in FPGAs, and
it looked like it would hurt my head (and cost a lot).
[/quote:7cfe17b4b8]
Fraunhofer institute Erlangen also constructed dedicated hardware
for a renowned German movie camera manufacturer, of course for
the upcoming DCI. So clearly, JPEG2000 on hardware is available,
but is pricey. For a simple minded consumer hardware implementation,
JPEG-1 is currently still the optimal choice.
So long,
Thomas |
|
|
| Back to top |
|
|
|
| Jim Leonard |
| Posted: Fri Nov 09, 2007 11:12 am |
|
|
|
Guest
|
On Nov 9, 6:36 am, erpy <i...@forwardgames.com> wrote:
[quote:913fc60c6c]To this respect, also Mantiuk et al. proposed similar extensions for
motion pictures, with MPEG-HDR.
[/quote:913fc60c6c]
What kind of extensions are proposed? In my own work, 10-bit DCTs are
enough to eliminate human-visible banding on all of my HDR-capable
output devices. |
|
|
| Back to top |
|
|
|
| erpy |
| Posted: Fri Nov 09, 2007 5:25 pm |
|
|
|
Guest
|
Jim Leonard ha scritto:
[quote:e18ab37c18]On Nov 9, 6:36 am, erpy <i...@forwardgames.com> wrote:
To this respect, also Mantiuk et al. proposed similar extensions for
motion pictures, with MPEG-HDR.
What kind of extensions are proposed? In my own work, 10-bit DCTs are
enough to eliminate human-visible banding on all of my HDR-capable
output devices.
[/quote:e18ab37c18]
They did not proposed extensions AFAIK, as of now.
I've read the MPEG modification proposed by Mantiuk et al. with 10 to 12
bit DCTs...but the increased dynamic range makes blockyness (and
ringing) even more evident. (contrast on the block edges might be orders
of magnitute stronger than with 8bits)
High-contrast block and ringing removal algorithms are around as well,
but this requires lots of computations. Not an easy issue as a whole.
Best,
E. |
|
|
| Back to top |
|
|
|
| Phil Carmody |
| Posted: Fri Nov 09, 2007 6:20 pm |
|
|
|
Guest
|
erpy <info@forwardgames.com> writes:
[quote:503764235b]Jim Leonard ha scritto:
On Nov 9, 6:36 am, erpy <i...@forwardgames.com> wrote:
To this respect, also Mantiuk et al. proposed similar extensions for
motion pictures, with MPEG-HDR.
What kind of extensions are proposed? In my own work, 10-bit DCTs are
enough to eliminate human-visible banding on all of my HDR-capable
output devices.
They did not proposed extensions AFAIK, as of now.
I've read the MPEG modification proposed by Mantiuk et al. with 10 to
12 bit DCTs...but the increased dynamic range makes blockyness (and
ringing) even more evident. (contrast on the block edges might be
orders of magnitute stronger than with 8bits)
[/quote:503764235b]
Why? It's surely the quantisation of the coefficients in
frequency-space that cause the ringing, which is surely
independent of the precision of the original signal? If
you're using different quantisation functions for the
frequencies, then yes, of course the ringing and blocking
can be vastly different, but that's nothing to do wuth
the colour depth.
Phil
--
Dear aunt, let's set so double the killer delete select all.
-- Microsoft voice recognition live demonstration |
|
|
| Back to top |
|
|
|
| erpy |
| Posted: Fri Nov 09, 2007 7:46 pm |
|
|
|
Guest
|
Phil Carmody ha scritto:
[quote:3627952e22]erpy <info@forwardgames.com> writes:
Jim Leonard ha scritto:
On Nov 9, 6:36 am, erpy <i...@forwardgames.com> wrote:
To this respect, also Mantiuk et al. proposed similar extensions for
motion pictures, with MPEG-HDR.
What kind of extensions are proposed? In my own work, 10-bit DCTs are
enough to eliminate human-visible banding on all of my HDR-capable
output devices.
They did not proposed extensions AFAIK, as of now.
I've read the MPEG modification proposed by Mantiuk et al. with 10 to
12 bit DCTs...but the increased dynamic range makes blockyness (and
ringing) even more evident. (contrast on the block edges might be
orders of magnitute stronger than with 8bits)
Why? It's surely the quantisation of the coefficients in
frequency-space that cause the ringing, which is surely
independent of the precision of the original signal? If
you're using different quantisation functions for the
frequencies, then yes, of course the ringing and blocking
can be vastly different, but that's nothing to do wuth
the colour depth.
Phil
[/quote:3627952e22]
You'd really ask Mantiuk for details, but in his 2004 paper there should
be enough answers.
I don't like hot-linking so:
http://www.mpi-inf.mpg.de/~mantiuk/
....download and read: "Perception-motivated High Dynamic Range Video
Encoding".
In the PDF, read section 2.3.
At the beginning of 2.3 he says:
"Unfortunately the DCT is not always an optimal representation for HDR
data. HDR images can contain sharp transitions from low to extremely
high luminance values, for example at the edges of light sources.
Information about sharp edges is encoded into high-frequency DCT
coefficients, which are coarsely quantized. This results in visible
noisy artifacts around edges...."
Best,
E. |
|
|
| Back to top |
|
|
|
| Phil Carmody |
| Posted: Fri Nov 09, 2007 8:37 pm |
|
|
|
Guest
|
erpy <info@forwardgames.com> writes:
[quote:4614206b5e]Phil Carmody ha scritto:
erpy <info@forwardgames.com> writes:
Jim Leonard ha scritto:
On Nov 9, 6:36 am, erpy <i...@forwardgames.com> wrote:
To this respect, also Mantiuk et al. proposed similar extensions for
motion pictures, with MPEG-HDR.
What kind of extensions are proposed? In my own work, 10-bit DCTs are
enough to eliminate human-visible banding on all of my HDR-capable
output devices.
They did not proposed extensions AFAIK, as of now.
I've read the MPEG modification proposed by Mantiuk et al. with 10 to
12 bit DCTs...but the increased dynamic range makes blockyness (and
ringing) even more evident. (contrast on the block edges might be
orders of magnitute stronger than with 8bits)
Why? It's surely the quantisation of the coefficients in
frequency-space that cause the ringing, which is surely
independent of the precision of the original signal? If
you're using different quantisation functions for the frequencies,
then yes, of course the ringing and blocking
can be vastly different, but that's nothing to do wuth the colour
depth.
Phil
You'd really ask Mantiuk for details, but in his 2004 paper there
should be enough answers.
I don't like hot-linking so:
http://www.mpi-inf.mpg.de/~mantiuk/
...download and read: "Perception-motivated High Dynamic Range Video
Encoding".
In the PDF, read section 2.3.
At the beginning of 2.3 he says:
"Unfortunately the DCT is not always an optimal representation for HDR
data. HDR images can contain sharp transitions from low to extremely
high luminance values, for example at the edges of light
sources. Information about sharp edges is encoded into high-frequency
DCT coefficients, which are coarsely quantized. This results in
visible noisy artifacts around edges...."
[/quote:4614206b5e]
I do not see that as really supporting your claim that "the increased
dynamic range makes blockyness (and ringing) even more evident (contrast
on the block edges might be orders of magnitute stronger than with 8bits)"
Just because they've found a way (by amongst other things extracting
the part of the signal which impinges so much in frequency-space and
coding that separately) of reducing the perceived blocking and ringing
greatly doesnt mean that if they'd have simply DCT'd and quantised
the higher resolution signal it would have had more blocking and
ringing than if working with an 8-bit original.
I'm curious why the caption to figure 5 claims that the bpp is
only increased by 7% and yet the bpps in table 3 seem to be
increased by up to 100%.
Phil
--
Dear aunt, let's set so double the killer delete select all.
-- Microsoft voice recognition live demonstration |
|
|
| Back to top |
|
|
|
| erpy |
| Posted: Fri Nov 09, 2007 9:02 pm |
|
|
|
Guest
|
Phil Carmody ha scritto:
[quote:dcaa2f28e2]erpy <info@forwardgames.com> writes:
Phil Carmody ha scritto:
erpy <info@forwardgames.com> writes:
Jim Leonard ha scritto:
On Nov 9, 6:36 am, erpy <i...@forwardgames.com> wrote:
To this respect, also Mantiuk et al. proposed similar extensions for
motion pictures, with MPEG-HDR.
What kind of extensions are proposed? In my own work, 10-bit DCTs are
enough to eliminate human-visible banding on all of my HDR-capable
output devices.
They did not proposed extensions AFAIK, as of now.
I've read the MPEG modification proposed by Mantiuk et al. with 10 to
12 bit DCTs...but the increased dynamic range makes blockyness (and
ringing) even more evident. (contrast on the block edges might be
orders of magnitute stronger than with 8bits)
Why? It's surely the quantisation of the coefficients in
frequency-space that cause the ringing, which is surely
independent of the precision of the original signal? If
you're using different quantisation functions for the frequencies,
then yes, of course the ringing and blocking
can be vastly different, but that's nothing to do wuth the colour
depth.
Phil
You'd really ask Mantiuk for details, but in his 2004 paper there
should be enough answers.
I don't like hot-linking so:
http://www.mpi-inf.mpg.de/~mantiuk/
...download and read: "Perception-motivated High Dynamic Range Video
Encoding".
In the PDF, read section 2.3.
At the beginning of 2.3 he says:
"Unfortunately the DCT is not always an optimal representation for HDR
data. HDR images can contain sharp transitions from low to extremely
high luminance values, for example at the edges of light
sources. Information about sharp edges is encoded into high-frequency
DCT coefficients, which are coarsely quantized. This results in
visible noisy artifacts around edges...."
I do not see that as really supporting your claim that "the increased
dynamic range makes blockyness (and ringing) even more evident (contrast
on the block edges might be orders of magnitute stronger than with 8bits)"
Just because they've found a way (by amongst other things extracting
the part of the signal which impinges so much in frequency-space and
coding that separately) of reducing the perceived blocking and ringing
greatly doesnt mean that if they'd have simply DCT'd and quantised
the higher resolution signal it would have had more blocking and
ringing than if working with an 8-bit original.
I'm curious why the caption to figure 5 claims that the bpp is
only increased by 7% and yet the bpps in table 3 seem to be
increased by up to 100%.
Phil
[/quote:dcaa2f28e2]
To my understanding, they did include hybrid coding because of increased
artifacts with "standard" MPEG encoding - but with increased DCT range
(10 to 12 bits) - so they did, but it was horrible...so they came out
with hybrid coding.
But then again, it is not my paper. 
About figure 5 and table 3, still to my interpretation, hybrid coding
accounts for 2 additional blocks per block (only where needed ?) to be
stored, but only for luminance...blocks then are further compressed
(huffman ?). So the total added data only for hybrid coding is +7% of
the compressed file size without the additional data.
(mpeg_size/mpeg_with_hybrid_size ??)
The bpp in Table 3 accounts for everything...including the increased DCT
range (from 8 to 10 or 12 bits). So, looks pretty reasonable to me.
Best,
E. |
|
|
| Back to top |
|
|
|
| Thomas Richter |
| Posted: Sat Nov 10, 2007 9:03 am |
|
|
|
Guest
|
erpy wrote:
[quote:6f9dcaa47a]You'd really ask Mantiuk for details, but in his 2004 paper there should
be enough answers.
I don't like hot-linking so:
http://www.mpi-inf.mpg.de/~mantiuk/
...download and read: "Perception-motivated High Dynamic Range Video
Encoding".
In the PDF, read section 2.3.
At the beginning of 2.3 he says:
"Unfortunately the DCT is not always an optimal representation for HDR
data. HDR images can contain sharp transitions from low to extremely
high luminance values, for example at the edges of light sources.
Information about sharp edges is encoded into high-frequency DCT
coefficients, which are coarsely quantized. This results in visible
noisy artifacts around edges...."
[/quote:6f9dcaa47a]
I don't think I quite understand this argument. The DCT is a linear
transformation, which means that if I increase the precision of the
input data by additional bits, the absolute error due to quantization
should remain bounded. The relative error increases of course if
quantized to the same absolute step sizes.
Of course, if you use HDR to represent a huge range of luminance and
view these images by extracting only a small luminance range for
viewing, then the situation is quite different.
So long,
Thomas |
|
|
| Back to top |
|
|
|
| Marco Al |
| Posted: Sun Nov 11, 2007 10:32 am |
|
|
|
Guest
|
Thomas Richter wrote:
[quote:fee879844d]While
current measurements seem to indicate that VDP predicts better
[/quote:fee879844d]
What, where?
Marco |
|
|
| Back to top |
|
|
|
|
|
All times are GMT - 5 Hours
The time now is Sat Jul 31, 2010 4:38 pm
|
|
