"Completely wrong" -input-format handling

[sgbeal]

(i hope i'm in the right bug db...)

uname -a
Linux st3v3 4.10.0-38-generic #42~16.04.1-Ubuntu SMP Tue Oct 10 16:32:20 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
autotrace -version
AutoTrace version 0.31.1.

autotrace's handling of -input-format seems to be completely hosed. As input i have a PNG file:

autotrace -output-file x.svg -input-format PNG -dpi 300 -color-count 16 x.png
[ED]u[DB]H: invalid chunk type

So i convert the png to bmp and try that:

autotrace -output-file x.svg -input-format BMP  -dpi 300 -color-count 16 x.bmp 
Error reading BMP file header

But... while testing that i accidentally mis-typed BMP as BPM and i accidentally fed it a PNG file, and it worked:

autotrace -output-file x.svg -input-format BPM -dpi 300 -color-count 16 x.png

No error, despite the BPM typo, and it generates the expected SVG output. That also works if i replace x.png with x.bmp, but only if i feed it an illegal -input-format type.

If i remove -input-format, it behaves just like it does with PNG:

autotrace -output-file x.svg -dpi 300 -color-count 16 x.png
[ED]u[DB]H: invalid chunk type

The only option which works for me is to feed it an invalid -input-format type:

autotrace -output-file x.svg -input-format WTF -dpi 300 -color-count 16 x.png

WTF indeed. Locally supported formats:

autotrace -list-input-formats
Supported input formats:
  PNG Portable network graphics
  TGA Truevision Targa image
  PBM Portable bitmap format
  PNM Portable anymap format
  PGM Portable graymap format
  PPM Portable pixmap format
  BMP Microsoft Windows bitmap image
  3FR Hasselblad CFV/H3D39II

[jnweiger]

Can reproduce this with 0.40.0 on ubuntu 18.04:

autotrace --centerline  --output-format=svg github/fablabnbg/inkscape-centerline-trace/testdata/dolly.png
[DB][B2][E3][AA]: invalid chunk type

Specifying a different or invalid input format does not help for me.

[Notis]

I'm using tga format

[Russtopia]

I am also having format issues on Funtoo x86_64, autotrace 0.40.0.

$ ./configure --without-magick
$ make && sudo make install
$ autotrace -list-input-formats
Supported input formats:
   gf TeX raster font
  pgm Portable graymap format
  tga Truevision Targa image
  png Portable network graphics
  pnm Portable anymap format
  ppm Portable pixmap format
  bmp Microsoft Windows bitmap image
  pbm Portable bitmap format
$ autotrace -version
AutoTrace version 0.40.0.

$ autotrace -input-format png -output-format pdf -preserve-width wh01.png >wh01.pdf
w[94][D5][C4]: invalid chunk type

$ gwenview wh01.png
$ # (valid PNG file displayed)

--

Sadly this makes the program pretty useless -- can't process PNG at all.
The error string "invalid chunk type" doesn't even occur within the source code of autotrace. So is this error coming from libpng or some other helper lib ?

I also tried building autotrace-0.31.1(from debian sources) on this same Funtoo Linux, it gives the same error; so I suspect it's an issue with the input PNG format, or an auxilliary library has made a breaking change, and upon which autotrace depends.

The PNG was created using ImageMagick 7; could this also be a source of incompatibility (ie., IM7 putting PNG stuff in that autotrace or libpng doesn't understand?)

I have an old install of IM6.9 and autotrace-0.31.1 on Cygwin64 elsewhere, and it can understand the PNGs from ImageMagick 6.9 (though, as reported above, one has to give -input-format=WTF or other invalid format to get it to work).

[Cygwin64 autotrace-0.31.1]

$ ldd $(which autotrace) | grep png
        cygpng16-16.dll => /usr/bin/cygpng16-16.dll (0x3e14b0000)

[Funtoo Linux x64, autotrace-0.40.0]
$ ldd $(which autotrace) | grep png
libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007f885c7fd000)

[Russtopia]

UPDATE: I have tested building branch Martin_Weber_input_png_15 and this now does accept '-input-format png' properly, and appears to output PDF and DXF formats for me properly.

I had to build suing ./configure --without-magick, due to compile issues, even with ImageMagick-6.9.

Suggest prioritizing merge of this branch to fix PNG input handling, but the issues with ImageMagick remain.

[josephrocca]

Also get an i[AC][AD]W: invalid chunk type error for PNGs, but I'm also getting this error for this BMP (and yet I've had other BMPs work fine):

autotrace --centerline char.bmp
autotrace: src/input-bmp.c:244: ReadImage: Assertion `image' failed.

I haven't dug into what's causing it yet. Going to try Martin_Weber_input_png_15 branch as suggested by Russtopia since I was only resorting to BMPs because PNGs weren't working.

Edit: And this BMP file also doesn't work (produced with convert char.png char2.bmp - a different method to the other file). It gives Error reading BMP file header as mentioned above by sgbeal. Here's the original PNG.

[photopea]

@josephrocca "char.bmp" has a negative height, which means, that the first pixel is the top left pixel (otherwise, BMPs always start with a bottom left pixel). This little part of the spec is often ignored, as such BMPs are quite rare :)

"char2.bmp" has a header of 124 Bytes (BITMAPV5HEADER), instead of more common 40 bytes. It also has a compression==3 instead of more common compression=0 (as it contains transparency). Also, when you open "char2.bmp" in Photoshop, the transparency is ignored. So far, it looks like no program accepts BMPs with transparency.

I strongly suggest not to store images in BMP nowadays and convert them to PNG as soon as possible :D

[josephrocca]

Thanks for the insights, photopea! I managed to get the Martin_Weber_input_png_15 branch working like this:

sudo apt-get install autoconf automake pkg-config libgtk-3-dev autopoint
sudo ./autogen.sh
./configure --without-magick --without-pstoedit
make
sudo make install

And it works for PNGs, but the centerlines it produces are not centerlines at all:

./autotrace --centerline --output-format=svg char.png > char.svg

Perhaps this has to do with excluding imagemagick? I have no idea :S If I end up working it out I'll post here.

[photopea]

Hi, I just noticed this library is about tracing bitmaps to vector graphics. This feature is present in Photopea and is better than many commercial tracers: https://blog.photopea.com/vectorize-bitmaps-in-photopea.html

[josephrocca]

@photopea Very cool! It looks like it doesn't support centerline/midline tracing though? And fair enough because it's not a very common need. I'm specifically trying to turn glyphs like "G", above, into centerline traces rather than outlines. Also, I need to be able to do it programmatically (hundreds of thousands of images). We're probably heading off-topic now though. But, as I said in my email - thanks for the excellent tool!

[Russtopia]

For anyone interested: I gave up on this version of autotrace and have been happy with potrace:

potrace 1.15. Copyright (C) 2001-2017 Peter Selinger.
Library version: potracelib 1.15
Default unit: inches
Default page size: letter

Possible input file formats are: pnm (pbm, pgm, ppm), bmp.
Backends are: svg, pdf, pdfpage, eps, postscript, ps, dxf, geojson, pgm,
gimppath, xfig.

.. unsure where the definitive upstream is, as there are a ton of forks on github, but the above is the version info from my Funtoo installation. It handled BMP input to PDF and DXF for me much better than current versions of autotrace.

[diyseguy]

UPDATE: I have tested building branch Martin_Weber_input_png_15 and this now does accept '-input-format png' properly, and appears to output PDF and DXF formats for me properly.

This worked for me, on OSX, I was able to build without issue using the instructions from INSTALL_OSX.md.

autotrace -output-file foo.svg -centerline drunkenbooboobear.png

It did a pretty good job!

[frnkhng]

Thanks for the insights, photopea! I managed to get the Martin_Weber_input_png_15 branch working like this:

sudo apt-get install autoconf automake pkg-config libgtk-3-dev autopoint
sudo ./autogen.sh
./configure --without-magick --without-pstoedit
make
sudo make install

And it works for PNGs, but the centerlines it produces are not centerlines at all:

./autotrace --centerline --output-format=svg char.png > char.svg

Perhaps this has to do with excluding imagemagick? I have no idea :S If I end up working it out I'll post here.

Thank you. This branch works. But I a got another issue, the right part of image is missing.