Random EXIF Stripping on Alternate Sized Files, Original on SM Retains EXIF
brecklundin
Registered Users Posts: 121 Major grins
Here is one shot with EXIF intact:
And here is a shot from the same gallery that SHOULD show the EXIF but does not:
On the 2nd shot as well as the rest of the shots, if I look at the original file, the EXIF is there. And before the past week or two, the EXIF was always intact for resized images used linked to on other sites (forums).
So, there is nothing we users are doing to cause this, it has to be something in the code used to generate the alternative sized files. (remember the original file, on SM, has all the EXIF intact.)
This is a really annoying issue and, frankly, not what I would expect from a service such as SM.
Given the EXIF is there, And both the above shots are contained in the SAME GALLERY, there is nothing I as the customer can do to further troubleshoot the issue. I have no control over the generation of the alternative files from the uploaded originals.
And here is a shot from the same gallery that SHOULD show the EXIF but does not:
On the 2nd shot as well as the rest of the shots, if I look at the original file, the EXIF is there. And before the past week or two, the EXIF was always intact for resized images used linked to on other sites (forums).
So, there is nothing we users are doing to cause this, it has to be something in the code used to generate the alternative sized files. (remember the original file, on SM, has all the EXIF intact.)
This is a really annoying issue and, frankly, not what I would expect from a service such as SM.
Given the EXIF is there, And both the above shots are contained in the SAME GALLERY, there is nothing I as the customer can do to further troubleshoot the issue. I have no control over the generation of the alternative files from the uploaded originals.
0
Comments
EDIT: Now I can read the EXIF again...could this be a browser thing? I am using IE8 but it should not matter as I use Opanda's iEXIF viewer as well as another EXIF plug in that displays any basic EXIF data in the browser's status bar. I do not have an EXIF viewer installed on FF but will add on now.
No matter it should not happen like this...and I know it's not an IE8 thing because I only upgraded this week and we began noticing the issue a couple weeks ago or more.
I just tripped across something new. I realized something about the first shot above...the original is the same size as the "Large" image size so there was no processing of the image for image sizes large through original. Hence the EXIF data is retained.
If you click here:
http://www.brecklundin.com/gallery/8294929_3vFhZ#546946787_8Vtcd-X2-LB
Then click on any size smaller than large...the EXIF will NOT BE THERE. But from large on up, it's there. Sooooo, it seems to me since I am not the one processing the files to create the other sizes, the deal is indeed within the SM image processing code somewhere.
The issue where I could not read the EXIF after previously being able to must have been on my end and unrelated to the topic for this thread as a reboot solved that issue, and NO a cache clearing did not resolve that issue. Don't even go to the clear-your-cache dance with me...it works NOT AT ALL 99.9% of the time with modern browsers yet it's the first utterance from any support script.
that is completely unacceptable. Nor was I informed of that significant issue when I paid for a YEAR in advance. I am far from a neophyte in the world of development. This is not how a company which tries to pass itself off as a high end service would function.
It may seem trivial to you...but it is also nickle and dime BS from to perspective of a customer.
We haven't hid this for 7 years we've been in business. I'm sorry.
But you'll be happy to know that we're working on some new image processing that will keep exif in the display copies.
Hang in there it's something that we hope to do pretty soon. But it is software and anything can happen.
When the file is 800px or smaller, the exif is retained: http://www.brecklundin.com/photos/546946787_8Vtcd-L.jpg
Portfolio • Workshops • Facebook • Twitter
Thanks Andy,
I know my post came across as terse...but that was in reply to the original answer.
Even so, it is not a great thing to discover. I would not say upset is the way I feel...more let down is how I feel about the issue. Something like this is probably one of the few things easily assumed as a given for a site dedicated to photography and image hosting. People expose SmugMug to the world in forum and blog posts. Places where that info is crucial to the discussing not being there makes the person look either lacking in knowledge or lazy, neither of which is a good thing. Add to that my initial confusion as to why some shots showed EXIF info off-site w/o issue and some did not and you can understand my disappointment as well as embarrassment for assuming it was there so no need to post it along with the image...it was not until I looked more closely that I discovered the pattern this AM.
On nice thing of having RA is it often keeps me from being able to sleep...gave me time to work on the problem.
And yes, I do understand the development/maintenance cycle can be a very fluid thing and certain fires simply come along pushing other projects down the priority list. Yet in this case, even a roll your own image management component is at most a 3-4 week project for a 2-3 person team. Unless of course you are revamping the whole backend image management/manipulation tool set. But OTOH, you mention seven years...completely not acceptable for something so intrinsic/fundamental to the purpose of the site to be absent for seven years. At least from the peanut gallery it seems that way. But color me confused at best...
I have paid for my year and we will see where it goes. Not sure I will be very willing at present to recommend the site to others just yet. Though I do like the customization portion, but I also feel like my hands are tied because of the lack of access to back end server side code modules. That issue I was aware of at the time I decided to use SM. What I never thought of was keeping my original site and merely setting up the SM site as a sub-domain of my original site. It would have fit with my ecommerce plans better. I am not sure if that was ever mentioned in the doco for the site (which, overall I like very much, in fact it might be the best doco for a host service I have come across in the 30+ years of development I subjected myself to...hehe)
But, I do not recall reading anywhere that specifically told me that EXIF was stripped from images posted on other sites, so if I wanted the info included I should upload images which fit the constraints of the sites where I would expect to use the images. So, for now the obvious work around will be 2-3 versions of many of my images. Hey, it's not my server space being gobbled up, only my heartbeats spent manually doing what a few dozen lines of code (or few hundred, it is not many added to the existing code) should be doing automagically.
Like I wrote, I am not upset, but rather I feel let down in my expectations and obviously now wonder what other walls I will encounter. Hence my reluctance to recommend the site to clients and friends at this point in time, my reputation is important to me and i do not want to be apologizing for something like this every time we/they attempt to do something with a site hosted here. So, I'll just consider this year as a beta period with me as the test subject who is not in the control group taking the placebo...
At least now I know the drill...so thanks for the response.
Hey Andy,
Are you certain about the 800px limit? I ask as this is a 900x600 image which retains EXIF:
http://www.brecklundin.com/gallery/7900008_xPdaQ#511921338_jvTxH-A-LB
I can experiment later but if you have more firm info on the exact size constraints it would be helpful. As in is it a limit on just the longest side or a total number? If we can use 1024 long side or square, that is usually the max on the most generous sites such as POTN.
No matter the above shows the 800px number is not correct, unless it is a vertical limit...so a 1024x800 image might be the max size would make sense.
You guys need to figure out the way to have EXIF remain in every size photograph. Picasa has it figured out. Flickr has it figured out. I doubt it is a very difficult thing to do for your programmers. Having EXIF is very very important.
D700/ 50mm 1.8G/ 85mm 1.4D /28-105D
D90/ 18-200VR /35mm 1.8G /Tokina 11-16 F/2.8
Canon:
T2i kit/ 17-55 F2.8 /17-85
This matter has been discussed here fairly recently. I agree with you: it's something which needs to be sorted out—not just the preservation of EXIF metadata, but also the IPTC data.
Last time I checked, Flickr isn’t preserving this data in its resized images. That is to say, if you save one of the smaller sizes from Flickr you will find none of the extended metadata (EXIF or IPTC) in the jpeg.
Portfolio • Workshops • Facebook • Twitter
Thanks for the link to the other thread.
One of the reasons I chose SM over flickr was because I never read anywhere in the help files and how-to's that EXIF was removed for resized images.
What I have discovered in testing is the maximum long side length that will preserve intact EXIF info, at least the basic stuff, I am not to the point of using the extended EXIF data but do see it's important. Anyway, the make size that SM seems to leave alone is an image with a long edge of 1024. Over that and you have to use a link to the original.
I have not fully figured out the actually dimensions of each size (S-M-L-XL-X2-X3) here on SM. I am sure it is listed somewhere or found in the forums. I find that the X2 seems to have the max height of 1024 and the X3 a max width of 1024 before EXIF is stripped by processing.
More tested would be needed to determine the (x,y) dimensional limits before image processing kicks in but, it's not something I am going to waste my time on. Rather I will use storing duplicates of ALL images with a max long dimension of 900px. More than that is a problem on many sites so no reason to bump it up to 1024 even though we apparently can.
Here are a couple examples with EXIF preserved and a long dimension of 1024:
http://brecklundin.smugmug.com/photos/550196917_A8zVZ-X2.jpg (~500KB)
http://brecklundin.smugmug.com/photos/550196245_Lqs6V-X3.jpg (~300KB)
I will leave my pet peeve of altering the URL for images to include SM rather than my full domain name for another time...well, a small jibe is OK I suppose...I pay to have the ability to use my own URL and expect it, and only it, to appear in any links generated. It feels like a cheap marketing parlor trick. If I like SM I will steer my clients here for you...and yeah, I know I just need to alter the URL provided to point to my domain, but why spend the time manually doing yet another thing...ok, mini-rant over...hehehehe....
NOTE: I changed to links rather than inline images because of the file sizes
I originally used inline images rather than just posting the URL so you get an idea of each size if someone does not know, for forum use 1024 is pretty large. But because of the files not having been compressed on my end I changed it to URL links.
I do not like having to do 2x the uploads as well as maintaining at least one added copy of each file on my account. Something else this means is if SM actually creates a real copy of the file on upload rather than conversion on the fly/demand, it will be at 4-6 extra files for each duplicate image uploaded. So, not a good work around for us nor good for SM in terms of storage space.
We'll see just how soon a solution of presented by SM. But for now, at least we know the max is 1024 in width makes the file retaining EXIF is X2 image and if the image height is 1024 the SM size is X3. None of it matters since I will just use a link to the original I upload presized but again it is nice to know the dimensional constraints which trigger processing on SM's end.
I have not tested what happens with a 1024x1024 image. It might be there is a horizontal dimensional trigger for processing as well. Only testing a square image using the other known triggers will reveal if there is a limit on the small side dimension of a 1024px image.
One thing to remember if you use my method. When exporting/generating the images prior to upload, be sure and precompress the images or you will end up with pretty large file sizes of around 500k as shown in the two images in this post.
Because 1024 is your Original and the same size as X2. Make Sense? Guys, we really have something in the works, stay tuned.
Portfolio • Workshops • Facebook • Twitter
Hi Andy,
Thanks for the reply and encouragement. Everyone from Sm is genuinely nice and helpful so please know as I mentioned before I am not upset here, only am not curious what the triggers are so I am looking at them more closely. But I fully understand the reasons WHY, that is trivial and easily understood, each size designation has predefined dimensions, so that's kinda of a '"no d'uuuuh" thing...of course there are dimensional limits on each size...THAT IS HOW ONE DEFINES/delineates SIZES of objects...hehehehe
Rather, it is the lack of where the size constraints for each SM image size designation that is the motivation to explore when they trigger processing. Is there a list ANYWHERE in the help section that tells us what the long dimension is for each SM image size? Here I have already determined 1024 represents the trigger upper bound for processing on the horizontal dimension of an X2 size and 1024 represents the upper bound limit for the vertical dimension for an X3 size image.
Example:
http://brecklundin.smugmug.com/gallery/8384535_HiVHf#550272894_htBu9-X3-LB
Portfolio • Workshops • Facebook • Twitter
Awesome, thanks Andy...it's under VIEWING...who woulddathunk to look THERE!!
You can check out the gallery in question here:
http://photos.wendellbeitzel.com/gallery/8596047_89gcM
This kind of throws off vacation/trip galleries because now they are not displaying in the correct order. Anything I can do?
Thank you!
Edit: Ok, so I figured out that it seems to be Send to Smugmug that is causing the problems. What I did was delete the gallery, and created another one. Then I tried to re-upload the images using the normal uploader. But even though the iamges had been deleted it was acting as though they were already uploaded and just checking each photo. What I need to do is fully re-upload every image. Any easy way to do this?
Thanks!
Portfolio • Workshops • Facebook • Twitter
Yeah, I've tried deleting and reuploading the files using several different methods, and each time it doesn't actually upload fresh files. It is like when I delete them it just deletes the references to them. Then when I re-upload the files it is just reattaching references to the existing files.
Any ideas?
Thanks Andy
I've even tried deleting the gallery and creating new galleries. Seems to always use the old files.
So.. its December and you posted this in May... and the problem still exists.
Any word?
Thanks,
My Gear
Sebastian
SmugMug Support Hero