STDIN?

[MTNTheCompWiz]

How much of a pain would it be to take input from stdin?

[stefanhaustein]

Shouldn't be hard but quite busy at the moment... Happy to accept a pull request O:)

[stefanhaustein]

p.s. did you try /dev/stdin as file name?

[HybridDog]

did you try /dev/stdin as file name?

I have tried it, it does not work because somehow it does not recognize the file format:

convert-im6.q16: no decode delegate for this image format `' @ error/constitute.c/ReadImage/504.
convert-im6.q16: no images defined `pnm:-' @ error/convert.c/ConvertImageCommand/3258.
sh: 1: gm: not found

[CImg] *** CImgIOException *** [instance(0,0,0,0,(nil),non-shared)] CImg<unsigned char>::load(): Failed to recognize format of file 'stdin'.
File format is not recognized for 'stdin'

For PNG images I can do ln -s /dev/stdin stdin.png and use stdin.png instead of /dev/stdin, this works for me.
If I remove the .png extension from a png file and open it with tiv, it still recognizes the file format whereas with /dev/stdin it does not.

ln -s /dev/stdin /tmp/stdin.png
cat wmiz.png | tiv /tmp/stdin.png

[hadisfr]

There's a not so clean approach, to save input in a temporary file, run program on it, and then, delete it. I think process image data directly needs some changes in CImg library. Creating an issue in CImg's repo for this may be good.
And there should be a method for distinguishing between file address and image data.

[stefanhaustein]

The reason why the extension works is probably that it saves cimg from consuming part of the file to figure out the type.

Maybe we could let the makefile create stdin aliases named stdin.png, stdin.jpg etc. and then use some special parameter to access them? Seems hacky (but still better than a tmp copy) though. Or we just document this approach on the main page?

[mnpenner]

Why not just add --format=jpg or --format=png options? This would bypass parsing the file to figure out the type for both stdin and incorrectly named files?

[stefanhaustein]

The problem is that CImg (the library that is used to load the images) doesn't seem to support providing the file type by other means than the file extension.

The best fix would probably be a corresponding feature in CImg...

[user202729]

Actually CImg does support specifying the type, using the load_xxx member functions (for example load_bmp)

[stefanhaustein]

I'll have another look when the snap and macos things are resolved (and nobody has stepped in in the meantime) O:)

[boretom]

I was wondering what the problem may be and had a look at it (TL;DR: not successfully):

• CImg can handle files without extension, it then uses file magic to decide the image type (check for ftype() method in CImg.h). Worked well for me.
• There is special handling if the input file is "-", like fclose() not closing the stdin or stdout. In the latest version (255) of CImg.h there is also special handling in some fopen() methods to not open if it's stdin or stdout (since they are always open)
• I managed to make it work using not "-" but "/dev/stdin" and using fseek() to reset the position. But only with input redirection ( tiv - < someimage.jpg) and not piping (cat someimage | tiv -). I haven't found the root of it. Even more strange is that comparing cimg::_stdin() and "/dev/stdin" did not result in the same file pointer ; but it should
• Since CImg.h works with external utilities like convert and gm it assembles command lines to call them and seems to expect a filename. Well, a lot of calls in CImg.h use a filename as an argument and not file handle.

When I get time I'll gotta put a question on CImg.h github.

[ghost]

did you try /dev/stdin as file name?

I have tried it, it does not work because somehow it does not recognize the file format

Perhaps it fails because stdin is not seekable? I wonder if there's a simpler alternative to CImg that plays better with streams? For the needs of tiv, CImg seems a bit overkill.

I'd really like to have this as well, but I'm not willing to dig through the 64kloc of CImg.h to figure out what changes are needed…