Support `-p b` for using background colours and/or reverse video about timg

[hzeller]

Just tested 256 color support. Probably not too involved to add.

To test, please check out color-256-testing branch:
https://github.com/hzeller/timg/tree/color-256-testing

[hzeller]

Not quite sure what your request is: would you like that upscaled images (e.g. using -U) are more 'sharp` ? Maybe we should introduce an 'upscale, but only in integer multiples' variant, so that in a scale of 2, a pixel either fits one half block, or 4 half blocks (= 2 spaces with background color set).

The -U is already there to not upscale (and 'unsharpify :)') images if they are very small (such as icons). But having an integer option to scale it as multiple of original pixels will then always produce a sharp output.

(For pixelation: Internally, timg already does optimize the case of two vertical same pixels being replaced by one space as background color. If the image was integer-scaled with factor two in each direction, we automatically get spaces with background color output)

[hzeller]

I've added now added an optional parameter to --upscale: 'i' for integer upscale.

So a small picture, like this sunflower without upscaling

timg tiny-sunflower.jpg

... and that looks like this with --upscale (or -U) option (this looks bilinear scaling, so is 'fuzzy):

timg tiny-sunflower.jpg --upscale

... looks like this with integer upscaling --upscale=i:

timg tiny-sunflower.jpg --upscale=i

Is this roughly what you had in mind ?

[Alhadis]

Wait, I forgot that Terminal.app doesn't support 24-bit colours. I blindly assumed the following mess to be the fault of my terminal font:

However, Alacritty proved that wasn't the case:

I filed this issue before I remembered \e[35;2;R;G;Bm gets mangled by Terminal.app, so... 😅

On that note, is there a way to force \e[35;5;…m escapes for terminals that don't support 24-bit colour?

[hzeller]

On that note, is there a way to force \e[35;5;…m escapes for terminals that don't support 24-bit colour?

Not right now. It is the question if it is worthwhile supporting the by now mere handful of ancient terminals that do not support 24 bit color (without decreasing code readability too much or performance) vs. filing bugs with them to actually support it.

I mean, even xterm supports 24 bit color these days. And that is an ancient application from 1984 but still up to the present time.

Please file a bug for 256 color support. Let's see if that is more requested (and potentially considering sending a pull-request).

[hzeller]

Alright, there is now a --color8 option :)

[hzeller]

I guess we can close this one ?

[Alhadis]

Jesus. That was quick.

Thanks for the fast response!