This is why there are so many problems with images on WordPress.com

  • Unknown's avatar
    enilamalenj · Member ·

    Many people have been experiencing problems with their images recently on WordPress.com. Suddenly, the quality of previously-uploaded images have changed. Multi-frame images no longer work correctly. Images lose their transparency.

    How can we deal with this problem, and why is it happening in the first place?

    The answer to the first question is simple. Normally, when one adds an image into a post, the following HTML is inserted automatically:

    <img src="http://example.wordpress.com/files/year/month/example_image.jpg" alt="alt_text" title="title_text" width="XXX" height="YYY" />

    Upon publishing the post, if one were to examine the source code of the page, they’ll see that the HTML is converted to the following:

    <img src="http://example.files.wordpress.com/year/month/example_image.jpg?w=XXX&h=YYY" alt="alt_text" title="title_text" height="YYY" width="XXX">

    And if one were to compare the published image to the original on their hard drive, they’ll notice that the two images are actually different.

    The problem appears to be a result of the ?w=XXX&h=YYY bit that is automatically added (beyond the user’s control). This line can be removed if one deletes the width=”XXX” height=”YYY” attributes from their original code, as such:

    <img src="http://example.wordpress.com/files/year/month/example_image.jpg" alt="alt_text" title="title_text" />

    After publishing the post, the HTML is processed and, upon examining the source code of the published post, one sees the following:

    <img src="http://example.files.wordpress.com/year/month/example_image.jpg" alt="alt_text" title="title_text">

    Now, the published image and the original image are identical.

    While this solution addresses the problem, there are still two big issues to deal with.

    First, a blogger with hundreds of images cannot hope to go through each of his or her posts and remove the width=”XXX” height=”YYY” from every single image. Since those attributes were automatically inserted by WordPress.com when an image is added to a post, unless the blogger deliberately removed those attributes in the first place, all of their images will have them. This means that all of their images will also have the ?w=XXX&h=YYY line and as a result, all of the images will be broken.

    Second, the underlying problem of why this is happening in the first place is still not addressed.

    The answer to the second question involves examining the images in greater detail. To do this, I will look at the Exif data of various images. What the actual images are doesn’t really matter — it’s the underlying data that’s key.

    The following are the results of a few images that I looked at. Part (a) features data from the original image, while part (b) features data from the images that had the ?w=XXX&h=YYY line added to their code. Bolded data in part (b) highlight the differences against those in part (a).

    Example 1(a): PNG

    8,700 bytes (0.008 megabytes)
    Image compression: 92%
    Bit Depth: 8
    Color Type: RGB
    Compression: Deflate/Inflate
    Filter: Adaptive
    Image Size: 300 × 100
    Interlace: Noninterlaced
    MIME Type: image/png

    Example 1(b): PNG

    7,512 bytes (0.007 megabytes)
    Image compression: 93%
    Bit Depth: 8
    Color Type: RGB with Alpha
    Compression: Deflate/Inflate
    Filter: Adaptive
    Image Size: 300 × 100
    Interlace: Noninterlaced
    MIME Type: image/png

    Example 2(a): PNG

    162,144 bytes (0.15 megabytes)
    Image compression: 44%
    Bit Depth: 8
    Blue X: 0.15
    Blue Y: 0.05999
    Color Type: RGB
    Compression: Deflate/Inflate
    Filter:Adaptive
    Green X: 0.3
    Green Y: 0.6
    Image Size: 470 × 221
    Interlace: Noninterlaced
    Pixel Units: Meters
    Pixels Per Unit X: 2,835
    Pixels Per Unit Y: 2,835
    Red X: 0.63999
    Red Y: 0.33001
    White Point X: 0.31269
    White Point Y: 0.32899
    ICC_Profile
    Blue Matrix Column: 0.14307 0.06061 0.7141
    Blue Tone Reproduction Curve: (2,060 bytes binary data)
    CMM Flags: Not Embedded, Independent
    Color Space Data: RGB
    [remaining ICC Profile removed to save space]
    MIME Type: image/png

    Example 2(b): PNG

    183,162 bytes (0.17 megabytes)
    Image compression: 37%
    Bit Depth: 8
    Color Type: RGB with Alpha
    Compression: Deflate/Inflate
    Filter: Adaptive
    Image Size: 470 × 221
    Interlace: Noninterlaced
    [Additional Exif and ICC profile data completely stripped out]
    MIME Type: image/png

    Example 3(a): JPEG

    57,421 bytes (0.055 megabytes)
    Image compression: 89%
    JFIF Version: 1.01
    Resolution: 59 pixels/cm
    Bits Per Sample: 8
    Color Components: 3
    Encoding Process: Baseline DCT, Huffman coding
    Image Size: 521 × 449
    MIME Type: image/jpeg
    Y Cb Cr Sub Sampling: YCbCr4:4:4 (1 1)

    Example 3(b): JPEG

    79,551 bytes (0.075 megabytes)
    Image compression: 82%
    JFIF Version: 1.01
    Resolution: 1 pixels/None
    Bits Per Sample: 8
    Color Components: 3
    Encoding Process: Progressive DCT, Huffman coding
    Image Size: 521 × 449
    MIME Type: image/jpeg
    Y Cb Cr Sub Sampling: YCbCr4:2:0 (2 2)

    Example 4(a): GIF

    1,808 bytes (0.002 megabytes)
    Image compression: -26%
    Animation: yes
    Frames: 9
    Comment: GIF file was created using the trial version of Studio XYZ.
    GIF Version: 89a
    Image Size: 50 × 10
    MIME Type: image/gif

    Example 4(b): GIF

    194 bytes (0.000 megabytes)
    Image compression: 87%
    Animation: no
    Frames: 1
    [Comment stripped out]
    GIF Version: 87a
    Image Size: 50 × 10
    MIME Type: image/gif

    So there you have it. Somehow, images with the ?w=XXX&h=YYY line present in the code are being post-processed by WordPress.com with varying results. Some images increase in file size. Some decrease in size. Image metadata is getting stripped out or scrambled. Image quality is altered, with changes ranging from unnoticeable to drastic.

    Unfortunately, I was not able to pinpoint what types of changes specifically occur, since the differences run the gamut. Hopefully, the developers will have better luck than I did.

    Though I must ask: I am aware that images that are not posted at their actual resolution (i.e. images that are posted at a shrinked or expanded resolution) are generated on the fly by WordPress.com through whatever post-processing methods used. However, why bother to post-process an image if it is being posted at its actual resolution? That’s what’s happening in all of these examples. If the information contained in the ?w=XXX&h=YYY and width=”XXX” height=”YYY” lines represent the actual resolution of the image, no post-processing should be needed.

    Questions and comments are welcome, of course.

  • Unknown's avatar
    enilamalenj · Member ·

    Hmm, it looks like the forum converted the escape code for the ampersand into an actual ampersand.

    The line that’s being added by WordPress.com is actually ?w=XXX & a m p ; h=YYY. Ignore the extra spaces.

  • The topic ‘This is why there are so many problems with images on WordPress.com’ is closed to new replies.