Sprint recompression of JPEG files

Update, 2014-10-25: This can be mitigated on the server side. When HTTP headers specify 'Cache-Control: no-transform', Sprint's proxy honors it and doesn't degrade the image before sending it to the phone. In apache, this can be achieved by enabling mod_headers and putting Header add Cache-Control no-transform in an appropriate location. I've done this for the server where my photos come from...

When showing my blog photos on my phone, I noticed that they looked terrible. Shown above is a detail of the original image (not entirely free of JPEG artifacts) and of the same area after it was recompressed by sprint. (zoomed 200%, nearest neighbor scaling)

It turns out that sprint recompresses jpegs and this is documented by sprint, but it's still terrible.

It also affects ting.com users, since they are a sprint reseller. (and I didn't find any ting documentation about this misfeature yet)

This happens both on the phone itself, and to devices tethered via the phone.

Most images aren't mangled quite as badly as this one, but their claim that there's "no user perceptible loss of quality" is bunk.

Here are the jpeg files zipped up, in case you are interested in inspecting them for the jpeg compression details: original-and-recompressed.zip

I know that serving web pages over https is the new hotness; here's another reason to do it, since sprint couldn't rewrite the contents of content served over https.

Sprint recompression of JPEG files

Original image, converted to png

Sprint-recompressed image, converted to png