Re: [Inkscape-devel] [Inkscape-user] Live trace?
[Note brought to inkscape-devel from Inkscape-user]
On 2007-May-04 , at 10:05 , Michael Grosberg wrote:
John R. Culleton <john@...360...> writes:
Is there a function in Inkscape equivalent to the "live trace" in the latest version of Illustrator?
No, there isn't.
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. - the preview is in the Tracing window rather than on canvas. - 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.
From a developer point of view: - what about auto-updating the preview when the parameters are changed? IMHO that would slow down things too much but maybe an auto- update checkbox would be nice for people on bigger machines than mine. - how hard would it be to put the low resolution bitmap preview of the trace on canvas rather than in the trace dialog? This would be a nice feature and would probably ease things very much when it comes to docking the trace dialog. - the color mapping feature is really nice and probably handy in some situations (e.g. I am doing a flyer with a defined color palette and I want to integrate a traced bitmap). I don't see any color mapping options in potrace so I guess this would require some substantial changes to potrace. Alternatively an extension which would map all colors in selected objects to their closer match in the selected swatches set would probably be very nice in many situations and not just on a traced object (I am thinking of cliparts imported from OCAL for example).
Cheers,
JiHO --- http://jo.irisson.free.fr/
- the color mapping feature is really nice and probably handy in some
situations (e.g. I am doing a flyer with a defined color palette and I want to integrate a traced bitmap). I don't see any color mapping options in potrace so I guess this would require some substantial changes to potrace.
Indeed there is no color mapping options in potrace since potrace does not even know about color. Inkscapes uses potrace to trace black and white bitmaps. The changes are to be done in Inkscape. It's probably not such a hard task since I think "palette" objects aready exist in Inkscape.
Regards, Stéphane.
Hi!
jiho 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.
- 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. Instead of quantization, we would just copy the colors of the swatches to the color table. But we would still need to color-distance map the source pixels to the swatch colors. This would be tougher to code in the GUI, but would actually use a little less cpu.
From a developer point of view:
- what about auto-updating the preview when the parameters are
changed? IMHO that would slow down things too much but maybe an auto- update checkbox would be nice for people on bigger machines than mine.
Yes, this would definitely use more CPU. The single-scan filters would not be so bad, but quantization and color multi would take a lot.
Doing a Preview each time a radio button or check box is changed to alter the type of filter would be OK, I think. Doing a Preview every time the number changed in one of the numeric spinboxes would be awful. Maybe only doing it on the release of a spinbox would work.
- how hard would it be to put the low resolution bitmap preview of
the trace on canvas rather than in the trace dialog? This would be a nice feature and would probably ease things very much when it comes to docking the trace dialog.
(above)
- the color mapping feature is really nice and probably handy in some
situations (e.g. I am doing a flyer with a defined color palette and I want to integrate a traced bitmap). I don't see any color mapping options in potrace so I guess this would require some substantial changes to potrace. Alternatively an extension which would map all colors in selected objects to their closer match in the selected swatches set would probably be very nice in many situations and not just on a traced object (I am thinking of cliparts imported from OCAL for example).
(above)
Those are good ideas. The idea of allowing the user to pick the colors of the multiscan has been mentioned before. But I think that the swatch GUI would really help this to be a reality. And it would not be so bad to get rid of the Preview area on the Trace dialog. It has always been an awkward size and shape for the dialog. Just look at the Preview button! :-)
bob (ishmal)
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/
participants (3)
-
Bob Jamison -
jiho -
Stéphane Gimenez