locked
Danger -- Photo Gallery Viewer Destroys Data Without Warning RRS feed

  • General discussion

  • I was reviewing some jpg photos in PGV and wanted to see one item rotated through a right angle. I clicked to rotate the pic and found that the file on disk had immediately been over-written with a rotated image. No confirmation. No warning that my original would be lost. And the unwanted image was less than a third of the size of the original. Had I lost perceptible resolution? Yes, I had.

    Secure by design? Hmm -- it seems I no longer need those script kiddies to destroy my data now that I have an 'operating system' to do it for me.

    MS Vista boys please note:
    i) There is no need to change any original data file on disk when the user adopts a different view of his data.
    ii) Even if you think people want their data files overwritten with something else, it is good practice to give those people the choice before you do so.

    Could we correct this serious feature before subjecting millions of people who aren't data recovery professionals to it, please?

    Wednesday, August 2, 2006 8:23 PM

All replies

  • My personal opinion after looking into an "all-in-one" solution with Photo Gallery and Media Center is this; If the picture / video handling was more like what Google did with Picasa2, I would be jumping for joy... It will save a second "edited" copy of any photo, and allow you to "undo" edits anytime in the future without touching the original.

    Also, Windows Media Player and Media Center need some better support of video file formats. I always resort to a third party solution for my digital video files. Anyway, personal ramblings, nothing more...

    Thursday, August 10, 2006 6:31 PM
  • Thanks for the feedback.  Indeed as you notice we actually rotate the file.  In most cases this rotation is completely lossless.  There is absolutely no pixel data loss when performing a lossless JPEG rotation where the dimensions of the photo are a multiple of the block size (which isn’t always 8, it is more often 16).  I don’t believe that there are any current cameras that generate files that cannot be losslessly rotated (some older cameras did, however).

     

    There are several reasons a file may change size when it’s rotated, even if no pixel data changes.  For instance we generate a new embedded thumb for the rotated image,  in many cases our thumb is smaller than the camera generate thumb.  That said loosing 1/3 of the file size isn’t typical.  What camera did this file come from?   Did you process it with any software prior to the rotate?  I’d like to try to reproduce what you are seeing so I can ensure there isn’t a bug.

     

    If the JPEG can’t be losslessy rotated it will be rotated and re-encoded.  Because JPG is not a lossless format there will changes to the data whenever the file is re-encoded.  These changes are generally not perceptible.  There was a time when we did warn before doing a lossless rotate but it makes little sense to most users who just want to see the photo in the orientation they took it.  For usability reasons we no longer have that warning. 

     

    I should also note that we don’t immediately write the data out on rotate.  It is written out once you leave the viewer.  A 180 degree rotate only takes 1 encoding just like a 90.

     

    John Thornton [MSFT]

    Window Photo and Imaging Program Manager

     

    ***This posting is AS IS and confers no rights.

    Friday, September 22, 2006 6:55 PM
  •  John M. Thornton wrote:

    Thanks for the feedback.  Indeed as you notice we actually rotate the file.  In most cases this rotation is completely lossless.  There is absolutely no pixel data loss when performing a lossless JPEG rotation where the dimensions of the photo are a multiple of the block size (which isn’t always 8, it is more often 16).  I don’t believe that there are any current cameras that generate files that cannot be losslessly rotated (some older cameras did, however).

     

    There are several reasons a file may change size when it’s rotated, even if no pixel data changes.  For instance we generate a new embedded thumb for the rotated image,  in many cases our thumb is smaller than the camera generate thumb.  That said loosing 1/3 of the file size isn’t typical.  What camera did this file come from?   Did you process it with any software prior to the rotate?  I’d like to try to reproduce what you are seeing so I can ensure there isn’t a bug.

     

    If the JPEG can’t be losslessy rotated it will be rotated and re-encoded.  Because JPG is not a lossless format there will changes to the data whenever the file is re-encoded.  These changes are generally not perceptible.  There was a time when we did warn before doing a lossless rotate but it makes little sense to most users who just want to see the photo in the orientation they took it.  For usability reasons we no longer have that warning. 

     

    I should also note that we don’t immediately write the data out on rotate.  It is written out once you leave the viewer.  A 180 degree rotate only takes 1 encoding just like a 90.

     

    John Thornton [MSFT]

    Window Photo and Imaging Program Manager

     

    ***This posting is AS IS and confers no rights.

    Here's some more feedback on the issue. If there is any possibility of an application overwriting my data, even if it should be losless "most of the time," I know I would want to be notified. It shouldn't be up to Microsoft to decide if I can live with the possible loss of quality. You are modifying my original files with no warning, and you may even be re-encoding it. Please add a confirmation for this. I certainly will not want to use a piece of software that behaves this way.

    Saturday, September 23, 2006 12:32 AM
  •  John M. Thornton wrote:

    Thanks for the feedback.  Indeed as you notice we actually rotate the file.  In most cases this rotation is completely lossless.  There is absolutely no pixel data loss when performing a lossless JPEG rotation where the dimensions of the photo are a multiple of the block size (which isn’t always 8, it is more often 16).  I don’t believe that there are any current cameras that generate files that cannot be losslessly rotated (some older cameras did, however).

     

    There are several reasons a file may change size when it’s rotated, even if no pixel data changes.  For instance we generate a new embedded thumb for the rotated image,  in many cases our thumb is smaller than the camera generate thumb.  That said loosing 1/3 of the file size isn’t typical.  What camera did this file come from?   Did you process it with any software prior to the rotate?  I’d like to try to reproduce what you are seeing so I can ensure there isn’t a bug.

     

    If the JPEG can’t be losslessy rotated it will be rotated and re-encoded.  Because JPG is not a lossless format there will changes to the data whenever the file is re-encoded.  These changes are generally not perceptible.  There was a time when we did warn before doing a lossless rotate but it makes little sense to most users who just want to see the photo in the orientation they took it.  For usability reasons we no longer have that warning. 

     

    I should also note that we don’t immediately write the data out on rotate.  It is written out once you leave the viewer.  A 180 degree rotate only takes 1 encoding just like a 90.

     

    John Thornton [MSFT]

    Window Photo and Imaging Program Manager

     

    ***This posting is AS IS and confers no rights.

    I think you're completely missing the point...

    If I browse a group of pictures in say - PaintShop Pro, Photoshop, or pretty much ANY other piece of graphics software on the market that does this sort of thing - AND I open a file for a more closeup view of the thumbnail AND I rotate it for whatever reason, I can:

    a.) Undo the action - IN MEMORY - without it being saved to the disc

    b.) Simply close the file being edited and STILL have my original, unrotated image on the hard drive.

    c.) Close the image, and have the program ask if I want to SAVE the changes I made.

    For that matter, most other pieces of well behaved software from lowly Notepad, to MS Office and pretty much everything in between will likewise require you to click the SAVE icon, or prompt you for a save if you close the document without saving. Few, if any well behaved apps will make drastic changes to your work files prior to commiting them to disk.

    Sunday, September 24, 2006 11:23 PM
  • This behavior needs to be changed. I'm not using Photo Gallery until it is.

    No excuses.

    Wednesday, September 27, 2006 11:52 AM
  • agreed...  if data or quality loss is going to occur, then the user should be asked if he/she wants to proceed.  if it is indeed a lossless rotation that has taken place, then i wouldn't mind so much if it didn't ask if i wanted to save, but if it is going to effect the photo in any other way other than rotation, then yeah, don't just save the file automatically.
    Sunday, October 29, 2006 2:34 AM
  • I have no idea why they'd pay more attention to this than to this obviously destructive problem.

    But it underlines the lack of agility at Microsoft recently.

    Sunday, October 29, 2006 3:10 AM
  • John, I know it's late for this release of Vista, but for the next, consider this.

     

    Take this Google Image search: http://images.google.ca/images?hl=en&q=john

     

    Now look at the dimensions for the images:

    700x1238, 835x1287, 143x143, 273x284, 461x559, 350x399, 1139x1709, 720x576, 790x1069, 790x1087, 440x330, 650x639, 998x1670, 676x900, 1600x1200, 268x400, 700x525, 700x385, 550x686, 230x300

     

    Of the 20 images returned by this query, 18 of them have at least one dimension not divisible by 8. It's safe to say that roughly 90% of all images on the Web will break if rotated with the Photo Gallery.

     

    I don't know what sort of usage testing you did, but if the results indicated that all or even most images used with Photo Gallery are from cameras and specifically new cameras, I suggest you consider a serious reevaluation of your methods.

     

    I should also note that we don’t immediately write the data out on rotate.  It is written out once you leave the viewer.  A 180 degree rotate only takes 1 encoding just like a 90.

    Is that supposed to be an excuse or something? Because the only way this solves the problem at all is if Photo Gallery crashes.

     

    Not to mention, this is a severe design flaw in itself. It's prone to race conditions. Picture:

    -User rotates an image in Photo Gallery

    -User opens picture in another application

    -User makes modifications to the picture, saves them and closes the application.

    -User unsuspectingly closes Photo Gallery, not knowing that it will overwrite the work that he did in the other application.

    Sunday, October 29, 2006 10:57 AM