Allow to specify a format for stdin/stdout

[whocares0101]

Using - as output returns something but not a png image, didn't try stdin yet. I'd like to transcode from png to flif and back to png through stdin/stdout from a python script, without temporary files.

[williain]

FWIW, the flif decode of a flif file piped into 'file -' gives me: /dev/stdin: Netpbm image data, size = 3648 x 2736, rawbits, pixmap

Also, FWIW, trying to encode an apparently correct png file to flif caused a segmentation fault in my build made just now. But I'm running this headless over ssh so can't see if the png file looks right - although I can just about make it out using tiv. It was created using imagemagic's convert tool from a jpeg file. This machine has only 2GB of RAM but if it is ram limited it's tearing through that rather rapidly. Maybe I'll try enabling swap tomorrow though.

From a quick grok of the source it seems a number of the command line arguments are passed through verbatim to flif-dec, and it looks to me like it hasn't decoded the output file type by then, so presumably along with the new options in flif.cpp, new code to decode that option will need to be written somewhere else (probably in flif-dec.cpp)

[jonsneyers]

@whocares0101 What is the purpose of transcoding via a lossless format? You can do something like flif -e input.png - | flif -d - - | convert - output.png (or just flif -e input.png - | flif -d - output.png), but unless there's a bug in FLIF, that is just a very slow way of doing cp input.png output.png ;) (or rather something like convert input.png output.png)

If you want to see what the result of doing lossy FLIF would look like, you can use e.g. flif input.png -Q50 output.png. No need to actually do a FLIF encoding then (unless you want to know the size of the FLIF file, but then a temporary file is the easiest way to get that size).

@williain Do you have the problem with any PNG file or with just one? Could you share the problematic PNG? Or the verbose output of an encode attempt (with -vvvvvv or so)...

[whocares0101]

@jonsneyers On disk storage, convert a png file to flif to save space and later convert it back to png when needed.

[jonsneyers]

So you can use flif -e input.png - and the output to stdout will be a FLIF file. And for the other direction you can use flif -d input.flif - | convert - png:- and the output to stdout will be a PNG file.

But if it is about saving space on disk, why not use the filenames directly instead of going through stdout? Just flif input.png output.flif and flif output.flif backtopng.png will work...

[whocares0101]

The place in my code where I'd like to convert PNG files to FLIF receives a bytes object and not a filename because the data was supplied by an http request. Also I'm using windows and I'd really like to keep the external binaries to a minimum. FLIF already can read/write PNG files, is it really so much work to add an option for this? For stdin auto-detection would be a nice thing and for stdout the possibility to select a format seems a reasonable thing to have.