thegrandpoobah / voronoi Goto Github PK

The program crashes when using the following invocation:

voronoi -t 0.05 -s 64000 corpus\squirrel.png squirrel.svg

The computation of cell centroids uses a fixed step size regardless of the size of the centroid. If the stepping size is dynamically computed, it may a) speed up the computation, and b) make the results more refined.

Stippler throws std::exception errors. On Visual C++, std::exception takes a string argument in its constructor, but this is non-standard and was modified to work on Linux by removing the usage of e.what(). What should be done from the get go is to use std::runtime_error which has the string argument in the constructor as part of the standard.

Try to resolve the warnings from GCC

g++ -Wall -fpermissive -fopenmp -O2 -I/opt/local/include -I/opt/local/include/boost -I./picopng -I./stippler -I./voronoi -c stippler/stippler_api.cpp -o stippler/stippler_api.o
g++ -Wall -fpermissive -fopenmp -O2 -I/opt/local/include -I/opt/local/include/boost -I./picopng -I./stippler -I./voronoi -c stippler/stippler.cpp -o stippler/stippler.o
In file included from stippler/stippler.cpp:31:
stippler/VoronoiDiagramGenerator.h:185: warning: extra qualification ‘VoronoiDiagramGenerator::’ on member ‘ELgethash’
stippler/VoronoiDiagramGenerator.h:207: warning: extra qualification ‘VoronoiDiagramGenerator::’ on member ‘openpl’
stippler/VoronoiDiagramGenerator.h:208: warning: extra qualification ‘VoronoiDiagramGenerator::’ on member ‘line’
stippler/VoronoiDiagramGenerator.h:209: warning: extra qualification ‘VoronoiDiagramGenerator::’ on member ‘circle’
stippler/VoronoiDiagramGenerator.h:210: warning: extra qualification ‘VoronoiDiagramGenerator::’ on member ‘range’
stippler/stippler_impl.h: In constructor ‘Stippler::Stippler(const StipplingParameters&)’:
stippler/stippler_impl.h:85: warning: ‘Stippler::parameters’ will be initialized after
stippler/stippler_impl.h:81: warning:   ‘float Stippler::displacement’
stippler/stippler.cpp:33: warning:   when initialized here
stippler/stippler_impl.h:81: warning: ‘Stippler::displacement’ will be initialized after
stippler/stippler_impl.h:79: warning:   ‘float* Stippler::vertsX’
stippler/stippler.cpp:33: warning:   when initialized here
g++ -Wall -fpermissive -fopenmp -O2 -I/opt/local/include -I/opt/local/include/boost -I./picopng -I./stippler -I./voronoi -c stippler/utility.cpp -o stippler/utility.o
g++ -Wall -fpermissive -fopenmp -O2 -I/opt/local/include -I/opt/local/include/boost -I./picopng -I./stippler -I./voronoi -c stippler/VoronoiDiagramGenerator.cpp -o stippler/VoronoiDiagramGenerator.o
In file included from stippler/VoronoiDiagramGenerator.cpp:30:
stippler/VoronoiDiagramGenerator.h:185: warning: extra qualification ‘VoronoiDiagramGenerator::’ on member ‘ELgethash’
stippler/VoronoiDiagramGenerator.h:207: warning: extra qualification ‘VoronoiDiagramGenerator::’ on member ‘openpl’
stippler/VoronoiDiagramGenerator.h:208: warning: extra qualification ‘VoronoiDiagramGenerator::’ on member ‘line’
stippler/VoronoiDiagramGenerator.h:209: warning: extra qualification ‘VoronoiDiagramGenerator::’ on member ‘circle’
stippler/VoronoiDiagramGenerator.h:210: warning: extra qualification ‘VoronoiDiagramGenerator::’ on member ‘range’
stippler/VoronoiDiagramGenerator.cpp: In member function ‘void VoronoiDiagramGenerator::clip_line(VoronoiDiagramGenerator::Edge*)’:
stippler/VoronoiDiagramGenerator.cpp:752: warning: unused variable ‘temp’
g++ -Wall -fpermissive -fopenmp -O2 -I/opt/local/include -I/opt/local/include/boost -I./picopng -I./stippler -I./voronoi -c voronoi/parse_arguments.cpp -o voronoi/parse_arguments.o
g++ -Wall -fpermissive -fopenmp -O2 -I/opt/local/include -I/opt/local/include/boost -I./picopng -I./stippler -I./voronoi -c voronoi/voronoi.cpp -o voronoi/voronoi.o
g++ -fopenmp -O2 -L/opt/local/lib/ -o voronoi_stippler picopng/picopng.o stippler/bitmap.o stippler/stippler_api.o stippler/stippler.o stippler/utility.o stippler/VoronoiDiagramGenerator.o voronoi/parse_arguments.o voronoi/voronoi.o -lboost_program_options

First of all, great project. Pretty great speeds and beautiful output. I work on a pen plotter project called the WaterColorBot and have been looking for a fast stipple with SVG output for pen plotting to integrate into RoboPaint, and this is great.

The old standard has been StippleGen, a great program unfortunately limited by its implementation in both number of stipples and general performance.

One of a few things missing before I can attempt to use the output of this app is a "Traveling Salesman Problem" circle/path ordering of the stipples. Attempting to draw the current output with the given path order shows the paths to be in basically random order, requiring huge pen moves between each circle, resulting in a var more inefficient toolpath than one where the TSP ordering has been done.

Might it be possible to add path ordering like this? I've considered adding some kind of top->bottom left->right naive ordering as an after-process, but it would be more efficient to make it part of the creation step. Thanks!

When logging is enabled, the program outputs the amount of time each iteration of the algoritm will take. In a discussion for issue #13, it becomes apparent that a "total time" metric would also be useful.

Add necessary code and build tools to make sure the voronoi tool compiles on Mac.

The CPU rendering path uses OpenGL to create the individual Voronoi tiles. OpenGL is used primary as a texture mapper and clipping mechanism. On faster machines this works perfectly fine, but on slower machines (read integrated Intel graphics), this serves as a bottleneck into the whole rendering process. Whilst it is possible to make better usage of the graphics hardware so that even slower graphics processors are better utilized, it is more complicated than implementing the texture mapping (bilinear filtering) and clipping in software.

Add necessary code and build tools to allow the voronoi tool to compile and run on Linux.

The CPU renderer is single threaded even though the work is embarrassingly parallel. The rendering code path should be optimized to use all available computation cores on the system.

Allow the usage of predefined radii in the output image by providing a new parameter to the tool. This will in effect turn off tone preservation.

When the threshold value gets small enough, the progress percentage can start going backwards. This implies that there is a subtle bug somewhere in the program, because the progress should always be a monotonically increasing sequence.

The GPU renderer is finicky and only works with certain processors. The the resources do not exist to test all the variants available out there, the GPU renderer should just be dropped altogether. In the future, an OpenCL based code path can be created to regain the ability to use the beefy GPU hardware for assistance.

No bounds checking is being performed for any of the parameters right now. Add bounds checking and choose sensible actions for out of bounds parameters (wrap, clamp, exception, whatever).

Introduce support for creating coloured stipples using the imput image as a colour map.

The Stippler class should be a library with the current console application being a front-end for the library.

remove VoronoiDiagramGenerator:: in VoronoiDiagramGenerator.h from the methods already in the class.

Also, this is a bit sad:

~/build/voronoi: make
/usr/local/bin/g++-4.8  -fopenmp -O2 -L/usr/local/lib/ -o voronoi_stippler picopng/picopng.o     stippler/bitmap.o stippler/stippler_api.o stippler/stippler.o stippler/VoronoiDiagramGenerator.o    voronoi/parse_arguments.o voronoi/voronoi.o -lboost_program_options
~/build/voronoi: ./voronoi_stippler -s 16000 -I corpus/klaymen.png -O test.svg
voronoi_stippler(77937) malloc: *** error for object 0x10365c570: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Abort trap: 6

Hello, I'm not able to make it on yosemite. Do you know how to build it? I tried with gcc-4.2 but somehow i think it is missing xcode 6

make
g++ -fopenmp -O2 -L/Users/sergio/GitHub/voronoi/boost_1_56_0/boost/lib -o voronoi_stippler picopng/picopng.o stippler/bitmap.o stippler/stippler_api.o stippler/stippler.o stippler/VoronoiDiagramGenerator.o voronoi/parse_arguments.o voronoi/voronoi.o -lboost_program_options
ld: library not found for -lgomp

Not a huge perf gain, but when you have to work with hundreds of thousands of points like some users do, it should provide a nice little gain.

Once #10 is completed, a GUI front-end for the Stippler class can be created (with the possibility of Integrating said front-end Paint.NET and other graphics programs.

From http://www.gimpchat.com/viewtopic.php?f=15&t=3872&p=47917#p47917:

Running voronoi with the following parameterization crashes frequently according to the post:

voronoi -t .3 -s 500 -n -z 1 -I %1 -O %1.svg

The number of stipples does not seem to affect it much though.

Enable Profile Guided Optimization on a corpus of inputs to see if it increases the speed of the application any.

Should result in a more robust cross-platform build system.

• CMake: http://www.cmake.org/
• A (potentially) suitable CMake template to get started: http://code.google.com/p/cpp-project-template/source/browse/trunk/CMakeLists.txt

Related to #5, #6

If I understand correctly, the implementation of the individual tile computation can be rewritten in OpenCL to make use of all forms of computation cores (CPU, GPU, APU, etc) on the system. Once this is done, the OpenCL pipeline will automatically create optimized code for all applicable platforms.

This needs further research to see if this all correct.