LuraWave JPEG2000 images are blurry

Discussion in 'Digital Photography' started by K2, Jun 8, 2004.

  1. K2

    K2 Guest

    I've just started using IrfanView's LuraWave JPEG2000 plugin (at
    resolutions beyond 640x480) and have noticed serious blurring
    artifacts at the "default" setting of 95.

    Using the max setting of "100" the files are huge and it still doesn't
    look that impressive. Large sections of images look blended like
    smooth water, with certain areas in sharp detail. The only super clean
    images I get are in the non-lossy mode of JPEG2000, which makes huge
    files. The quality is far worse than standard JPEG (even at "80" or
    below).

    However, before I registered LuraWave to allow JPEG2000 saves beyond
    640x480, the images looked quite good. Are their known bugs with the
    full version of LuraWave and/or IrfanView's implementation?

    K2
     
    K2, Jun 8, 2004
    #1
    1. Advertisements

  2. Forget about JPEG2000 and Wavelet technology!
    It is a hoax and is inferior compared with standard DCT JPEG!
    Go with standard DCT JPEG - it's fine and the best method
    currently available!
    There will be advances in the future, but *not* in the JPEG2000
    or Wavelet direction, but based on the current DCT JPEG standard.

    Regards
    Guido
     
    Guido Vollbeding, Jun 8, 2004
    #2
    1. Advertisements

  3. K2

    Martin Brown Guest

    Heaven knows what their setting "95" actually means, but there is
    something seriously wrong with the codec if you can see any visible
    artifacts on a J2k file that was saved at highest quality.
    That is odd. Using the (experimental) release of Jasper I found that for
    some digicam images the wavelet representation of a raw image was almost
    exact. Sharp edge pixels were different but not very many.
    There is something wrong then. My experience with Jasper was that J2k
    achieved the same quality as JPEG in about 70% of the file size.

    Some of the compression improvement being due to it using arithmetic
    coding (when does that patent expire?).
    I don't know. You could try running the original files through the
    (rather tedious) command line interface for Jasper to see how they
    compare.

    It could be that you have found a pathological case where J2k performs
    badly, but on balance I think it more likely you have run into a bug.

    Regards,
     
    Martin Brown, Jun 8, 2004
    #3
  4. K2

    Rahul Vohra Guest

    Is this really the case ? Could somebody provide (scientific) evidence to
    argue this one way or the other ? I'm interested both in a comparison
    between JPEG Baseline and the JPEG2000 standard as well as sinusoidal
    transforms vs. wavelets in general. Guido, can you justify you statement
    that wavelets will not form the basis of future compression techniques ?

    Rahul
     
    Rahul Vohra, Jun 9, 2004
    #4
  5. K2

    David Haley Guest


    According to what I've heard the biggest problem is simply that the JPEG2000
    standard is not being adopted very widely and is therefore effectively useless,
    no matter how good it may or may not be. To start using it on the web for
    instance would require that the browsers you target support it, etc.

    -dhaley
     
    David Haley, Jun 9, 2004
    #5
  6. Rahul, Guido does have some very fixed opinions, although he has provided
    useful software for the original JPEG standard as well. I would also be
    interested in some evidence for his statement.

    I have been using a wavelet-based lossless transform in a non-JPEG
    application for over a year now, and I have no problems with it.

    Cheers,
    David
     
    David J Taylor, Jun 9, 2004
    #6
  7. Many years of experience with JPEG and the fact that I recently discovered
    the most important and previously unknown property of the DCT as used in
    standard JPEG have convinced me that the DCT is the best basis for image
    compression and superior to the Wavelet techniques.

    I consider the Wavelet approach as just an academic and commercial artifact
    with no practical advantage and several disadvantages.
    I find it rather amusing that those "image compression experts" who pursue
    the sophisticated and yet unsuccessful Wavelet approach do not even have
    a clue about the basic simple DCT property! They have shown to be
    unteachable and ignorant.

    There *will be* future advances in image compression, but *not* with
    Wavelets, but with the common DCT! The potential of the DCT approach
    is currently far from being exploited, because until recently nobody
    knew the basic DCT property which makes it ideal for image compression,
    even the original JPEG authors didn't know about that and therefore
    failed to exploit all opportunities!
    With this knowledge it will be possible to introduce important
    improvements in image compression with only *slight* modifications
    of the current JPEG standard! Furthermore, it will be easy to
    maintain compatibility with existing JPEG.

    BTW, image blur is the basic property of Wavelet techniques, similar
    to the obsolete mosaic sensor technique used in digital photography.
    Insofar both techniques might well match for people who like blurry
    images. If you look at the current digital camera market you must
    think that there are lots of them...

    Regards
    Guido
     
    Guido Vollbeding, Jun 9, 2004
    #7
  8. []
    Guido, thanks for your feedback - are there any references available
    online to support your claims?

    I have been using lossless wavelet compresssion in a non-JPEG application,
    where there is no blurring of the data.

    Cheers,
    David
     
    David J Taylor, Jun 9, 2004
    #8
  9. You wouldn't think that people would start adopting something which is
    inferior to what you already have, which does not have a useful advantage,
    and which does have several disadvantages.
    Oh, sorry, I forgot, the advantage of Wavelet is that some people can
    make themselves important, and can earn money from credulous people...

    Regards
    Guido
     
    Guido Vollbeding, Jun 9, 2004
    #9
  10. Many people and I myself experienced the same properties with Wavelets
    as described by the original poster. I also remember some web site,
    but sorry I'm too lazy to dig it out now.

    You can find some of my findings in a paper for the German Color Group:

    http://kb-bmts.rz.tu-ilmenau.de/gcg/GCGMAT1.HTM

    or with additional material here:

    http://jpegclub.org/temp/
    Well, as far as I remember, you are also one of the folks who still
    accept the blurry images of current mosaic sensor cameras.
    So, as said, this is a good match.
    But not for me, because for me the digital images from cameras with
    mosaic sensor are too blurry to be acceptable.

    Regards
    Guido
     
    Guido Vollbeding, Jun 9, 2004
    #10
  11. []
    Thanks for those references.
    The images I am referring to:

    (a) are not from digital cameras, but from satellite images

    (b) are losslessly compressed, so no blurring is involved. The output
    data is identical to the input data. The transform process is purely used
    to reduce the bandwidth required for image transmission.

    Please withdraw your remarks, which I find insulting and clearly
    irrelevant to the points I raised.

    David
     
    David J Taylor, Jun 9, 2004
    #11
  12. There are other lossless compression schemes which work at lest as good,
    if not better, than lossless wavelets.
    Even with plain standard DCT JPEG I can get good lossless compression.
    Sorry, couldn't resist - you must have some fat skin when debating with me...

    Regards
    Guido
     
    Guido Vollbeding, Jun 9, 2004
    #12
  13. []
    Apology accepted!

    By the way "a thick skin" would be the normal term.

    Fortunately the wavelet transform code I needed for this project was
    supplied free-of-charge, so no extra cost was involved. In this case, the
    data is 10 bits deep, so using the 12-bit JPEG word length may have meant
    that the file sizes were not quite as compact as the 10-bit wavelet coded
    files. Lossless coding was essential.

    Cheers,
    David
     
    David J Taylor, Jun 9, 2004
    #13
  14. Thanks, I'm learning...
    Well, the original JPEG standard supports up to 16 bits per component
    in the lossless coding mode. It should be quite effective especially
    with the arithmetic entropy coding back-end. Perhaps you could also
    use the "point transform" feature to support 10 or 12 bits better.
    There are several options.

    But I was rather thinking about my recent extensions in the common
    *DCT* JPEG mode which also allow for lossless coding!
    (See comments on http://jpegclub.org/cjpeg/)
    I have performed few experiments, and the efficiency seemed quite
    good, at least noticeably outperforming compressed TIFF and PNG.

    Regards
    Guido
     
    Guido Vollbeding, Jun 9, 2004
    #14
  15. []
    If the word length can be kept to 10 bits internally, then DCT lossless
    JPEG might be acceptable for this application, but if the word length is
    12 or 16 bits then any consequent increase in file size might render it
    unsuitable.

    The project I am referring to has already fixed on using wavelet
    transforms, but if you are interested I could send you a 12MB zipped PGM
    version of a sample image (3712 x 3712 x 10 bit greyscale).

    Cheers,
    David
     
    David J Taylor, Jun 9, 2004
    #15
  16. The correct scientific comparison here is to use your eyes. I have a
    visual comparison of baseline JPEG and JPEG2k artifacts at
    http://www.ailab.si/aleks/jpeg/artifacts.htm

    Indeed, blurring is the worst JPEG2000 artifact, apart from ringing.

    Aleks
     
    Aleks Jakulin, Jun 9, 2004
    #16
  17. I have only experimented in the 8-bit mode.
    The Independent JPEG Group software is supposed to also work
    in 12-bit mode when compiled appropriately, but I haven't
    tried that. For the mentioned lossless application it
    should work with no problem because the pixels are then
    directly treated as DCs and no further 'real' DCT is done
    (just 1x1 with the DC which is just some scaling/quantization).

    The 10-bit case could be handled by an appropriate quantization
    factor, or by point-transforming in progressive mode (shifting
    by 2 and omitting the lower bit scans altogether). Something
    like the latter is also what I've done in my experiments to
    get the desired performance gain: coding just the DCs in a
    progressive mode scan and omitting the (all-zero) AC scans
    altogether (otherwise the EOB code in each block after the
    DC with all-zero ACs in sequential mode would noticeably
    drop the performance).

    This is all in experimental state, I plan to perform more
    investigations later. You could keep your sample image
    for request later...

    Regards
    Guido
     
    Guido Vollbeding, Jun 9, 2004
    #17
  18. []
    Yes, I should always have something available, as I get the raw data all
    the time (a continuous satellite data stream averaging 1.1Mb/s).

    Cheers,
    David
     
    David J Taylor, Jun 9, 2004
    #18
  19. Pray tell, what defines your limits of "acceptable"?
     
    Brian C. Baird, Jun 9, 2004
    #19
  20. How can you say that without knowing anything about the data that David
    works with, *or* the wavelet-based algorithm that he uses?
    So far, this isn't much of a debate. You made a sweeping statement, and
    David pointed out that it is wrong at least in the domain where he
    works. So your statement is incorrect.

    You might be able to fix your statement by qualifying what sort of
    wavelet algorithm you were talking about (just JPEG2000?) and what sort
    of images you tested on, and how you determined whether an image is "too
    blurry" or not. Then it might become a debate.

    Dave
     
    Dave Martindale, Jun 9, 2004
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.