A Live Preview version of the autotrace plugin is available here:
https://www.gimpscripts.net/2024/02/aut ... eview.html

Oh... If I knew it was a nepotist plugin, I would not have lose time to download it.

macOS and Linux people reading this, the full plugin is only for Micro$oft.

You can try to install autotrace with this > https://sourceforge.net/projects/autotrace/ (latest 0.31.1 is said to not work, thus those older version)
but don't ask me how to install it, I have no idea what to do with those files.

I'm sorry you wasted your precious time.

For those who know Linux better , I will just add the information that autotrace is assumed to be located in: "/usr/bin/" (if the location is different, edit line 190 (applies to Version 1.1).

I tried to compile autotrace in linux, but came up with many errors I don't understand. I'm not very good at compiling, sorry. It would be nice if someone that successfully compiles in linux and posts it here so I can try it out.

Thanks,

I've got autotrace in linux from 2019 except it doesn't work with .png so I use it with .ppm that gimp can export.

If used with .png I get:
y[5C]T[D5]: invalid chunk type
Other people have this problem:
https://github.com/autotrace/autotrace/issues/5

So I don't know if that's what you call "the full plugin" and I don't have Potrace:
viewtopic.php?f=9&t=17485&hilit=AutoTrace
viewtopic.php?f=9&t=17493

What linux distribution and version are you using?

Kubuntu 22.04 / Gimp 2.10.36 (PPA) / appimage launcher to add python.

Working ok here out of the can. The dialog does open large and needs sizing on each use. This a png so I do not have teapots issue.



Autotrace not in the repo, I must got from an older installation, I know I did not compile it. Some files zipped.
Put autotrace in /usr/bin
Put libautotrace.so.3 libgomp.so.1 libpstoedit.so.0 in /usr/lib
Run in a terminal and see if it gives dependency errors, Best of luck.

Teapot
Autotrace does not support png.
Instead of ppn, it is better to use bmp (the file is about 10 times smaller).
Potrace dla różnych platform można pobrać stąd:
https://potrace.sourceforge.net/#technical

Rich
Thank you for trying (I still have problems starting the new Ubuntu with the dualbott option).

As reported earlier the most recent compile of Autotrace for Windows is broken. Get the 0.4 version from https://github.com/autotrace/autotrace/releases This one: https://github.com/autotrace/autotrace/ ... -setup.exe

Windows does not support png but you should be OK with linux. This in version 0.40

rich@rich-neon:~$ autotrace -list-input
Supported input formats:
ppm Portable pixmap format
png Portable network graphics
pbm Portable bitmap format
pnm Portable anymap format
bmp Microsoft Windows bitmap image
tga Truevision Targa image
pgm Portable graymap format
gf TeX raster font

bmp is a bit peculiar, make sure that Compatibility Option > Do not write color space information is enabled otherwise Autotrace gives an error. Targa fails as well.

That worked great rich, thanks for posting the compiled linux version. I used layers and blending modes to make this.

Indeed, a good one, MareroQ, nice laughter

Thanks Rich for the files, sadly it does not work on my distro (Ubuntu-MATE 20.04)

But I think I did found where the problem comes from, I did input your terminal "autotrace -list-input" and the result looks like I'm missing a library, I'll try to found out that one this evening.

Changed GUI appearance in Ver.1.2

Yes, I have seen that type of error before when compiled on an older system

I have Autotrace installed on kubuntu 20.04 and since it appears in synaptic I assumed that it is in the repo. Looks like I got it from here:
https://launchpad.net/~finitelife/+arch ... u/unstable



I probably downloaded the deb and installed manually. It is one of the first things I install so a few years ago, a
slightly earlier revision.
As a note, I have tried the files I posted on Mint 21.3 and MX 23 and working there (although I did have to set permissions with MX 23)

Thanks Rich for posting the links.

I tested autotrace 4.0 for Windows only.

Some conclusions from the tests:

- using png doesn't work;
- writing to bmp works (it is a temporary file deleted after rendering),
- lack of operation for png is not important because autotrace (and potrace) does not support images with an alpha channel (transparency) at all,
- bmp can be saved with or without transparency,
- since autotrace does not support transparency (RGBA), you should save the bmp without the alpha channel (RGB), but this causes another problem - the transparency is replaced only with white, which may result in the loss of image fragments in the rendering. Inkskape also works this way (in the example the white shape has been lost).

Sample png image:



Result after opening and using Inkscape trace:



- this problem in Gimp can be easily solved by flattening a copy of the selected layer (with the selected color) before rendering.
The choice of this color depends on the colors of the active layer.
- live preview allows you to change BG multiple times (so this option had to be added to achieve the intended goal - this is included in versions 1.3)
- the advantage of this solution is the ability to directly use the text layer.

Examples from Gimp:

Incorrectly selected BG color:


Well-chosen background color:

[quote="MareroQ"]
...snip...
- since autotrace does not support transparency (RGBA), you should save the bmp without the alpha channel (RGB) [quote]

This is just a comment, not suggesting it should be implemented as it is a bit 'quirky'

Autotrace can specify a background color for removal. There is a -background-color parameter. I often use magenta FF00FF but Autotrace needs it entered a little off as FF02FF. You can get this by color-picking the Autotrace svg.

Then it might look like this: Left side without background removal Right side with -background-color FF02FF

Hi, Rich.

The possibility you presented is very interesting.
However, it was not used by Lloyd Konneker or Inkscape.
I think I know why - because when the image is partially transparent without taking into account BG Color (I described it earlier), the effect may be different than I expected. However, I added this option to version 1.4 (with Hex to RGB conversion).
Some examples:

Started image:


Removing (ignoring) black color with wrong color BG:


Well-selected BG color:


There is no problem if the image has no transparent parts:





Sorry, the attachment on gimpscripts.net was removed because the new option was very unintuitive.
This could be replaced with a Gimp color selection (if you were interested in that option).