Also, I have tried the trace function a couple of times and it brings my computer (toshiba 3490ct 700 mhz/p3/256mb laptop) to its knees and I had to abort before the procedure finished. Three possible things:

1.) Add a progress bar to show where the process is at...

2.) Speedup the process

3.) simplify the complexity of the process somehow on an image. For example, if an image is too large, shrink the image.

Just some thoughts...

Jon

On Fri, 2004-09-17 at 10:16, bulia byak wrote:

On Thu, 16 Sep 2004 20:35:43 -0400 (EDT), Peter Selinger <selinger@...535...> wrote:

...

Did you look at the "mkbitmap" program, which comes with the potrace distribution? It is a pretty good pre-processor for potrace for certain types of images, like cartoons or photographs of handwriting. For some examples, see

It would be very nice to incorporate mkbitmap into the Inkscape potrace interface as well - not as something separate but integrated with the rest of the trace options. Especially nice would be a scale option, since scaling before tracing often gives good results. Highpass filter is nice too.

---

This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

Jon Phillips wrote:

Also, I have tried the trace function a couple of times and it brings my computer (toshiba 3490ct 700 mhz/p3/256mb laptop) to its knees and I had to abort before the procedure finished. Three possible things:

1.) Add a progress bar to show where the process is at...

That would not be too hard.

2.) Speedup the process

3.) simplify the complexity of the process somehow on an image. For example, if an image is too large, shrink the image.

I wonder if it's implemented correctly. Did you try the same image with the standalone potrace? (potrace.sf.net) If this still brings your computer to its knees, please send me the bitmap. It should not normally happen - in the past, this kind of behavior has typically exposed an implementation bug (i.e., an infinite loop of some kind) - or in one case, a compiler bug (some strange unsound loop optimization).

In my tests, potrace normally handles between 3 and 13 million pixels per second on reasonable images. On random noise, I just measured 0.17 million pixels/second (@1.7 GHz, for a 1000x1000 pixel image, produced by: ( echo P4 1000 1000 ; dd bs=1000 count=125 if=/dev/urandom)).

-- Peter

On Fri, 2004-09-17 at 02:15, Jon Phillips wrote:

I tried it with a 1024 by 768 72 dpi jpg image...nothing fancy...and it brought it to its knees.

It seems fairly slow to me as well -- perhaps there is a more efficient way to use potrace than we are currently doing?

-mental

On Tue, 2004-09-21 at 23:52, Peter Selinger wrote:

I tried with Jon's image and the standalone potrace, and it always finished in under 1 second. There must be something wrong with how it's integrated in inkscape.

Could it be that it's actually the "canny" edge detection which is slow?

It seems to be, yes. I haven't had a chance to try with Jon's image though.

-mental

On Tue, 2004-09-21 at 23:52, Peter Selinger wrote:

One thing is that I use -O3, whereas you probably use -O2. One should manually inline a lot of functions in this case, to make it faster. This makes a difference of 20-30 percent.

For the sake of the less experienced developers here, I feel compelled to point out that there is an important tradeoff involved:

Manual inlining and similar micro-optimizations generally can't yield order-of-magnitude improvements in performance like algorithmic optimizations can.

Worse, most micro-optimizations have the tendency to obscure patterns in the code which are helpful for making larger optimization and improving the algorithms.

They also really screw up maintainability, and occasionally they can make performance even worse.

For example, an issue raised on the Linux kernel mailing list recently was that the kernel actually performed significantly better when the tiny spinlock functions used throughout the kernel were _not_ inlined. Surprising, but true. The most recent versions of 2.6 have non-inlined spinlocks now.

So, IMO manual inlining and related transformations are only something to do if:

* you've completely debugged the code

* you don't plan on making any more major changes to it

* you've exhausted all the options for better algorithms

* you've measured the performance benefit

* the performance improvement is significant (whether a 20% increase is significant may depend on whether your typical runtime is a few seconds or a few weeks)

* you're a seasoned expert like Peter or myself ^_-

But, you get the idea.

But this cannot be the only reason it is so slow. I compiled the standalone potrace with g++ and -O0 just for comparison, and it still finishes Jon's image in 1.5 seconds.

So, as demonstrated here, even poor compiler options have relatively little impact on ultimate performance, compared to choosing good algorithms -- potrace is very fast even in the presence of pessimal compiler options.

-mental

I have just been playing with autotrace in the 24 Sep win32 build. I tried a couple of fairly small .jpgs and had no success at all. The machine just went away to think about things until I stopped it after several minutes in each case. This happened with default image brightness, canny edge and colour quant settings.

The Stop button (Abort?) does not! The machine hangs everything including the Stop button.

vellum