add an additional mixed-blitter?

[joseluis]

This C project seems to have an optimized algorithm to choose the most appropriate symbols https://github.com/csdvrx/derasterize maybe we could use something like that?

Examples:


![snake_original](

PS found out about it on the interesting sixel support thread for microsoft terminal

[csdvrx]

If you can wait a bit, I'm going to release a new version that's much faster. It was done to support videos with mpv in tmux-sixel

[dankamongmen]

Hey there, @csdvrx ! I've seen your work, and thought it good. It's nice to get all we terminal hackers 'round the fire.

I'll take closer look at this soon. @joseluis , does image quality beat us? Like your pretty snake, I move more quickly when threatened =].

[dankamongmen]

@joseluis , running derasterize.c and notcurses-view on sample/snake.jpg seems to generate almost indistinguishable images, except notcurses-view takes .074s, while derasterize.c takes .303s, about 4x the notcurses-view time.

[schwarzgerat](127) $ time  notcurses-view -t0 samples/snake.jpg
Term: 45x80 vte-256color (VTE with xterm 256-colors)

 notcurses 2.1.4 by nick black et al 
  45 rows 80 cols (56.25KiB) 16B cells 256 colors+RGB
  compiled with gcc-10.2.1 20201224, little-endian
  terminfo from ncurses 6.2.20201114
  avformat 58.45.100 avutil 56.51.100 swscale 5.7.100
1 render, 80.53µs total (80.53µs min, 80.53µs max, 80.53µs avg)
1 write, 15.64ms total (15.64ms min, 15.64ms max, 15.64ms avg)
132.05KiB total (132.05KiB min, 132.05KiB max, 132KiB avg)
0 failed renders, 0 failed writes, 0 refreshes
RGB emits:elides: def 4:37 fg 3543:55 bg 3511:50
Cell emits:elides: 3600/0 (0.00%) 90.24% 1.53% 1.40%
real 0m0.074s
user	0m0.033s
sys	0m0.008s
[schwarzgerat](0) $ 

vs

[schwarzgerat](0) $ time ./derasterize.c samples/snake.jpg > /dev/null
real	0m0.303s
user	0m0.318s
sys	0m0.014s
[schwarzgerat](0) $

if derasterize.c looked better when you filed this bug, it's probably because we weren't yet using sextants by default. now, derasterize.c does use things like THREE EIGHTHS BLOCK, which we don't, and maybe ought consider. but i suspect that sexblitter is roughly equivalent. even where we can't use sexblitter (e.g. alacritty), quadblitter seems about as good:

so if you find a case where we're noticeably worse, i'm very interested, but for now i'm feeling like the fastest terminal cowboy in the west [blows smoke from guns]. =]

@csdvrx , please don't interpret this as a knock on your superb work! just proud of my own =].

[joseluis]

Athough sexblitter has been an improvement, it does have less resolution due to the lack of vertical and horizontal eight blocks, diagonal bloks, diagonal lines, crosses, etc. The racoon image is the one that better shows the extended shapes palette.

I'd still add this new mixed blitter at some point, once Charlotte releases the new version. No need to rush in anycase.

[dankamongmen]

I'll take a look at raccoon, thanks for the heads-up. @csdvrx , do you intend to expose your blitter as a library? It looks like it's only built as a binary at the moment.

it does have less resolution due to the lack of vertical and horizontal eight blocks
well, sexblitter gives you 3x vertical and 2x horizontal. they don't seem to be using the 1/8 horizontal blocks, though i'm sure it'd be trivial to add them. a bigger concern of mine is how to deal with the mixed mode. they're doing, so far as i can tell with a quick look at adjudicate(), a comparison of how similar the glyphs are to the desired output. does this work at different scales? hrmmm, i guess it does, probably

....i guess i'm thinking: we have a number of Y rows and X columns to which we're going to output, right? so we then resize the input to be Y * {height of blitter} and X * {width of blitter}, trusting ffmpeg/oiio to do a resize way better than we will, and then have a multiple of our comparison geometries. there's no guarantee of that here. which maybe isn't a problem? i'm unsure, will ponder it. this is why, for instance, we don't have a superblitter that utilizes both quads and sextants -- if we're mapping 3x2 pixels to a single cell, there's no
way we ever use an UPPER HALF BLOCK nor LOWER HALF BLOCK, because we'd need 1.5-pixel matches. but hrmmm, that might actually be a better solution -- imagine you have input pixels 0x000000, 0x888888, and 0xffffff. the best blit of that may well be 0x444444 + 0xbbbbbb using half blocks, rather than what you'd get right now (not better than 0x444444 + 0x444444 + 0xffffff). HRMM. yeah, i think i've been assuming some false constraints in my sexblitter. HRMMMM. hrm!

oh hey, it looks like some of this code is due my girl @jart. [wave!] (we worked together at Google NYC)

another worry is that derasterize approach doesn't seem easily composed with other planes, which it needn't worry about, but we do. see e.g. #1068 which would be severely exacerbated.

[jart]

I think @csdvrx has textmode supremacy here. Look at that lemur.

[dankamongmen]

i personally think the undetailed area on the left looks better, color-wise, in y'alls', and mine is better with the shadow on the eye and less weird banding above the eye / bottom of the top rind of the ear. they're certainly close.