It’s beautiful! I actually adjusted my python code to your method and just for optimization checked if the current two pixel colors match the previous two and if so leave out the color info. Much more fidelity in the images now!
As an extra optimization, if top and bottom colors of a pixel match, you can just output space and only set background color. Implemented correctly, this can save a lot of memory. Didn’t want to make the code more complex in fear of people being scared of running it.
I’ve been learning Rust by going through The Book… there’s some wack-ass syntax in that language. I’ve mostly used C# and Python so most of it just looks weird… I can more or less understand what whileletSome((_, top)) = iter.next() { ... } is doing, but .for_each(|((_, _, t), (_, _, b))| { ... } just looks like an abomination. And I mean the syntax in general, not this code in particular.
In C#, the closest is lambda expressions, declared like this:
( arguments ) => { calls }
Parentheses are tuple deconstructors. In C# you have exactly the same thing. Imagine you have a method that returns a two element tuple. If you do this:
var (one, two) = MethodThatReturnsATuple();
You’ll get your tuple broken down automatically and variables one and two declared for you.
First of all, I’m using .zip() to pair the rows of the picture by two, that returns a tuple, so, I have to deconstruct that. That’s what the outer parentheses are for. The pixel enumeration stuff I’m using returns a tuple (u32, u32, &Rgba<u8>) first two values are x and y of the pixel, the third one is a reference to a structure with color data. I deconstruct those and just discard the position of the pixel, you do that with an underscore, same as C#.
I’m not that far into learning myself, but I’m not a textbook learner at all. Poking around opensource projects and wrestling with the compiler proved to educate me a lot more.
I gladly present you this jank.
You might need these to compile:
And the jank itself:
Some Rust code
use std::path::PathBuf; use clap::Parser; use image::{ imageops::{self, FilterType}, ImageReader }; #[derive(Parser)] struct Cli { path: PathBuf, #[arg(short = 'H', long, default_value_t = 30)] height: u32, #[arg(short, long, default_value_t = 0.4)] ratio: f32, #[arg(short, long, default_value_t, value_enum)] filter: Filter, } #[derive(clap::ValueEnum, Clone, Default)] enum Filter { Nearest, Triangle, Gaussian, CatmullRom, #[default] Lanczos3, } fn main() -> Result<(), Box<dyn std::error::Error>> { let args = Cli::parse(); let filter = match args.filter { Filter::Nearest => { FilterType::Nearest }, Filter::Triangle => { FilterType::Triangle }, Filter::CatmullRom => { FilterType::CatmullRom }, Filter::Gaussian => { FilterType::Gaussian }, Filter::Lanczos3 => { FilterType::Lanczos3 }, }; let img = ImageReader::open(args.path)?.decode()?; let original_ratio = img.width() as f32 / img.height() as f32; let width = ( args.height as f32 / args.ratio ) * original_ratio; let out = imageops::resize(&img, width as u32, args.height * 2, filter); let mut iter = out.enumerate_rows(); while let Some((_, top)) = iter.next() { let (_, bottom) = iter.next().unwrap(); top.zip(bottom) .for_each(|((_, _, t), (_, _, b))| { print!("\x1B[38;2;{};{};{};48;2;{};{};{}m\u{2584}", b[0], b[1], b[2], t[0], t[1], t[2]) }); println!("\x1B[0m"); } Ok(()) }It’s beautiful! I actually adjusted my python code to your method and just for optimization checked if the current two pixel colors match the previous two and if so leave out the color info. Much more fidelity in the images now!
As an extra optimization, if top and bottom colors of a pixel match, you can just output space and only set background color. Implemented correctly, this can save a lot of memory. Didn’t want to make the code more complex in fear of people being scared of running it.
I’ve been learning Rust by going through The Book… there’s some wack-ass syntax in that language. I’ve mostly used C# and Python so most of it just looks weird… I can more or less understand what
while let Some((_, top)) = iter.next() { ... }is doing, but.for_each(|((_, _, t), (_, _, b))| { ... }just looks like an abomination. And I mean the syntax in general, not this code in particular.This is actually fairly similar to what C# has.
This is a closure syntax:
| arguments | { calls }In C#, the closest is lambda expressions, declared like this:
( arguments ) => { calls }Parentheses are tuple deconstructors. In C# you have exactly the same thing. Imagine you have a method that returns a two element tuple. If you do this:
var (one, two) = MethodThatReturnsATuple();You’ll get your tuple broken down automatically and variables
oneandtwodeclared for you.First of all, I’m using
.zip()to pair the rows of the picture by two, that returns a tuple, so, I have to deconstruct that. That’s what the outer parentheses are for. The pixel enumeration stuff I’m using returns a tuple(u32, u32, &Rgba<u8>)first two values are x and y of the pixel, the third one is a reference to a structure with color data. I deconstruct those and just discard the position of the pixel, you do that with an underscore, same as C#.I’m not that far into learning myself, but I’m not a textbook learner at all. Poking around opensource projects and wrestling with the compiler proved to educate me a lot more.
It’s not so different in python:
for ((_, _, t), (_, _, b)) in zip(top, bottom):Or in C#:
.ForEach(((_, _, t), (_, _, b)) => Console.Write(...));Is
| (...) | { ... }a lambda expression then?Yep, lambda or closure (it’s an anonymous function but it can also capture state from the enclosing function, i think pure lambdas can’t do that?)