beautify image display with image dithering

[johnnychen94]

It's not tested, but I think Floyd–Steinberg dithering can be used to enhance the display quality in the terminal, and could also be used to encode image with 1 bit.

I'm not sure where the codes should be put to. ImageCore, ImageInTerminal, or ImageDithering? If ImageDithering, it might only have one algorithm :P

Thoughts? @timholy @Evizero

[Evizero]

Unsure. I always thought I'd someday get around to implement a strategy similar to https://github.com/stefanhaustein/TerminalImageViewer but that never happened

[jiviteshjain]

@johnnychen94 I had some questions regarding dithering. ImageInTerminal supports everything from 16 colours, 256 colours, to full 24bit RGB colours. In the case of 24-bit colours, and usual 24-bit RGB images, the quality loss is due to the image being downscaled and each pixel being shown as big as half a terminal block. In that case, the quality loss is due to low spatial resolution, not due to colour quantization. Not sure how to tackle that using Floyd-Steinberg dithering.

In the case of 16 or 256 colour terminals, this could be doable, though we will need a map between ANSI colour codes and the RGB colour they correspond to?

Let me know if there's something I'm missing.

[johnnychen94]

The repo @Evizero provides uses a fancy trick to tackle the big block issue -- spatial discretization.

Dithering can be used to improve the 8bit and 1bit rendering quality -- value discretization. Currently, images are just black boxes in CI logs, we can fix this and provide some visual information by specializing how 1bit is rendered, this can fuel our ReferenceTests suite and help diagnose issues similar to JuliaImages/ImageInpainting.jl#14

I think these two are orthogonal methods to improve this package. If you're interested in this, please take whatever path that is more attractive to you.

[johnnychen94]

Just found the wonderful https://github.com/adrhill/DitherPunk.jl package made by @adrhill that we might use. But the dependency is a little horrifying to me as it requires Images and UnicodePlots...

[adrhill]

I don't see a problem with making the dependencies more lightweight! UnicodePlots functionality is just there for fun and could be removed. I guess Images could be replaced with ColorTypes. However I'm planning on adding color algorithms, so ColorVectorSpace will probably be added soon.

[johnnychen94]

However I'm planning on adding color algorithms, so ColorVectorSpace will probably be added soon.

Most packages in JuliaImages now use ImageCore because it hides ColorTypes, Colors, ColorVectorSpace (via Reexport), and some other packages(e.g., MosaicViews, PaddedViews) from the dependency management.