Terminal I/O of images

[lgritz]

This is a little kooky maybe, but it was something I was playing a couple
years ago, finally inspired by Chris to clean it up and PR it.

This patch adds a "term" format which, instead of writing files,
outputs a preview image to a true color text terminal window.

Is any of this useful? I have no idea. But it's kinda fun.

The quick demo of this is:

oiiotool myfile.exr -o out.term

It will only do something useful if on a color terminal emulator with
24 bit color capability and Unicode. (I've tested it on the
gnome-terminal on Linux, and iTerm2 on Mac.)

The best quality results are on Mac if you are using iTerm2, it can
additionally do an actual pixel output (iTerm2 has as a nonstandard
feature the ability to send inline images to the terminal). This is
the "iterm2" method, but it's only expected to work on Mac with
iTerm2. It will automatically use this method as the default if you
are running iTerm2.

Next best is (thanks, Chris) is to display two pixels (vertically) in
each character cell, by outputting the Unicode "upper half block"
glyph (\u2508) with the foreground color set to the top pixel's color
and the background color set to the bottom pixel's color. This is the
default if you're not on a Mac running iTerm2. To demo (if you're on
have iTerm2 but want to see this method):

oiiotool myfile.exr -attrib term:method 24bit -o out.term

But some terminals and fonts don't support unicode, or don't display
this character, or display it with an ugly border. So you can also use
an alternate method:

oiiotool myfile.exr -attrib term:method 24bit-space -o out.term

where doesn't use the unicode trick but instead outputs a space (' ')
for each 2 vertical pixels, simply setting the background color to the
average of those two pixels.

There's also a "256color" method that just uses the 6x6x6 color space
in the 256 color palette -- which looks horrible -- and an
experimental "dither" which does a half-assed Floyd-Steinberg
dithering, horizontally only, and frankly is not an improvement unless
you squint really hard.

In all cases, the image will automatically be resized to fit in the
terminal, as well as converted to sRGB so it looks kinda ok.

Along the way, I added a new ImageOutput::supports("procedural")
query. If the existing input supports("procedural") query says
whether the input image is being generated procedurally and doesn't
correspond to an existing file on disk being ead, then the output
supports("procedural") is the opposite -- is the output doing
something procedural that does not correspond to a file being written.
(The specific use is to use this to avoid oiiotool attempting to
rename the file to move it into its final position.)

Signed-off-by: Larry Gritz lg@larrygritz.com

[fpsunflower]

LGTM!