Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

On my iPhone, for the checkerboard resizing, the srgb-space resizing (b) is almost an exact match, while C appears much whiter.


I had the same problem on my laptop which, like many phones, has a high density display. When a website hasn't explicitly provided support for high DPI displays, the browser is forced to scale up the source image (typically by 200%). To see the expected effect, you just need to lower the browser zoom level a couple of times to get the image back down to its native size. You'll know you've got it right when the A block suddenly appears lighter and matches the C block rather than B block (which will now look too dark).


I zoomed the image in and out a bunch -- no change. When I zoomed in enough, I could see the checkerboarding in A, but the overall color stayed the same as B.


This technique may not work if you've got a weird DPI that's causing scaling to something like 150%. In that case you'd need to set your browser's zoom level to 66.666% which is probably not one of the levels it supports. My display scales by 200% so I just needed to zoom out to 50% which has worked on every browser I tried.

Another option is to save the image from the webpage to disk and then open that image in a basic image editor (making sure the editor is not zoomed in at all). I'm not sure how feasible this is if you're on a phone though.

What would have been ideal is if the author of the article had included srcset alternatives for these images to cater for some of the more common high DPI devices. Would then have just work automatically for most people and caused a lot less confusion.


Thanks for the suggestion, I'll look into the scrset thing!


Yep, for me too on a 4k HiDPI screen. The reason is that the browser scales the original image, using the naive incorrect algorithm. Amazing full-circle confirmation of the author's point, eh?


Which is why he recommends not viewing the examples on a phone. Too bright is less noticeable than too dark, so I guess you're lucky it's off in that direction.

It's also possible that the image file is a PNG with a gAMA chunk, which sometimes gets rendered incorrectly by browsers.


I get a similar behaviour on my Android phone. As I mentioned in the article, that example doesn't work on most phone LCD screens. Try it on a real desktop monitor!


> Try viewing it on a real desktop monitor!

You keep saying this, but many people don't have a real desktop monitor. Laptop sales exceed desktop sales and both are dwarfed even by tablets alone.

So whether it's technically the correct approach is irrelevant for a large proportion of potential end-users, for whom it will look broken.


Sorry, I can't magically fix all the mobile device screens of the world so they will start displaying images in a gamma-correct way... The fact is, the owners of such devices will never see gamma correct images on their screens, at least until the manufacturers fix this. It sucks but I can't help there.

Anyway, I think you have bigger problems than gamma with those devices anyway (glare, reflections etc.), so that's probably the least of your concerns.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: