evil-mad / robopaint

The software for your friendly painting robot kit!
126 stars 34 forks source link

Remove the word "image" from edit context #114

Closed oskay closed 8 years ago

oskay commented 10 years ago

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.

techninja commented 10 years ago

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

oskay commented 10 years ago

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 commented 10 years ago

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:

oskay commented 10 years ago

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

techninja commented 10 years ago

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.

oskay commented 10 years ago

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 commented 10 years ago

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.

RI0 commented 10 years ago

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

oskay commented 10 years ago

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.

oskay commented 10 years ago

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

techninja commented 8 years ago

This issue was moved to evil-mad/robopaint-mode-edit#1