Uhhh - please go talk to someone else at Smugmug about his because this is absolutely not true. If one is only comparing the true number of bits in the file (as per the filesize of the file and not looking at whole clusters or anything like that) then ANY change in bits is file corruption or modification - plain and simple.
When I transfer 1,030,546 bytes from one place to another, those 1,030,546 should be EXACTLY the same at the destination. If they are not, then the data has been corrupted. If I copy it to one disk, then from there to another, then from there to another, those 1,030,546 bytes should still be exactly the same.
Thank you for seeing this too John. For a second I was like
I'd like to know the outcome of this too. If you could please post back what you find out about the issue, if there is one, to this thread. I'd appreciate it.
I've done a quick check of some of the jpgs I've uploaded to SmugMug and what came back was the same as what when up.
I've done a lot of http downloading implementations and haven't seen an issue where what came back was different from what when up. If there are some kind of edge case around jpg's I'd really like to know about it.
I'm sorry but I beg to differ. This is not data corruption. It's like when files on a hard disk become fragmented. This is a totally normal situation and the nature of the way bits get written to the hard disk through normal usage. That data may be fragmented however that does not instantly mean they are corrupt.
I'd like to know the outcome of this too. If you could please post back what you find out about the issue, if there is one, to this thread. I'd appreciate it.
I've done a quick check of some of the jpgs I've uploaded to SmugMug and what came back was the same as what when up.
As have I. In fact, I've probably done the most extensive testing of this ever, uploading and downloading about 200gb with not a single error.
Personally, I think it's a bug somewhere on the back end when dealing with the Canon 50D or it's JPG files as part of RAW+JPG. They've passed it on to an engineer who's looking into it, but this could mean a lot for a lot of people since the Canon 50D is a popular camera.
Well, since I just experienced this problem with a Nikon D60, and haven't received an answer from support, I figured it out on my own. So here's what's going on.
My older cameras don't have an orientation sensor, so they don't embed any information in the original picture. These images are the exact same when uploaded and then downloaded from SM. If they are rotated, they are no longer the same.
Newer cameras like the Canon 50D and Nikon D60 have an orientation sensor. It seems that SM picks up this information and automatically runs the rotate image routine on the images as they are uploaded. Kinda like the automatic watermarking. The problem with this is that an image that is rotated is always different than the original, so there is no way to get the original back from SM since it is altered upon upload.
The way to avoid this issue is to not use the orientation sensor built into newer cameras and manually rotate images in a gallery. But since the rotate tool doesn't always work right, that wastes a lot of time.
So to summarize, the infrastructure at SM is capable of producing exact bit-by-bit copies of your originals, but only if your originals are not altered. Because most modern cameras use an orientation bit, most cameras will have some images immediately altered upon upload, and hence not be available as a bit-by-bit exact copy for download.
I ran into this thread researching something else and would like to add some experience from the entire year of 2010.
In this year, I created and uploaded over 100,000 photos to SM. Each of these photos were downloaded using either Albumfetcher or the new 'download all' option under Tools. In every case where an original photo did not compare to be the bit-by-bit exact same with what I uploaded to SM, there was an error in the upload to SM. Some of these were listed in the upload log, other weren't. But once the file was replaced and re-compared, it compared bit-by-bit perfect with the original.
This is around 250GB of data that has been uploaded and then downloaded from SM and compared bit-by-bit with the original file. And every single file compares correctly.
I don't think anyone at SM might have done this type of extensive testing, so I thought you might like to know. Great little storage system you've got there.
Comments
Want faster uploading? Vote for FTP!
I've done a quick check of some of the jpgs I've uploaded to SmugMug and what came back was the same as what when up.
I've done a lot of http downloading implementations and haven't seen an issue where what came back was different from what when up. If there are some kind of edge case around jpg's I'd really like to know about it.
Thanks in advance.
http://www.danalphotos.com
http://www.pluralsight.com
http://twitter.com/d114
Personally, I think it's a bug somewhere on the back end when dealing with the Canon 50D or it's JPG files as part of RAW+JPG. They've passed it on to an engineer who's looking into it, but this could mean a lot for a lot of people since the Canon 50D is a popular camera.
Want faster uploading? Vote for FTP!
My older cameras don't have an orientation sensor, so they don't embed any information in the original picture. These images are the exact same when uploaded and then downloaded from SM. If they are rotated, they are no longer the same.
Newer cameras like the Canon 50D and Nikon D60 have an orientation sensor. It seems that SM picks up this information and automatically runs the rotate image routine on the images as they are uploaded. Kinda like the automatic watermarking. The problem with this is that an image that is rotated is always different than the original, so there is no way to get the original back from SM since it is altered upon upload.
The way to avoid this issue is to not use the orientation sensor built into newer cameras and manually rotate images in a gallery. But since the rotate tool doesn't always work right, that wastes a lot of time.
So to summarize, the infrastructure at SM is capable of producing exact bit-by-bit copies of your originals, but only if your originals are not altered. Because most modern cameras use an orientation bit, most cameras will have some images immediately altered upon upload, and hence not be available as a bit-by-bit exact copy for download.
Want faster uploading? Vote for FTP!
In this year, I created and uploaded over 100,000 photos to SM. Each of these photos were downloaded using either Albumfetcher or the new 'download all' option under Tools. In every case where an original photo did not compare to be the bit-by-bit exact same with what I uploaded to SM, there was an error in the upload to SM. Some of these were listed in the upload log, other weren't. But once the file was replaced and re-compared, it compared bit-by-bit perfect with the original.
This is around 250GB of data that has been uploaded and then downloaded from SM and compared bit-by-bit with the original file. And every single file compares correctly.
I don't think anyone at SM might have done this type of extensive testing, so I thought you might like to know. Great little storage system you've got there.
Want faster uploading? Vote for FTP!