search

yarn-co / kepler

Server-side trixel rendering
1 stars 0 forks source link

Wanted: png output with transparency #14

Open semateos opened 8 years ago

semateos commented 8 years ago

Transparent backgrounds so we can use png images in the feed. Bonus: export with proper alpha color data from using the proposed alpha slider in trixel create. My understanding was that this required a different version of some software on the server. Could go into the new yarn-v2 stack @sethwklein is building. May need an assist from @devinivy regarding how that interacts with the CDN.

sethwklein commented 8 years ago

I'm guessing a different version of GraphicsMagick given that it's installed on the v1 Node.js App Server layer. Does anyone have a test case handy?

devinivy commented 8 years ago

If I remember correctly it's a lib that GM calls out to that needs to be swapped. Currently the machine can render PNGs with opacity, but the anti-aliasing looks like crap.

tripdragon commented 8 years ago

By crap anti-aliasing you most likely means its running 8bit transparency. Which means its not a smooth gradient. changing that to 24bit will fix that but the file size will go up if the tool is unoptimized. Keep in mind everything you build will need to be 2x or even 3x. You could build a spritesheet to save on requests and background-image it and shrink that way but that gets Trrrrrricky on spritesheets.

The current noted 30 layer svg trixels file sizes are 1.2megs a piece. There is no further way to compress these without some magic google api thing. The SVGs have two layers one a duplicate of the other and then a blur filter xml element. You could remove that duplicate and add it as it loads on the page. The performance on the page in my link to 100 svgs and pngs did not show much of a lag http://fancyhologramufotacos.xyz/trixelfeed/pngtests.html http://fancyhologramufotacos.xyz/trixelfeed/svgtests.html

The svgs would disappear for a sec as you scrolled back but lag on scrolling was not really to be seen.

Related to https://github.com/yarn-co/kepler/issues/15

In OS X I can instal Inkscape https://inkscape.org/en/download/ and it has a command line application at /Applications/Inkscape.app/Contents/Resources/bin/inkscape which if I use absolute paths I can run simple png commands on

/Applications/Inkscape.app/Contents/Resources/bin/inkscape /Users/tacos/test/5056.svg -z -e /Users/tacos/test/5056.png -w800

and then I can do a cheap simple batch with

FILES=("/Users/tacos/test/b/"*.svg)
PNGS="/Users/tacos/test/b/pngs/"
for f in "${FILES[@]}"
do
  /Applications/Inkscape.app/Contents/Resources/bin/inkscape "${f}" -z -e "${f%svg}png" -w800
done

the PNG output defaults is excellent from Inkscape even has transparency 24bit, in OS X it requires X11 but if you do the command exactly perfect it won't require X11 to start otherwise it will start the app. In Linux I assume it's already there so can be done without anything.

Other alternatives Node.js SVGExport produced unoptimized images. ImageMagik was not advised as its very old and svg was an after thought to its raster system.

sethwklein commented 8 years ago

I'm taking this for the moment since infrastructure changes may resolve it.

sethwklein commented 8 years ago

So I tested trixel SVG to PNG conversion using GraphicsMagick. The best command I found was gm convert -background transparent 1980.svg 1980.png but its output has artifacts including a line through the middle of one of the trixels I tried.

This is in contrast to the output from the Inkscape command from @tripdragon above, which produces beautiful output. Using Inkscape requires a bit of development time to convert from using the gm NPM package to something using Inkscape.

Can you come up with a better gm command?

Or should we spend the resources to convert to Inkscape?

I took a stab at the conversion with the aid of https://www.npmjs.com/package/inkscape , but ran out of time to figure out what I was doing when I got snarled in errors about streams. In Node, not only must they not be crossed, they also have version conflicts!

semateos commented 8 years ago

@tripdragon @devinivy any thoughts on the above? Sounds like we probably need to switch kepler to Inkscape for png output.

devinivy commented 8 years ago

I know that GM can output silky PNGs. GM is going to call out to other libs on the machine in order to make that PNG, and the silkiness relies largely on those libs. On EC2 they weren't the ones we wanted, and it was going to be hard to swap em out.

Is that at least consistent with the further research that's been done on the problem? If that's already been taken into account, then maybe it is time to switch to inkscape.

tripdragon commented 8 years ago

the inkscape I was testing against is just the compiled bin file, is that not enough? Can we not just copy it to the dir? Or does it have to be in a package management thing and C compiled?

sethwklein commented 8 years ago

@devinivy, you keep saying GraphicsMagick can do it and the external libraries are the key, but you never say which libraries! We're not on EC2 (Amazon Linux, really) anymore so its not hard to swap them out anymore. But we can't swap them out, no matter how easy it is, if we don't know what needs swapping or have any clue how to figure it out!

Do you have any further ideas for getting specific, actionable information here?

devinivy commented 8 years ago

I don't remember which ones, but I once knew about a year ago from medium-to-extensive googling of the issue at hand.

sethwklein commented 8 years ago

@devinivy it wasn't (lib)rsvg, was it?

devinivy commented 8 years ago

Definitely ringing a bell. Is that maybe the good one?

sethwklein commented 8 years ago

I suspect it was. I suspect ImageMagick (not the GraphicsMagick that I believe we're using) does or used to fall back to rsvg and Inkscape in some order. But when I grep the source of the most recent version (1.3.24) of GraphicsMagick, I find no mentions of variations on rsvg or Inkscape. I think I'm giving up on that and going to convert to Inkscape. rsvg would also be a possibility, but I feel like we had less success with it when working on the stickersheets.