Rotating photo changes file size.??? Newbie question

Discussion in 'Digital Photography' started by QX, Oct 8, 2006.

  1. QX

    QX Guest

    Greetings all, Newbie here.
    I just experimented with a photo I took, where I had rotated the
    camera 90° when I made the exposure . I downloaded the image to my PC,
    and pasted it several times into a folder, naming each image something
    different. Then I rotated them back to the proper perspective. I used
    4 different programs to do the rotation. Here are the results based on
    the Win XP file properties screen for the photo:
    Original: 4,131,074 bytes 3.93 MB
    ======================================
    LView Pro 1,146,333 bytes 1.09 MB
    MS Picture It 2,007,928 bytes 1.91 MB
    WinXP 4.131.211 bytes 3.93 MB
    PS Elements 5,674,023 bytes 5.41 MB

    ..
    Can anyone explain why there is such a great difference in resultant
    file sizes between the different programs I used to rotate the image?
    (WinXP, I right clicked on the image, and selected <Rotate Clockwise>
    from the popup menu)
    Of particular interest is why the WinXP is slightly larger than the
    original, and why the PS Elements is so much larger?
    ..
    Based on the results, it would appear that I should use the WinXP or
    PS Elements to rotate images, for the largest (less loss) files.
    ..
    Does the group concur? or is there a better program to use?
    Thanks in advance
     
    QX, Oct 8, 2006
    #1
    1. Advertising

  2. QX wrote:
    > Greetings all, Newbie here.
    > I just experimented with a photo I took, where I had rotated the
    > camera 90° when I made the exposure . I downloaded the image to my PC,
    > and pasted it several times into a folder, naming each image something
    > different. Then I rotated them back to the proper perspective. I used
    > 4 different programs to do the rotation. Here are the results based on
    > the Win XP file properties screen for the photo:
    > Original: 4,131,074 bytes 3.93 MB
    > ======================================
    > LView Pro 1,146,333 bytes 1.09 MB
    > MS Picture It 2,007,928 bytes 1.91 MB
    > WinXP 4.131.211 bytes 3.93 MB
    > PS Elements 5,674,023 bytes 5.41 MB
    >
    > .
    > Can anyone explain why there is such a great difference in resultant
    > file sizes between the different programs I used to rotate the image?
    > (WinXP, I right clicked on the image, and selected <Rotate Clockwise>
    > from the popup menu)
    > Of particular interest is why the WinXP is slightly larger than the
    > original, and why the PS Elements is so much larger?
    > .
    > Based on the results, it would appear that I should use the WinXP or
    > PS Elements to rotate images, for the largest (less loss) files.
    > .
    > Does the group concur? or is there a better program to use?
    > Thanks in advance


    If you want to rotate a JPEG by exactly 90 degrees, you can do that in a
    lossless manner, and only Windows XP does that of the programs you tested.
    I would therefore suggest Windows XP, and avoid the others which are
    damaging your data.

    (Actually, there are free programs which will also do lossless JPEG
    rotation).

    David
     
    David J Taylor, Oct 8, 2006
    #2
    1. Advertising

  3. QX wrote:

    > Does the group concur? or is there a better program to use?


    David has explained the reason. However, I would recommend using a
    program with support for lossless rotation of JPEGs that isn't Windows
    XP. Windows XP rotate has a bug, so that it requires the dimensions of
    the JPEG to be dividable by 16, in order to perform lossless rotation.

    IrfanView, with the plugin pack, supports lossless rotation of JPEGs.
    A long list of programs can be found at
    http://sylvana.net/jpegcrop/losslessapps.html
    --
    Toke Eskildsen - http://ekot.dk/
     
    Toke Eskildsen, Oct 8, 2006
    #3
  4. Toke Eskildsen wrote:
    > QX wrote:
    >
    >> Does the group concur? or is there a better program to use?

    >
    > David has explained the reason. However, I would recommend using a
    > program with support for lossless rotation of JPEGs that isn't Windows
    > XP. Windows XP rotate has a bug, so that it requires the dimensions of
    > the JPEG to be dividable by 16, in order to perform lossless rotation.
    >
    > IrfanView, with the plugin pack, supports lossless rotation of JPEGs.
    > A long list of programs can be found at
    > http://sylvana.net/jpegcrop/losslessapps.html


    You cannot rotate losslessly /unless/ the JPEG has a size which is a
    multiple of 8 or, more likely 16, pixels. That's because of the way JPEG
    works, encoding the image into blocks of 8 or 16 pixels sqaure, it is not
    a defect of the Windows XP pitcure rotation. If you "losslessly" rotate
    an image which does not have that size, then the edge pixels in the
    resulting image will have been subject to lossy rotation. Perhaps that
    won't be noticeable as it will affect a small band of 8 or 16 pixels near
    the image edge.

    There are also programs which can losslessly crop as well - again in 8 or
    16 pixel steps.

    David
     
    David J Taylor, Oct 8, 2006
    #4
  5. David J Taylor wrote:

    [Toke: Windows XP ... requires ... dividable by 16 ... lossless]

    > You cannot rotate losslessly /unless/ the JPEG has a size which is
    > a multiple of 8 or, more likely 16, pixels.


    That is correct. It ties to the chroma subsampling. As fas as I
    remember, it is even possible to construct JPEGs, where the dimensions
    needs to be multiples of 32. But that's not something one would
    normally do.

    The the vast majority of digital cameras produces JPEGs where the width
    needs to be a multiple of 16 and the height a multiple of 8, in order
    to be losslessly rotated. Fortunately the same majority of cameras
    produces such images with dimensions that fit that description.

    > That's because of the way JPEG works, encoding the image into blocks
    > of 8 or 16 pixels sqaure, it is not a defect of the Windows XP
    > pitcure rotation.


    Yes it is. You will notice that I wrote 16, not 8. Windows XP cannot
    losslessly rotate JPEGs that are, for example, 32x24 pixels, no matter
    how the blocks are specified in the JPEGs.

    You could also call it a severe shortcoming, if you don't like the
    description "bug".

    > If you "losslessly" rotate an image which does not have that size,
    > then the edge pixels in the resulting image will have been subject
    > to lossy rotation. Perhaps that won't be noticeable as it will
    > affect a small band of 8 or 16 pixels near the image edge.


    It is my experience that it is quite visible on most pictures.
    I definitely prefer to throw away the non-losslessly-rotatable pixels.

    > There are also programs which can losslessly crop as well - again
    > in 8 or 16 pixel steps.


    Actually the cropping is a bit more flexible, as it is only the upper
    left corner, that needs to be a multiple. The lower right corner is
    free from these constraints.
    --
    Toke Eskildsen - http://ekot.dk/
     
    Toke Eskildsen, Oct 8, 2006
    #5
  6. Toke Eskildsen wrote:
    > David J Taylor wrote:

    []
    >> That's because of the way JPEG works, encoding the image into blocks
    >> of 8 or 16 pixels sqaure, it is not a defect of the Windows XP
    >> pitcure rotation.

    >
    > Yes it is. You will notice that I wrote 16, not 8. Windows XP cannot
    > losslessly rotate JPEGs that are, for example, 32x24 pixels, no matter
    > how the blocks are specified in the JPEGs.
    >
    > You could also call it a severe shortcoming, if you don't like the
    > description "bug".


    Well, it depends (to me) on how it is documented. If the description says
    "will rotate images which are a multiple of 16 in size" then I would call
    it a "limitation" or "constraint". If the documentation says "multiple of
    8" then I would agree it's a bug.

    >> If you "losslessly" rotate an image which does not have that size,
    >> then the edge pixels in the resulting image will have been subject
    >> to lossy rotation. Perhaps that won't be noticeable as it will
    >> affect a small band of 8 or 16 pixels near the image edge.

    >
    > It is my experience that it is quite visible on most pictures.
    > I definitely prefer to throw away the non-losslessly-rotatable pixels.


    So you would crop before rotation? Or let the program do that. It sounds
    a good approach to me.

    >> There are also programs which can losslessly crop as well - again
    >> in 8 or 16 pixel steps.

    >
    > Actually the cropping is a bit more flexible, as it is only the upper
    > left corner, that needs to be a multiple. The lower right corner is
    > free from these constraints.


    I haven't looked at the maths enough to know whether that's true or not
    (the part about allowing an arbitrary size when cropping). My gut feeling
    is that it doesn't sound right, but perhaps an expert like Dave Martindale
    will spot this thread and comment.

    David
     
    David J Taylor, Oct 8, 2006
    #6
  7. David J Taylor wrote:

    > So you would crop before rotation? Or let the program do that.


    jpegtran can do both: Automatically crop or leave the non-rotatable
    pixels.

    However, it is not very often I encounter an image that requires this.

    Toke:
    >> Actually the cropping is a bit more flexible, as it is only the
    >> upper left corner, that needs to be a multiple. The lower right
    >> corner is free from these constraints.

    >
    > I haven't looked at the maths enough to know whether that's true
    > or not (the part about allowing an arbitrary size when cropping).
    > My gut feeling is that it doesn't sound right, but perhaps an
    > expert like Dave Martindale will spot this thread and comment.


    No need. Fetch jpegtran and try it out:
    jpegtran -crop 123x123+16+8 in.jpg out.jpg
    produces an image of ... 123x131 pixels?

    Let's see...
    jpegtran -crop 123x115+16+8 in.jpg out.jpg
    produces an image of 123x123 pixels.

    Seems like there is a little bug in the Windows version. Anyway, the
    conclusion is the same: Cropping does not have the constraints on size.


    (okay, this is not a proof, since there could be recompression
    involved. But to my knowledge, jpegtran isn't capable of doing a full
    recompression)
    --
    Toke Eskildsen - http://ekot.dk/
     
    Toke Eskildsen, Oct 8, 2006
    #7
  8. Toke Eskildsen wrote:
    > David J Taylor wrote:

    []
    >> I haven't looked at the maths enough to know whether that's true
    >> or not (the part about allowing an arbitrary size when cropping).
    >> My gut feeling is that it doesn't sound right, but perhaps an
    >> expert like Dave Martindale will spot this thread and comment.

    >
    > No need. Fetch jpegtran and try it out:
    > jpegtran -crop 123x123+16+8 in.jpg out.jpg
    > produces an image of ... 123x131 pixels?
    >
    > Let's see...
    > jpegtran -crop 123x115+16+8 in.jpg out.jpg
    > produces an image of 123x123 pixels.
    >
    > Seems like there is a little bug in the Windows version. Anyway, the
    > conclusion is the same: Cropping does not have the constraints on
    > size.
    >
    >
    > (okay, this is not a proof, since there could be recompression
    > involved. But to my knowledge, jpegtran isn't capable of doing a full
    > recompression)


    I'll wait for Dave M's comments, before drawing any conclusions from what
    may be a flawed program or implementation.

    David
     
    David J Taylor, Oct 8, 2006
    #8
  9. QX

    Martin Brown Guest

    David J Taylor wrote:
    > Toke Eskildsen wrote:
    > > David J Taylor wrote:

    > []
    > >> I haven't looked at the maths enough to know whether that's true
    > >> or not (the part about allowing an arbitrary size when cropping).
    > >> My gut feeling is that it doesn't sound right, but perhaps an
    > >> expert like Dave Martindale will spot this thread and comment.


    It is correct. The strict requirement for lossless JPEG cropping is
    that the top left corner of the image must start on an exact boundary
    of both the luminance and chroma blocks. This usually means a multiple
    of 16 in horizontal and a multiple of 8 in vertical for a digicam
    image.

    There is no restriction on the bottom right corner position for
    cropping. The resulting file will contain all the information needed to
    create an image up to the next nearest multiple of 16 and 8 pixels
    respectively, together with a header that tells the codec how much of
    it to display.
    > >
    > > No need. Fetch jpegtran and try it out:
    > > jpegtran -crop 123x123+16+8 in.jpg out.jpg
    > > produces an image of ... 123x131 pixels?
    > >
    > > Let's see...
    > > jpegtran -crop 123x115+16+8 in.jpg out.jpg
    > > produces an image of 123x123 pixels.
    > >
    > > Seems like there is a little bug in the Windows version. Anyway, the
    > > conclusion is the same: Cropping does not have the constraints on
    > > size.
    > >
    > >
    > > (okay, this is not a proof, since there could be recompression
    > > involved. But to my knowledge, jpegtran isn't capable of doing a full
    > > recompression)

    >
    > I'll wait for Dave M's comments, before drawing any conclusions from what
    > may be a flawed program or implementation.


    The only gotcha is that a JPEG with image dimensions that are not exact
    multiples of the intrinsic JPEG block size cannot be losslessly rotated
    within the existing JPEG spec.

    It would in principle be possible to losslessly rotate any JPEG file
    with the addition of a couple of new JPEG tags to tell the decoder how
    much to crop off the top and left of an image.

    Nothing is actually lost when an image with an irregular size is
    rotated losslessly. But it must be rounded up to the next suitable size
    first. It is just that there will be a boundary of unwanted (previously
    undisplayed) pixels along the left and/or top of the desired image
    (depending on the actual rotation performed).

    The simplest tweak for this is to round up the dimensions to the next
    exact block multiple and then provide new tags to crop the unwanted
    data off so you can have perfect lossless rotation or cropping for any
    size of JPEG.

    Decoders that do not understand the new cropping tag will see an image
    16n x 8m pixels in size with a tatty border (upto 15 pixels wide) along
    the top and/or left edges. Compliant decoders will see an image 16n-x x
    8m-y suitably rotated.

    There was a thread about this topic here not long ago titled
    "irfanview lossless jpg rotation" and x posted to alt.comp.freeware
    some key parts of the thread are only in a.c.freeware

    Irfanview is a pretty good (free) choice for lossless JPEG operations.

    Regards,
    Martin Brown
     
    Martin Brown, Oct 9, 2006
    #9
  10. Martin Brown wrote:
    > David J Taylor wrote:

    []
    >>>> I haven't looked at the maths enough to know whether that's true
    >>>> or not (the part about allowing an arbitrary size when cropping).
    >>>> My gut feeling is that it doesn't sound right, but perhaps an
    >>>> expert like Dave Martindale will spot this thread and comment.

    >
    > It is correct. The strict requirement for lossless JPEG cropping is
    > that the top left corner of the image must start on an exact boundary
    > of both the luminance and chroma blocks. This usually means a multiple
    > of 16 in horizontal and a multiple of 8 in vertical for a digicam
    > image.
    >
    > There is no restriction on the bottom right corner position for
    > cropping. The resulting file will contain all the information needed
    > to create an image up to the next nearest multiple of 16 and 8 pixels
    > respectively, together with a header that tells the codec how much of
    > it to display.


    Many thanks for the explanation, Martin.

    []
    > Irfanview is a pretty good (free) choice for lossless JPEG operations.
    >
    > Regards,
    > Martin Brown


    Many thanks also for the clarification about the limits on lossless
    rotation. I read what you say as: "Given a change to the JPEG spec we
    could handle arbitrary size rotation, but not right now".
    I haven't used IrfanView for that (as I have other software), but if it's
    as good at lossless rotation as at everything else it does, I can believe
    you!

    Cheers,
    David
     
    David J Taylor, Oct 9, 2006
    #10
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Keith Sheppard

    Lossless rotation file size changes

    Keith Sheppard, Feb 4, 2004, in forum: Digital Photography
    Replies:
    2
    Views:
    913
    Guido Vollbeding
    Feb 4, 2004
  2. Richard Belthoff

    File Size vs. Printed Photo Size

    Richard Belthoff, Mar 19, 2005, in forum: Digital Photography
    Replies:
    19
    Views:
    530
  3. Re: File Size vs. Printed Photo Size

    , Mar 22, 2005, in forum: Digital Photography
    Replies:
    7
    Views:
    340
    Bubbabob
    Mar 24, 2005
  4. One4All

    Disconnect Between HD File Size & PS's File Size

    One4All, Sep 9, 2007, in forum: Digital Photography
    Replies:
    8
    Views:
    406
    One4All
    Sep 12, 2007
  5. Yong Huang
    Replies:
    2
    Views:
    341
    Yong Huang
    Feb 25, 2008
Loading...

Share This Page