gmic cannot read -.pgm

Software G'MIC
1

It seems gmic cannot read from stdin if in pgm format, as the following does not work:

cat foo.pgm | gmic -.pgm

or

gmic ... -o -.pgm | potrace ... -g | gmic -.pgm

I use potrace with its pgm backend thus the need to pipe that to gmic. Any solution? Maybe a bug? I just want to use pipes and not -exec within gmic, but will do so if necessary.

Thanks for any suggestion.

1 Like
2

I have no solution to this, but it doesn’t look hard to write up a G’MIC code that can read it. I written 4 different .pal format importer including at the hex level.

3

It looks like a bug, or at least a non-implemented feature that is described in the documentation. I’ll check that when I have some time.

4

will fix this. I’ll generate pre-release binaries for G’MIC 4.0.5_pre tomorrow.
I’ll tell you when it’s ready.
Thanks for reporting @alosca !

1 Like
5

Thanks @David_Tschumperle for taking a look at this! It certainly is a small feature and I am resolving it now with a -exec call to potrace but if reading -.pgm is available I will certainly adopt that.

6

I’ve posted a 4.0.5_pre release, at : Index of /files/prerelease

Now, this kind of things work:

$ gmic sp colorful -o -.ppm | gmic -i -.ppm

But it doesn’t seem to work on Windows yet, I don’t know why…

@alosca , is it possible for you to test it and tell me if that solves your issue ? What OS are you running?

7

I tested on Linux, my development OS. The simple test

cat foo.pgm | gmic -.pgm

is working. The second test with potrace output is not. gmic assumes the stream is a 3D file while in fact it is a P5, 2D pgm, file. See header below produced by potrace (ill formed?) and gmic output. Maybe P5 should be sufficient to indicate this is a 2D PGM? In fact, when saved to a file containing the same header format below gmic reads it with no problem:

  • problematic: cat foo.pgm | potrace -g | gmic -.pgm
  • okay: cat foo.pgm | potrace -g -o nada.pgm; gmic nada.pgm

The test below works, after splitting image size and quantization into different lines, so I assume gmic doesn’t like the formatted stream as is:

cat foo.pgm | potrace -g | awk '{ if (NR==3) { print $1,$2,"\n",$3 } else print $0 }' | gmic -.pgm

I will be happy to do other tests if needed, let me know.

P5
# created by potrace 1.16, written by Peter Selinger 2001-2019
1500 1500 255
_���"�჈��"��.���=ԝ�…

[774] : cat ct.pgm | potrace -g | gmic -i -.pgm
[gmic]./ Start G’MIC interpreter (v.4.0.5).
[gmic]./ Input file ‘-.pgm’ at position 0 (1 image 1500x1500x255x1).
[gmic]./ Display image [0] = ‘-.pgm’.
[0] = ‘-.pgm’:
size = (1500,1500,255,1) [2188.7 Mio of float32].
data = (0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,

8

I’de be intested to reproduce the issue here, so having the full PNM file generated by potrace could help!

9

This is actually an invalid header yes, as the ending 255 in line 1500 1500 255 should be placed on a new line instead.
As there have been some (unofficial) extensions to the PNM format, allowing to store 3D volumetric images (those extensions are used by Pink for instance), G’MIC explicitely infers that the line 1500 1500 255 defines a 1500x1500x255 volumetric image, with no COLORMAX field defined, rather than assuming a 2D image of size 1500x1500 with a COLORMAX of 255.

I could change the way the PNM headers are parsed, and assume that a 3D volumetric image with no COLORMAX if probably more a 2D image with a COLORMAX though, but this could break the compatibility with other PNM files (3D volumetric images that do not define a COLORMAX).

EDIT:

I’ve read the old thread : 3D pgm output support
and indeed, Pink uses also P5 to define 3D volumetric images.
So, if do something special for the P5 generated by potrace, this will probably break the support of 3D volumetric images in Pink.

10

I’ve done this:

Hopefully, this will help.

11

@alosca , I’ve done other modifications that should actually solve your issue.

By chance, do you compile gmic by yourself from the git sources ?
I’m not at the lab today, and from home, it’s really a pain to build/upload new pre-release binaries (because my network is really slow there).

If you compile gmic by yourself, it could be easier to test the latest commits and see if that works.

12

I’ve finally done it anyway. Feel free to test and tell me what happens :slight_smile:

13

I believe you no longer need the potrace file but if so here is a simple generated pgm for test:

https://tinyurl.com/potrace-example

it was created as in cat caju.pgm | potrace -g > caju_trace.pgm

14

By the way, the header in caju_trace.pgm has

P5
\# created by potrace 1.16, written by Peter Selinger 2001-2019
90 90 255

and gmic reads it without a problem, not a 3D interpretation. display from imagemagick also works.

15

Thanks for further investigating! Indeed, we don’t want to break what is assumed by Pink, i.e. P5 extension to 3D.

Regarding your other questions, I try to avoid compiling and use the builds you provide, but will compile if necessary. I will test the new pre-release binary and let you know what I get.

Much appreciated your attention to this minor issue. Much more effort than I anticipated, thanks!

16

I just tested and all works:

cat caju.pgm | potrace -g | gmic -.pgm

no longer a problem with the pgm stream.

Many thanks David!

1 Like
17

Nice! Thanks for reporting and testing the fix. Always nice to be able to make this kind of small improvements / bugfixes to the software.

1 Like