6 ms·

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

71 points by davidbarker 11y ago

personjerry 11y ago
This is pretty cool. Are there any practical applications? It seems the CSS images are orders magnitudes larger.
- rawnlq 11y ago
  Embedding images in emails that disallow images but allow css?
  - mjrpes 11y ago
    The majority of common email clients do not support css box shadows (as of 2014): https://www.campaignmonitor.com/css/ https://www.campaignmonitor.com/css/
  - personjerry 11y ago
    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.
    - supercoder 11y ago
      Could just as easily use a table to create an image in an email
    - ishi 11y ago
      These guys already did something like that - https://www.emailonacid.com/mozify https://www.emailonacid.com/mozify
SimeVidas 11y ago
3.7 KB image → 466 KB of text
- vegardx 11y ago
  How much if you gzip the text?
  - AnkhMorporkian 11y ago
    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.
    - mistercow 11y ago
      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.
    - lucideer 11y ago
      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.
    - userbinator 11y ago
      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.
- Theodores 11y ago
  ...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.
recursive 11y ago
Data urls already solved this problem, and much better too.
- akst 11y ago
  I don't think this is trying to solve a problem, I think it's more one of those "because you can" things
neilellis 11y ago
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.
- vortico 11y ago
  Emphasis on the insane part.
- userbinator 11y ago
  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.
frozenport 11y ago
We should make a 90s version where each pixel is a <td>, I bet it will render faster than this!
grizzles 11y ago
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.
ned2 11y ago
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 http://www.nedned.net/?x=divify (Scroll to the bottom to skip the waffle and get to the demo)
- rorykoehler 11y ago
  that is awesome
xem 11y ago
Here's a tiny (less than 512b) app I've made with the same goal: http://xem.github.io/miniShadowArt/ http://xem.github.io/miniShadowArt/

71 points by davidbarker 11y ago

personjerry 11y ago

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

rawnlq 11y ago
Embedding images in emails that disallow images but allow css?
- mjrpes 11y ago
  The majority of common email clients do not support css box shadows (as of 2014): https://www.campaignmonitor.com/css/ https://www.campaignmonitor.com/css/
- personjerry 11y ago
  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.
  - supercoder 11y ago
    Could just as easily use a table to create an image in an email
  - ishi 11y ago
    These guys already did something like that - https://www.emailonacid.com/mozify https://www.emailonacid.com/mozify

SimeVidas 11y ago

3.7 KB image → 466 KB of text

vegardx 11y ago
How much if you gzip the text?
- AnkhMorporkian 11y ago
  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.
  - mistercow 11y ago
    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.
  - lucideer 11y ago
    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.
  - userbinator 11y ago
    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.
Theodores 11y ago
...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.

recursive 11y ago

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

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

neilellis 11y ago

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.

vortico 11y ago
Emphasis on the insane part.
userbinator 11y ago
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.

frozenport 11y ago

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

grizzles 11y ago

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.

ned2 11y ago

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 http://www.nedned.net/?x=divify (Scroll to the bottom to skip the waffle and get to the demo)

rorykoehler 11y ago
that is awesome

xem 11y ago

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