Remove the word "image" from edit context

[techninja]

From @oskay on November 17, 2013 21:42

Usually, "image" refers to a bitmap. We should consistently use terms that do not imply bitmap, like "document," "drawing," or "painting"

"Open an example image" -> "open an example drawing" "import image" -> ??? Seems to actually import images, but since we can't print them, this may not be a good thing.

Copied from original issue: evil-mad/robopaint#114

[techninja]

The idea behind continuing to allow raster image "placing" was for users who intend to draw paths over the top of images. The most realistic direction we should probably take is to warn users at some point that "Any 'flat' images placed on the drawing will be ignored.", any images can also be part of the cleaning process from method-draw to the print interface.

ALSO... There's actually quite a few raster -> vector-ish conversions for plotters, it might not be a bad idea to add a mode for RoboPaint to handle these various methods directly. And yes I know inkscape and plugins/Stipplegen currently has the Monopoly on these, I figure if someone either has an SVG or a raster image they should be able to get at least entry level ability to "print" it.

EDIT: I agree it should say SVG/Drawing, if that wasn't clear

[techninja]

From @oskay on November 18, 2013 20:7

One approach might be to say "import image for tracing"

If you can come up with any good ways to automatically convert images, I'm all ears.

[techninja]

FWIW, it seems some unlucky guy has been trying to port the "potrace" vectorizer (found in inkscape) to JS! https://github.com/dunvi/potrace-js

His commit messages scare me a bit of course. :see_no_evil:

[techninja]

From @oskay on November 18, 2013 20:22

This may not be the best approach; Potrace is good, but it does not exactly produce "paint-ready" output.

[techninja]

No, it doesn't, well, not from Inkscape, I have yet to see how bad the output is from the JS port. I would probably end up screwing with the output quite a bit to ensure the path output if conformant, not to mention ensure the input image and settings make sense for either pen or color images. Probably need to reel in the scope of the various tracer/haltone/dithering into what makes sense. I doubt stippling will ever make a lot of sense for watercolor, but it's great for pen renderings.

I've physically seen pen specific color trace renderings for raster images at Maker Faire's and such, but googling for these oddball implementations has mostly come up trumps. :tired_face: Grumble.

[techninja]

From @oskay on November 18, 2013 20:35

One possible approach would be to first use an image filter (e.g., the type found in gimp or photoshop) to remix the photo into one that looks like it's been painted-- made of wide, long brushstrokes. Then, trace that image.

[techninja]

Yep, effects like that or a simplified palette adjustment technique where faces or shading is left mostly intact

Admittedly, the standard palette is pretty harsh for portraits, not to mention there's currently no calculations for paint mixing on paper. That was a common question, filled with lots of misunderstanding about how that would actually work, and/or how that's usually done with watercolors.

[techninja]

From @RI0 on December 7, 2013 10:25

Maybe the imported tracing image could have a lock option so it is not accidentally selected while tracing.

[techninja]

From @oskay on December 7, 2013 18:14

One other thing that we might consider is slight rephrasing: "Place" image-- it puts it there, but does not imply that it has been "imported" for painting.

[techninja]

From @oskay on December 7, 2013 18:17

On the idea of using an image filter (i.e., non-photorealistic rendering), I found this javascript example that can create brushstrokes:

http://cs.brown.edu/research/pubs/theses/masters/2012/price.pdf https://github.com/mprice1/NPR.js/tree/master