On 2007-May-04 , at 18:02 , Bob Jamison wrote:
The is a tracing function in Inkscape in Path > Trace bitmap. The differences are that in Inkscape:
- you get a small bitmap preview of the trace result before doing
the actual trace. From my point of view this allows to work on small machines while redoing the complete tracing each time you change a parameter (i.e as in Illustrator) is probably very resource hungry. The bitmap preview is not autoupdated so that's not exactly "Live" but the update is just a click of a button away.
Inkscape's Trace has a small set of "filters" that preprocess the source image and convert it to a form usable by Potrace. Potrace only does tracing of black and white images (which is good, I think: do one job, and do it better than anyone else on the planet. Peter Selinger is a genius). So Trace takes the selected GdkPixbuf and converts it into a black&white internal version that Potrace can use. The Preview image is a temporary GdkPixbuf copy of that interval bitmap that we make to be displayed to the user.
It is a special case for color multiscan. There is an internal indexed-color bitmap from which we generate the black and white layers for the individual scans. For Preview, we make a GdkPixbuf from this indexed-color bitmap.
But in either case, Preview is making a GdkPixbuf copy for the user of what Potrace will see.
- the preview is in the Tracing window rather than on canvas.
This is interesting. We might want to look at this. This might not be any more trouble than how we currently transform the output svg to overlay the original image. A nice benefit would be that we could get rid of the Preview area on the dialog. Of course, putting the preview image on the document would mean adding and removing images on the document tree, so there might be issues with that.
This would really be nice IMHO. another small concern would be the resolution of the GdkPixbuf copy. It seems quite low in the preview tab. could it be better on canvas without eating all the resources for its display?
- there are not tracing presets as in Illustrator but I guess
these should not be too hard to make
- the color mapping (map the trace colors to a palette) does not
exist (and the functionality is pretty cool actually see http:// www.creativecow.net/articles/mcmahon_frank/livetrace/livetrace.htm ) So there are less bells and whistles but the main functionality is there.
Currently it does octree quantization of the source image, to make an indexed color image (similar to a GIF) with colors that most closely fit, in color distance, the pixels of the original image.
If we did it with color swatches, then I suppose the number of swatches selected would be the number of scans and number of colors in the indexed-color bitmap.
That may be a solution but would differ from Illustrator's approach. From what I can see in the above mentioned tutorial it seems that the user picks a number of colors in the final trace (let say 6) and a swatches palette (with 20 colors for examples). Among the 20, the 6 which are closer to the image are chosen and the trace is done with them. This is probably a better way to use swatches because they contain very often more colors than are wanted in the final trace. I don't know how the color choice is made but a straightforward way would be: a- do the normal trace with 6 colors process -> this outputs an image with only 6 colors b- for each one, look for the color closer to it in the swatches with a draw without replacement (so that the same color of the swatch cannot be used twice). for this to give good output it should probably be done in several passes: 1. estimate the distance between all 6 colors and those in the swatches, rank the 6 in decreasing order of similarity with the colors in the swatches 2. assign the most similar one, then the second and so on 2.1 if there is no conflict (conflict = two colors from the 6 are most similar to the same color of the swatches) that's fine 2.2 if there is a conflict restart at 1 for the remaining colors and the swatches minus already assigned colors c- change the colors in the output
But as you can see, "a" would be the trace process while "b" and "c" would be independent processes, hence my idea of a more general extension to match some objects to a given set of swatches. On the other hand, having that integrated in the tracing allows to see a preview of the result without having to apply the trace and the extension... so both are probably very useful.
NB: The method fails when there are more colors in the original objects that there are in the swatches though. But those special cases could probably be handled with a warning that the number of colors in the output will be diminished.
[snip]
JiHO --- http://jo.irisson.free.fr/