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

Peter Selinger wrote:

Hi guys, I heard from Bob today that he had integrated my "potrace" into inkscape.

This is cool. Thanks for joining the list, and welcome.

That is really great! I checked out the inkscape-devel archives and I noticed that Bob was tinkering with brightness settings to prepare an image for black-and-white tracing.

Yes, that was the first image conversion that I enabled, merely using a cutoff threshold for direct color->b&w translation. I added the 'canny' edge detection later, to find traceable information in another way. It seems obvious that there is no single best method for doing this, and that it depends on the given source image and the desired result.

Maybe simple quantization to a small number of colors, then converting to black and white, will produce a nice set of contour lines for tracing.

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

http://potrace.sourceforge.net/mkbitmap.html

It does not do too great for Bob's venus example, I have to say. The problem (which is shared by the "canny" edge detector) seems to be that both programs look only at edges in the contrast data, and ignores edges in the hue and saturation. Therefore, there are lots of missing edges in the left part of the image.

I added a preview image to the dialog so that the user can see the intermediate bitmap that underlies the trace. This should help in getting the adjustments correct.

Also, you might look at the settings that we are using. This is still just a very early bit of integration between Inkscape and Potrace, so tweaks obviously need to be done.

I will be mostly unavailable until Monday afternoon, but I will be eager to delve into this then.

Thanks,

Bob

Hi all, I'm finally back at the office.

Jon Phillips wrote:

I tried it with a 1024 by 768 72 dpi jpg image.

Ok...

..nothing fancy..

...hey, aren't those two items mutually exclusive? ;-)

.and it brought it to its knees.

Jon

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