Why is lossless rotation actually gainful rotation?

Discussion in 'Digital Photography' started by Louise, Jan 28, 2004.

  1. Louise

    Louise Guest

    Thanks for all your responses to my questions about
    rotation.

    I have now tried rotating an image in Irfanview and in
    Adobe PhotoImpressions. I have chosen lossless rotation in
    Irfanview and rotation - best quality, in PhotoImpressions.

    In both cases the resulting file is larger - about 500+ kb
    larger - with the same final size and number of megapixels.

    I think I don't understand the concepts involved and so I
    don't understand why the image doesn't stay exactly the
    same size.

    If data is actually added, does this really improve the
    image I would eventually print or have printed, does it
    make no difference in the image, or what is happening?

    Thanks again.
     
    Louise, Jan 28, 2004
    #1
    1. Advertisements

  2. I have now tried rotating an image in Irfanview and in
    Lossless rotation should _not_ change the file size.

    Try Jpegcrop from:

    http://jpegclub.org/

    (just use the rotataion, not the cropping, of course!).

    Cheers,
    David
     
    David J Taylor, Jan 28, 2004
    #2
    1. Advertisements

  3. Were your pre-rotation and post-rotation images in the same format,e.g.
    jpeg?
    If so, your original image was probably highly compressed (low quality).
    After rotation, you saved the image in a slightly compressed (best
    quality) mode. Regardless of the operation, saving an image at lower
    compression than the original always adds lots of Kb to the file size.
    Bob Williams
     
    Robert E. Williams, Jan 28, 2004
    #3
  4. Louise

    louise Guest

    My original images came directly from the CF card of the
    Canon S400 shot at the highest resolution 2272x1704 with
    compression set to "superfine" which the manual clearly
    says shoots the "highest quality image" - therefore, I
    assume, the lowest compression.

    They were both jpgs.


    Louise ()
     
    louise, Jan 28, 2004
    #4
  5. Louise

    Gary Edstrom Guest

    Note: Courtesy copy of this followup sent to author via email.

    Just as an experiment, I tried lossless rotation in my copy of
    ThumbsPlus. While the file size does grow a little, it is only about
    2.5Kb on a 2.5Mb file. If I do another lossless roatation to undo the
    first, the file size returns to just 20 bytes larger than my original
    file. So, file sizes do change, but not by 500Kb, at least in
    ThumbsPlus. The file never seems to return to EXACTLY the same size.
    Here are the results of my test.

    Original 2,571,511
    +90 degrees 2,574,130
    -90 degrees 2,571,531
    +90 degrees 2,574,112
     
    Gary Edstrom, Jan 28, 2004
    #5
  6. That is not true.

    Lossless rotation first uncompresses the lossless
    compression, then it rotates losslessy and last it
    applies the lossless compression again. All three
    lossless operations.

    But the lossless uncompress and later compress does
    not guarantee that the size is the same.

    A difference of 500 KB sounds large though.


    /Roland
     
    Roland Karlsson, Jan 28, 2004
    #6
  7. Louise

    Chris Doran Guest

    Hmmm, I've just tried a few in Irfanview, and with Optimise JPEG
    ticked, they actually get a little smaller, certainly not bigger. Can
    you point us to an example that grows -- someone's web photo album,
    perhaps?

    Chris
     
    Chris Doran, Jan 29, 2004
    #7
  8. Louise

    Ed Guest

    Hello Louise!

    The simple answer to your question is just as Bob said -
    your camera is using a higher compression ratio in its
    JPGs than the software you're using. When your manual says
    "superfine" gives the "highest quality image" they are saying
    the highest quality image the camera will output, not the
    highest quality (least compression) possible with JPG compression.
    When you recompress the image with software and select highest quality
    then the data is compressed less than it was by the software in the
    camera, hence a larger file.

    Try this to confirm. Open file from your camera and don't
    do any rotation. Just immediately save using the compression
    settings you've been using to test the rotation data. If Bob and
    I are right, the file will be about 500 kb larger than the file
    directly from the camera. The increase in file size won't be from
    the rotation (because there was none) it will be from the different
    compression ratios in your camera and software.

    Best regards,
    Ed
     
    Ed, Jan 29, 2004
    #8
  9. Louise

    Ron Hunter Guest

    The reason is that the compression ratio for the source of the picture
    doesn't match that of the setting of your program. If they don't match,
    the resulting file will be either larger or smaller than the original.
    Larger is better since making the file smaller will lose data while the
    larger file may retain all the information.
     
    Ron Hunter, Jan 29, 2004
    #9
  10. Lossless rotation should _not_ change the file size.
    No, the rotation is done with the data still in its compressed state.
    That is the key to introducing no further degradation of the image. The
    file size should be identical (give or take a few bytes if the headers
    change).

    We are talking here about an operation on a JPEG file. The data in JPEG
    files has lossy compression applied, not lossless as you say.

    Cheers,
    David
     
    David J Taylor, Jan 29, 2004
    #10
  11. David,
    Roland is right here.
    JPEG *has* a lossless compression *part* in its process, and this part
    is responsible for small differences in the compressed size between
    original and rotated file.
    The lossless compression part is also called "Entropy Coding".
    See also the "Entropy Coding Option" in Jpegcrop:
    http://jpegclub.org/jpegcrop/ .

    Regards
    Guido
     
    Guido Vollbeding, Jan 29, 2004
    #11
  12. If you perform such a sequence with jpegtran or Jpegcrop, the second
    and fourth number should be identical, proving the lossless operation.
    In fact, that would be my recommendation to verify lossless operation.
    The first and third number may differ due to marker variations if the
    Original was generated with another JPEG compressor.

    Your differences with ThumbsPlus seem strange to me. Perhaps the
    program stores some adaptive comment info into the header.

    Regards
    Guido
     
    Guido Vollbeding, Jan 29, 2004
    #12
  13. []
    Accepted, but very few people will be aware of the internals of a JPEG
    file. It is because of the coding process that you can losslessly rotate
    blocks, even though those blocks themselves contain lossy-compressed data!
    I guess I was too keen to avoid the words lossless and JPEG in the same
    sentence!

    Cheers,
    David
     
    David J Taylor, Jan 29, 2004
    #13
  14. Well, perhaps one day I will present an understandable explanation of
    how JPEG works.
    The funny thing is that even the JPEG authors didn't know one of the
    most natural reasons *why* JPEG works, and thus introduced some obsolete
    processing modes, and couldn't exploit all of its capabilities.
    I discovered this recently when finding the new JPEG scaling options.
    (Part of an explanation you can find in a paper which I prepared for
    a workshop at http://jpegclub.org/temp/ .)
    Yes, but those blocks containing lossy-compressed data are not the direct
    image of the compressed file data - there is the lossless entropy coding
    stage in-between.
    This is somewhat similar to the lossless compression used in the common
    zip utilities: Suppose you have a text file and compress it to a zip file.
    Now you reverse the text, that is you start with the last letter and write
    it on to the first. This is kind of a lossless text transformation, similar
    to a 90-degrees rotation of image data in the spatial (pixel) domain.
    Now would you expect *the same* compressed zip file size with the reversed
    text? Probably not, because the text input looks different to the zip
    program. However, you wouldn't expect a *too large* difference, because
    the reversed text is somehow 'similar' to the original.

    Regards
    Guido
     
    Guido Vollbeding, Jan 29, 2004
    #14
  15. Give us the exact pre and post-rotation image sizes in MB.
    Bob
     
    Robert E. Williams, Jan 29, 2004
    #15
  16. Louise

    Martin Brown Guest

    I suspect what is happening is that the camera has saved the JPEG with a
    fully optimised lossless encoding of the coefficients and the lossless
    rotation program is using the unoptimised default coefficient tables.

    There may be an option for optimised coefficient encoding.
    So the extra size was about 20% extra on the camera JPEG?
    That sounds about right for optimised Huffman table vs the default (a
    bit high but then you can never be certain since it is data dependent).

    You can test the process for being lossless by JPEG rotating the image
    again back to align with the original camera shot and then subtract that
    image from the true camera image.

    For devious technical reasons of colour subsampling 2x1 vs 1x2 you may
    not get an exact match if you try comparing the image made from the
    rotated JPEG and the original JPEG image after rotation.

    Regards,
     
    Martin Brown, Jan 30, 2004
    #16
  17. I suspect what is happening is that the camera has saved the JPEG with a
    I had always understood that true "lossless rotation" would preserve such
    tables....

    David
     
    David J Taylor, Jan 30, 2004
    #17
  18. Louise

    Martin Brown Guest

    It might, but there is absolutely no guarantee (in fact it is highly
    unlikely) that the optimised table for the original image and the one
    for the rotated image will be the same. Using a good generic default
    table might even be preferable. It is still lossless it just isn't as
    compact as it could be.

    Regards,
     
    Martin Brown, Jan 30, 2004
    #18
  19. It might, but there is absolutely no guarantee (in fact it is highly
    Yes, I see what you mean.

    Thanks,
    David
     
    David J Taylor, Jan 31, 2004
    #19
  20. No, lossless rotation either uses the default Huffman tables, or generates
    new optimized Huffman tables. It preserves the *quantization* tables, but
    that's another subject.

    Regards
    Guido
     
    Guido Vollbeding, Feb 2, 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.