Re: Bug#931534: ITP: viu -- Command-line application to view images from the terminal
On Sun, Jul 07, 2019 at 12:15:20PM +0200, Wolfgang Silbermayr wrote:
> On 7/7/19 11:51 AM, Adam Borowski wrote:
> > On Sun, Jul 07, 2019 at 11:25:47AM +0200, Wolfgang Silbermayr wrote:
> >> Package name: viu
> >> Upstream Author: Atanas Yankov <atanas.yankov98@gmail.com>
> >> URL: https://github.com/atanunq/viu
> >> Description:
> >> viu is a small command-line application to view images from the terminal
> >> written in Rust. It uses unicode lower half blocks to fit 2 pixels into
> >> a single cell by adjusting foreground and background colors accordingly.
> >
> > Hi!
> > This looks exactly as what "catimg" does -- is there are any reason to
> > prefer viu over catimg?
> [...]
> > Thus: is there anything viu does better than the above tools?
>
> In fact, catimg is new to me. I did a quick test, and it looks quite good.
>
> I follow what is happening in the Rust crates ecosystem, so I stumbled
> over viu when it got published, and thought it would be great to have
> this tool packaged.
>
> A quick test showed nearly identical output when scaled to the same size
> (with minimal difference in colors, I assume due to downscaling).
Even assuming identical output capabilities, there are many algorithms for
scaling and palette reduction. And then, you need to handle 16-color,
256-color and 24-bit output (88-color being thankfully dead).
> What I find a bit inconvenient is that catimg defaults to the full
> terminal width whereas viu takes both height and width of the terminal
> into account.
chafa doesn't have this problem, and seems to be better than both of these
tools.
> Do you think it's a disadvantage to have some similar command-line tools
> packaged where some people would prefer one and some the other?
Yes, archive bloat puts a load on the QA team, on the mirror network and
people's machines (every package takes ~1KB of space just for the indices),
and so on. It also wastes people's time, making them wonder which of the
tools should they use.
Thus, I'd refrain from adding redundant implementations unless there is
_some_ reason the new one is better.
> Especially with the consideration that - at least in my experience -
> rust packages require very low amount of work for packaging and maintenance?
Let's start with porting efforts: even the Rust compiler itself doesn't
build at all for 10 out of Debian architectures. There are much better
choices than Rust for writing programs...
(But at least it supports dynamic linking, unlike certain *akhem*
competitors.)
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ According to recent spams, "all my email accounts are owned
⢿⡄⠘⠷⠚⠋ by a hacker". So what's the problem?
⠈⠳⣄⠀⠀⠀⠀
Reply to: