search

fogleman / primitive

Reproducing images with geometric primitives.
https://primitive.lol/
MIT License
12.35k stars 608 forks source link

Background color, edge-treatment, transparency and generated SVG integration #14

Closed globalcitizen closed 7 years ago

globalcitizen commented 7 years ago

Hi Michael

I wanted to have a snooze on this before writing the issue as it was 4AM and my mind was far below even at its usually unimpressive level. Even now it's probably not the clearest, and could perhaps be better broken down in to a number of component issues by yourself.

In short I am quite happy indeed with the generated SVGs and have been able to get them loading in to my Lua/LÖVE-based game environment after writing my quick and hacky svg2love tool.

The issue I am facing now is that for anything but 'picture in a square' level of graphical integration, there is a need to obtain non-hard edges on the images, and/or some additional intelligence in primitive with respect to output and transparency.

Transparency: Currently it seems that primitive assumes that an image should be drawn to 100% opacity in all places, drawing a background rectangle in output SVGs to kick off the process. What I would really like is the option to not include this background rectangle or the assumption that it is based on. For example, if I could run with a switch like primitive -b 000000 to have primitive assume that the background was already present and black. In this case, the background rectangle would not be drawn in the resulting SVG but more importantly the other colors would have been chosen in such a manner as to create the desired output assuming a black background. Then if I were to paste on to a blackish background, the majority of the image would have solid opacity, and the image would integrate more closely with arbitrary environments without demanding a square border.

Edges: There are semi-frequently significant edge artifacts in the images. Thus far I have been dealing with these by cropping, but I wonder if there is an algorithmic enhancement or adjustment that you could make to avoid having, for example, long shapes occurring along the edge of an image bringing with them an additional 'gutter' to the output image.

globalcitizen commented 7 years ago

PS. Even better would be to auto-detect a background color with a presumably corner-based color-range. Though this would require more code, it would handle more elegantly the frequent case of slight background color variations on input bitmaps.

fogleman commented 7 years ago

For starters you could just remove the "background rectangle" from the SVG manually...

globalcitizen commented 7 years ago

Of course I have tried that but because the other elements are designed to produce a certain color based upon the assumption of a certain background color (~whitish), and I am interested in using a different color (~blackish), it corrupts the image.

fogleman commented 7 years ago

Did you try specifying the background color with the bg flag?

globalcitizen commented 7 years ago

I tried this one with -bg 000000 -n 250 -m 1. I still wound up with a 100% opaque SVG filling the entire square. What I was looking for was an image that did not have the black background areas covered (much).

aegir_13___fancy_rat_by_dianephotos-d2xpd1x

fogleman commented 7 years ago

Yes it's still opaque. But then if you remove the background rectangle, the remaining shapes are assuming a black background now.

There will always be some shapes in the background areas of the image to try to clean up the edges. So not really anything else to do here.

globalcitizen commented 7 years ago

OK sorry I missed that. Thanks for your help! Great software!