Byline image brocken here...

[Pearson82]

http://www.theguardian.com/artanddesign/2014/jun/09/let-them-eat-football-rio-de-janeiro-sao-paulo-anti-world-cup-graffiti

[paperboyo]

Hi, working well for me in all browsers, in R2 everything is in it's place. Maybe a temporary hiccup?

Regards Mateusz

[Smylers]

It was also broken for me at lunchtime on Tuesday (on this, and a handful of other pages with circular byline photos), but is fine now — there are now images being served from the URLs used by the byline pics.

However, the images being served seem unnecessarily large: the one in the above article is http://i.guim.co.uk/w-140/h--/q-95/sys-images/Guardian/Pix/pictures/2014/3/13/1394733741000/JonathanJones.png

Note that despite the ‘w-140’ in the URL, that image is 720 px wide, and being scaled down by the browser. As such, it's 125 kb.

Compare this to the equivalent pic on the current site, which is 140 px wide, and only 7 kb: http://static.guim.co.uk/sys-images/Guardian/Pix/pictures/2014/4/17/1397749334203/JonathanJones.jpg

So the circular byline pics now look right, but seem rather a waste of bytes to be downloading such large mugshots only to shrink them down so much on display.

It's the case on all the circular byline pics I could find — a few more examples: http://www.theguardian.com/sport/2012/nov/06/maurice-holmes-english-murali-spin http://www.theguardian.com/lifeandstyle/2014/jun/12/taste-test-low-calorie-low-alcohol-wine http://www.theguardian.com/lifeandstyle/2014/jun/07/tim-dowling-away-without-teenagers

[paperboyo]

Hi, Smylers!

The big bylines are indeed 720x600, but the image area is never larger 480x600. And thanks to the great work by https://github.com/pornel, this particular one is 125KB instead of 573KB. They were suppose to work well at a variety of sizes and screen densities. Please remember that the same image is sized differently depending on the context - e.g. it is bigger (288x240) when used here: http://www.theguardian.com/artanddesign/jonathanjonesblog/2014/may/26/new-york-metropolitan-museum-art-met-renovations

That said, it looks like it may indeed be a waste of bytes sometimes. I do not have a 'retina' screen to check, but on my ~100DPI display, I have it scaled to 282x235 as per the screenshot: I do not know anything about the code (px vs. em?), but it looks like, in the screenshot above, my zoomed in image is an upsized 185x154, instead of a downsized 720x600 (it seems a bit less sharp, but I can't tell for sure, really, just by looking at it - but would that be a case, you would certainly be able to tell on those funky 542DPI displays that are soo common :).

I do not know what a cache is, but my layman's view is that the cache system for images should work something like this: There is a constantly updated histogram of the frequency of requests for an image at different sizes depending on the entire audience's devices displays, their screen orientations and zoom levels. Then the system caches every image in variety of smaller sizes based on where the spikes (the most common requests) are on such a histogram and when the distribution of requests changes, the image versions are updated too. Then the website serves the image in the closest bigger size to the displayed size taking into account screen density (if not directly reported), screen orientation and zoom level and silently serve the bigger version should the environment change. That would allow for zooming into image details up to the original image size. There should be a mechanism to serve an image in a smaller size than displayed if the user's connection is weak. But as with layman's ideas, that would most probably cause the website to follow the pacman's law where if you are to the far left, you inevitably end up on the far right - and this extreme following of 'responsive' principles would make it totally unresponsive in the traditional sense :D

Regards Mateusz

[phamann]

@paperboyo You are indeed correct that the new byline images are far too large in physical dimensions and bytes for our purposes. The issue is, that our image resizing server/service does not currently support transparent pngs (we can do it but produces terrible artefacts when downsizing). We are in the process of moving to a new service provider over the next couple of months which should eliminate these problems.

Though in the mean time we could batch run all of the images through imageoptim or the likes, and batch up load to the CAPI again. Is this doable?

[mstorijo]

How much work would it be to do this batch run?

[paperboyo]

Hi, They are already optimized to the max and are less than 30% weight-wise compared to the initial spec/Photoshop output. The only way would be to make them smaller pixel-wise.

The work is not the problem, I can size them down to new spec and optimize them again with ease. But they are used in Apps as well. They are used in different sizes on NGW. That template file was agreed between teams as future-proof. I think it would be wise to keep them as is in the API. That does not mean that we should not think of a way to use smaller versions of them by using some other mechanism while waiting for the proper image resizing server/service that could dynamically shrink them and re-optimize on demand (it would have to use pngquant, otherwise they will grow by more than 70%!).

But here, I can not help, I'm afraid :(

Regards Mateusz

[cantlin]

fixed