Img2css: convert any image into a CSS “image” using only box shadows | Hacker News Reader

Img2css: convert any image into a CSS “image” using only box shadows

javier.xyz

71 pointsdavidbarker23 comments

Not all things need to be useful, sometimes they're there just to stimulate thoughts and ideas. I like this, it's insane but creative.

Emphasis on the insane part.

I think this is useful for stress-testing purposes; most browsers will (hopefully) never see CSS like this in regular use, but pushing things to the limit is a good strategy for reliability in more normal use-cases.

Fantastic. I did a thing like this a while back but using individual divs for the pixels. The idea was to pixelate the image, but then I realized you could set the pixel size to 1 and get a perfect rendering of the image back. I'm happy to report that it's even slower than Img2css' method. Another perk is that you can apply styles to the pixel divs yielding interesting effects.

http://www.nedned.net/?x=divify

(Scroll to the bottom to skip the waffle and get to the demo)

that is awesome

3.7 KB image → 466 KB of text

...and 296% CPU for one Chrome tab whilst it is doing it, with negligible 'wait'.

Right now I am seeing how that works out for a sizeable image, I don't think I have seen such a deliberately CPU intensive thing run before in a browser. I have no idea if it is doing it or not, so a 'progress bar' could be helpful here.

How much if you gzip the text?

Not his example, but here's a file I ran it on.

Starting image size: 604521 bytes

Output CSS: 7077663 bytes

Gzipped: 1572759 bytes

Ratio of original to gzipped output: 2.60x

---

So really, not that bad. Not great, obviously, but not bad.

I wouldn't say "not bad" because compression does nothing but turn bandwidth and storage costs into energy costs on the client. The client still has to decompress, parse, and render all that CSS using a much more elaborated path than the one it uses for images.

It's still a fun hack though - reminds me of a similar technique I've seen before using many rectangular divs of a certain size, colour, and position.

He's also outputting his shadow colours in decimal rgb - hex would be a good deal smaller. I don't think small size was a goal.

What was the input type? PNG? If so, that means that a lot of the size gain is due to the fact that PNG can compress based on similarities between rows, while GZIP on the CSS is only compressing in the horizontal direction.

Data urls already solved this problem, and much better too.

I don't think this is trying to solve a problem, I think it's more one of those "because you can" things

I'm not recommending it, but this would be a passable copy protection scheme for the web if you combined it with a css animation where you were only showing some (half?) of the pixels at once and using the eye's natural ability to interpolate images from a rapid succession of images.

Because it's written in js, you could download the jpg like a normal file and do it all client side, so there wouldn't be any penalty from the conversion. But still don't do it. A business probably has bigger problems if it needs to use copy protection.

Here's a tiny (less than 512b) app I've made with the same goal: http://xem.github.io/miniShadowArt/

This is pretty cool. Are there any practical applications? It seems the CSS images are orders magnitudes larger.

Embedding images in emails that disallow images but allow css?

The majority of common email clients do not support css box shadows (as of 2014):

https://www.campaignmonitor.com/css/

I question the value of adding MBs to your email to forcibly embed an image.

Actually this could become a liability if spammers catch on.

These guys already did something like that - https://www.emailonacid.com/mozify

Could just as easily use a table to create an image in an email

We should make a 90s version where each pixel is a <td>, I bet it will render faster than this!

Reply on news.ycombinator.com