Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compression > #2739

Re: Periodic symmetric extension in jpeg 2000 forward wavelet transform

Show all headers | View raw

Thomas Richter <thor@math.tu-berlin.de> wrote:
> Am 22.12.2014 um 04:20 schrieb Aaron Boxer:

>> I am surprised that the standard makes no guarantee about encoder
>> image quality. Is this the case for other image standards?

Part of the idea of lossy compression is that the user gets to choose
the loss level (and file size) that they want/need.
 
> Actually, for most JPEG and MPEG standards (i.e. pretty much all of 
> SC29). We only define decoders, and the codestream syntax. How an 
> encoder arrives at a certain codestream is none of our business.
(snip)

>> How can an innocent user guarantee that a given encoder does 
>> not start outputting Lena when the bit depth hits 16, or 
>> dimensions are greater than 16,000 ,etc. ?
 
> Well, ISO cannot. But, would you buy a product with would do so? It is a 
> quality of implementation issue that an encoder doesn't do any nonsense, 
> and it allows vendors to differentiate between each other to create 
> smarter (or cheaper) encoders, tuned for a specific business case.

Some years ago when watching TV news, I noticed that the digital
television system does not handle rapid intensity fluctuations well
at all.  I believe the specific case was Will and Kate's wedding
announcement, but the result is many camera flash units going off
at almost the same time, approaching the frame rate.  It seems that
the motion prediction system gets completely lost.

I asked on comp.dsp, and was told that MPEG allows for multiple
streams, such that the encoder could encode such intensity variation,
especially for frames with no flash going off. It seems, though, that
the ones actually used don't do that. It happens rarely enough that
it isn't in the buying decision.

The NTSC (US analog color TV) standard allows for different bandwidth
(resolution) for different colors, following what the eye can see.

http://en.wikipedia.org/wiki/YIQ

NTSC allows for a simpler decoding on the red and blue axis, though I
believe that encoders are supposed to use YIQ.  But the majority of
sets used YRB (or YUV) decoding.

-- glen

Back to comp.compression | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Periodic symmetric extension in jpeg 2000 forward wavelet transform Aaron Boxer <boxerab@gmail.com> - 2014-12-18 12:59 -0800
  Re: Periodic symmetric extension in jpeg 2000 forward wavelet transform Thomas Richter <thor@math.tu-berlin.de> - 2014-12-20 13:48 +0100
    Re: Periodic symmetric extension in jpeg 2000 forward wavelet transform Aaron Boxer <boxerab@gmail.com> - 2014-12-20 06:55 -0800
      Re: Periodic symmetric extension in jpeg 2000 forward wavelet transform Thomas Richter <thor@math.tu-berlin.de> - 2014-12-21 00:24 +0100
        Re: Periodic symmetric extension in jpeg 2000 forward wavelet transform Aaron Boxer <boxerab@gmail.com> - 2014-12-21 19:20 -0800
          Re: Periodic symmetric extension in jpeg 2000 forward wavelet transform Thomas Richter <thor@math.tu-berlin.de> - 2014-12-22 20:53 +0100
            Re: Periodic symmetric extension in jpeg 2000 forward wavelet transform glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-22 22:53 +0000
            Re: Periodic symmetric extension in jpeg 2000 forward wavelet transform Aaron Boxer <boxerab@gmail.com> - 2014-12-24 03:35 -0800

csiph-web