JPEG Format/Corruption Question

djlin

Hi. I am relatively new to SmugMug so apologies if this a question that has been addresed in the past - I've searched the forum and could not find the answer.

I am struggling with an issue with the SmugMug jpg format. When I move a SmugMug generated jpg photo to my RAZR phone (just plug the phone into the computer with a USB cable, save the SmugMug photo (S size) to my hard drive, and drag it into my phone's file system), the phone's picture viewer can't render the jpg file on the phone screen and complains that it is somehow corrupt. I've also noticed that my older version of Quicktime Picture Viewer on my PC also can't render the SmugMug jpg files. When I try to do the same thing with, for example, a Flickr generated jpg photo, my cell phone is able to render their generated jpg on the phone screen.

I've noticed that if I take the SmugMug jpg photo, bring it into MS Paint and resave it as another jpg photo - that newly saved photo does render on the phone screen. The MS Paint rendered jpg photo is about half the size of the original SmugMug jpg photo. Do you know what the issue might be in terms of the jpg formats?

Thanks

luke_church

djlin wrote:

I've noticed that if I take the SmugMug jpg photo, bring it into MS Paint and resave it as another jpg photo - that newly saved photo does render on the phone screen. The MS Paint rendered jpg photo is about half the size of the original SmugMug jpg photo. Do you know what the issue might be in terms of the jpg formats?

Frankly, (IMHO) the issue is likely to be that Quicktime and your phone don't implement the JPEG standard properly.

Despite being a quasi-public standard JPEG implementations are very variable in their quality, in my experience even applications that really should know better (e.g. Adobe Photoshop) incorrectly implement chunks of the standard.

MS Paint will use the GDI+ (Windows native) output compressor, which is different to the one Smugmug uses, which is a different standard application (unless they've changed it since the last time we talked).

Quicktime's JPEG processing engine has been known to have servere issues in older versions, mainly security problems, I would really consider updating your version to the newest release if you can. Otherwise what version number are you using? (It'll probably be in a help-about menu somewhere).

As you've found that your phone can do JPEG decompression on GDI+ images, it might be easier to just have a program open them and save them again. It's tedious, but if you have something like Photoshop you should be able to script it so it wouldn't take too long....

How many images do you need to transfer and how often?

Luke

djlin

luke_church wrote:

Frankly, (IMHO) the issue is likely to be that Quicktime and your phone don't implement the JPEG standard properly.

Thanks for such a quick response, Luke. That was my first post on this forum and I am already so impressed with the caliber of members here. Your diagnosis sounds spot on. I tried another phone (Sony Ericcson) and it did successfully render the SmugMug jpg. I am actually trying to automate this process so I wonder whether you have any recommendations for any Java APIs (I am programming in Java) that could do the conversion. . . although, I guess the issue would be whether such a Java API's output compresser works similarly to GDI+ such that it will be rendered on the phone? What would you imagine the rate of conversion would be for something like this? I am hoping it is relatively quick. I will continue to look into.

Thanks!

luke_church

djlin wrote:

I am actually trying to automate this process so I wonder whether you have any recommendations for any Java APIs (I am programming in Java) that could do the conversion. . .

Sure, I think it's part of the imaging framework that ships with Java... I would have thought it would be somewhere around:

http://java.sun.com/j2se/1.5.0/docs/api/javax/imageio/package-frame.html

Either that or I imagine there are some more optimised routines in the Java Media Framework, but JMF has a reputation of being a complete pain in the neck to install and use...

although, I guess the issue would be whether such a Java API's output compresser works similarly to GDI+ such that it will be rendered on the phone?

Java won't talk to GDI+, as it's not cross-platform, it will use it's own codec, you could just try it and see. It really shouldn't be many lines of code, to input an image, set the output compression parameters and write the image out again... I suspect the middle one will be the fiddly bit.

If you're using Windows, you could use C#, in which case the code is fairly simple, and it definately does use GDI+. In fact, if you're writing in C# then I practically already have the code written in a 101 other projects that I've used its JPEG compressor in...

What would you imagine the rate of conversion would be for something like this? I am hoping it is relatively quick.

It'll be very fast. These are tiny images you're dealing with. I'd be very disappointed if it took more than 1s to convert an image. Unfortunately with Java (and to a lesser extent, C#), you're going to have to pay a substantial startup cost as your machine boots the virtual execution environment. This cost will totally dominate the execution time of the JPEG conversion, unless you're converting a large batch of images at once.

Thanks!

No trouble :-)