Create a library instead of only a cli application

[guitmz]

How does this idea sound to you? I came across your project and really wanted to use it in one of my hobby projects. In the current state, I had to copy and paste a bunch of your code but making it a library would be very much nicer.

[eugene-eeo]

You can import the underlying library: github.com/eliukblau/pixterm/ansimage (that's what I did) if all you need is the rendering into a string.

Also does anyone have any ideas on how to make this work nicely with termbox? Currently I am working around it so termbox's internal buffer doesn't know about the image printed, but I am thinking of forking it and adding some kind of termbox renderer (doubt it will be possible tho).

[eliukblau]

@guitmz, @eugene-eeo is right. github.com/eliukblau/pixterm/ansimage is the package with the library, and only the library. CLI app is in separate code.

@eugene-eeo Sorry. termbox-go is not compatible with true color output. This makes it impossible for PIXterm to work correctly. (In addition, termbox-go uses a Terminal Cell concept, representing any character on terminal space. PIXterm simply outputs a string with a bunch of ANSI codes to the standard output.)

[eugene-eeo]

@eliukblau ah right, I always forget about true colour. Do you think I'll have a better chance with the dithering with characters mode? It looks like it takes up 1 "cell" per ANSIPixel. AFAIK tcell supports true colour, I'll just need to port my UI loop away from termbox.

[eliukblau]

@eugene-eeo Oh, maybe you can manually translate any ANSIPixel from the ANSImage in a properly form of tembox-go's Terminal Cells (hacking the Render() method of this two types). In addition, you need hack the tembox-go code to support arbitrary ANSI colors codes.

Someone was make a similar solution here. But, in this case, it uses the tview library instead of termbox-go.

[guitmz]

@eugene-eeo @eliukblau yeah thanks, thats what I ended up doing too (importing github.com/eliukblau/pixterm/ansimage). I forgot to write about it here. I'm testing with https://github.com/jroimartin/gocui and so far it seems to work fine :)

[eliukblau]

@eugene-eeo Yeah, Dithering Mode is more simpler than Classic Mode. But classic mode is not so complex either. Classic mode simply represents any terminal char as two rows of real pixels of the image with two rows of ANSIPixels (upper pixel and lower pixel). Dithering mode does the same, but uses a trick: because brightness calculation, it needs that each terminal char takes data from 8x4 pixel segments of the image. As example, here is the calculation to get correct image scaling in order to achieve this (taken from CLI code).

Classic Mode takes a real upper pixel and real lower pixel, and represents this as 1 cell on terminal (formed of 2 ANSIPixels [upper & lower]).

Dithering Mode takes 8x4 pixel segments, and represents this as 1 cell on terminal (formed of 1 ANSIPixel [only lower one]).

Sorry for the bad english.

[eugene-eeo]

@eliukblau ah right, thanks! I'll have a go at it. Thanks for the quick response!

@guitmz oh right, I didn't want to use any wrappers around termbox because I wanted to write my own (it's more of a learning thing than anything). I'll try it with gocui if I get stuck. Thanks.