Page 2 of 2 FirstFirst 12
Results 31 to 33 of 33

Thread: WebP (Lossless April 2012)

  1. #31
    Member
    Join Date
    Sep 2010
    Location
    US
    Posts
    126
    Thanks
    4
    Thanked 69 Times in 29 Posts
    Quote Originally Posted by thorfdbg View Post
    As for deblocking: We're currently struggling with this issue as well, and trying to come to a conclusion of wether or not to include it in tests. There are arguments for and against it, and it's not quite so easy. Conceptionally, any postprocessing is not part of the standard, so you're not testing a standard, but an implementation of it, and the output of any codec could be improved by post-filtering.
    The problem is that the competitors generally have some kind of deblocking. AVC and HEVC have it in the standard. JPEG-XR does it inherently as part of the lapped transform. So to compare them against JPEG without a deblocker is not really apples to apples.

    Block artifacts at low bit-rate is by the far the most visible flaw in JPEG and is so easy to fix with a deblocker!

    It would be nice if there was a standard after-JPEG deblocker! BTW I like the Nosratinia deblocker a lot. It's too slow on the CPU but parallelizes very well and is super fast on a GPU.


    That's currently happening in a joint MPEG/JPEG ad-hoc, and I don't have finite results yet. Again, for me it looks as if AVC does have an advantage here - and of course our folks from WG11 also know about HVS-properties, so there's something in their reference code.
    Yeah I agree, I'm sure that AVC/HEVC will eventually be the best still image coder once the perceptual model is better understood.

    MPEG world lives in YCbCr, thus their images are always in YCbCr, and losses due to the color decorrelation transformation are not accounted for in MPEG experiments. JPEG "thinks" in RGB, and has a more end-to-end approach (but see above).
    Indeed this is a big issue that most people neglect. x264 loses something like 2 dB of PSNR (in RGB) through bad color space and downsampling of chroma. Most of the MPEG papers and charts report error in YCbCr so miss this aspect.

    I don't quite understand your point here. If the outcome of the experiment is that it is bad below 1bpp, then this is what it says. It's a fact that it is terrible below 1bpp. Of course, the full story is in the R/D curves (or R/Q curves, actually, for whatever Q you believe in).
    The problem is that the summary blurbs for things like HEVC say "better than JPEG by up to 10 dB !" . What they don't say is that improvement happens only at 0.25 bpp and less.

    NO! It's not "patent free"! It's at best "royalty free" as the MPEG-LA agreed in a cross-license agreement. That is, they believe (I'm not a lawer, so I don't claim to believe here anything anymore) that some patents in the MPEG-LA pool apply to VP8, though MPEG LA provides a royalty free access to such IPs. That's something very different to "patent free".
    Yeah okay, fair point, but for developers who want to use an image format in their app, it's in a much more useable legal state than J2K or AVC which are unpleasantly encumbered. Sadly anything that doesn't have official MPEG-LA clearance has to be considered dangerous. So in a practical sense, developers who want to be sure they are safe (and not pay a license) have to use JPEG or webp.
    Last edited by cbloom; 3rd August 2016 at 21:42.

  2. #32
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    448
    Thanks
    1
    Thanked 101 Times in 61 Posts
    Quote Originally Posted by cbloom View Post
    The problem is that the competitors generally have some kind of deblocking. AVC and HEVC have it in the standard. JPEG-XR does it inherently as part of the lapped transform. So to compare them against JPEG without a deblocker is not really apples to apples.
    Well, maybe. In XR, it is part of the transform and the specification, so you don't quite have a choice to pick that, or another. Postprocessing has a somehwhat more arbitrary character. J2K doesn't have any blocks, does this count as "deblocking filter"? The border line is not so clearly defined, which is exactly why I'm hesitating to take a clear position. It's not quite well thought-through at this moment.

    Here is another problem: We usually do not define encoders, only decoders - which gives you some freedom. For example, to select the quantization matrices in JPEG or the R/D optimizer in JPEG 2000, so you can adapt to various coding goals. Trouble now: Consider we would know that postprocessing is done at the decoder, one could, vice versa, an encoder to such a specific decoder and get an overall quality improvement of this specific combination. Is this a valid "improvement" and is it "conforming"? Even more so if combined with the reference decoder, which then might get even worse results? Is this valid to lower the quality on the reference decoder if the quality is improved on a special decoder on encoder-modification techniques?

    Quote Originally Posted by cbloom View Post
    Block artifacts at low bit-rate is by the far the most visible flaw in JPEG and is so easy to fix with a deblocker!
    Blocking, and ringing, and of course Gibbs artefacts.


    Quote Originally Posted by cbloom View Post
    It would be nice if there was a standard after-JPEG deblocker! BTW I like the Nosratinia deblocker a lot. It's too slow on the CPU but parallelizes very well and is super fast on a GPU.
    Don't give me ideas. We're re-visiting JPEG right now anyhow (JPEG XT, including a backwards compatible lossless and HDR coder), so maybe that *is* an idea for another part... Need to check with others, but I'm right now quite busy.



    Quote Originally Posted by cbloom View Post
    The problem is that the summary blurbs for things like HEVC say "better than JPEG by up to 10 dB !" . What they don't say is that improvement happens only at 0.25 bpp and less.
    That's the usual "marketing bullshit". Marketing people like to cut down quality to a single number. I also once had the idea to define a standard quality measure, but that's quite hard, and most people in the group did not see a good market chance for such a standard. All we have now are the AIC guidelines for codec evaluation, which are for my taste, too loose to fill this gap.


    Quote Originally Posted by cbloom View Post
    But for developers who want to use an image format in their app, it's in a much more useable legal state than J2K or AVC which are unpleasantly encumbered. Sadly anything that doesn't have official MPEG-LA clearance has to be considered dangerous. So in a practical sense, developers who want to be sure they are safe (and not pay a license) have to use JPEG or webp.
    I'm actually not quite clear what the resolution now was, i.e. whether Google got a transmittable licence, and whether they actually forward the rights to their developers and users. The usual rule here is that reference software does not transfer any IP rights, and users have to do that by their own - which goes back to an unfortunate ISO regulation we cannot change. It means for J2K, for example, that you get an implementation for free, and you get also the licenses for free, but you need to write to the companies nevertheless.

    It's complicated...

  3. #33
    Member
    Join Date
    May 2008
    Location
    England
    Posts
    325
    Thanks
    18
    Thanked 6 Times in 5 Posts
    0.3.0 is out

    https://code.google.com/p/webp/downloads/list

    Code:
    - 3/20/13: version 0.3.0
      This is a binary compatible release.
      * WebPINewRGB/WebPINewYUVA accept being passed a NULL output buffer
        and will perform auto-allocation.
      * default filter option is now '-strong -f 60'
      * encoding speed-up for lossy methods 3 to 6
      * alpha encoding can be done in parallel to lossy using 'cwebp -mt ...'
      * color profile, metadata (XMP/EXIF) and animation support finalized in the
        container.
      * various NEON assembly additions
      Tool updates / additions:
        * gif2webp added
        * vwebp given color profile & animation support
        * cwebp can preserve color profile / metadata with '-metadata'
    For the full changelog you'll need to download the source tree file.

Page 2 of 2 FirstFirst 12

Similar Threads

  1. WebP (lossy image compression)
    By Arkanosis in forum Data Compression
    Replies: 62
    Last Post: 12th April 2019, 19:45
  2. Lossless image coders
    By Madgeniy in forum Data Compression
    Replies: 26
    Last Post: 11th July 2011, 10:06
  3. JPEG Compression Test [April 2010]
    By Skymmer in forum Data Compression
    Replies: 18
    Last Post: 7th February 2011, 23:30
  4. 12th April - The Day of Astronautics
    By encode in forum Forum Archive
    Replies: 37
    Last Post: 13th April 2007, 11:26
  5. Squeeze Chart 2006 - 02 April/13 May
    By encode in forum Forum Archive
    Replies: 9
    Last Post: 17th July 2006, 05:39

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •