i read through the code, and i have some tips, which you may find helpful (or not):
argument parsing: if --color is not the first argument, it will try to open a file named --color, which i assume is unintended. i would suggest checking out the clap crate to easily parse args
i’m quite sure why you used ‘clusters’ instead of resizing the image to the terminal width? if it is purely as a programming exercise, or for performance reasons, then that’s great! but otherwise, calling image.resize() is easier
.len() on a string returns length in bytes, not characters, so could break with non-ascii text. in the context of this program, the text will always be ascii, so it is of course not a problem, but it’s worth to keep in mind. to get character length, use .chars().count()
in my testing, the width of the image is always affected by the width of the terminal, always being less than the maximum possible width, causing the image to be stretched vertically. i’m not sure why this is happening
in get_brightness_of_cluster, pushing to a Vec and then calling .sum() can be replaced with a loop which increments a mutable u32 variable. this is a nitpick, but it can avoid unnecessary memory allocation
check out this example.
sorry if this comes off as rude or a nitpick, i’m just trying to provide some advice :)
Thank you for your help this is not rude at all and very helpfull!
I know about argument parsing with clap, and started thinking about it as I started to add more functional to the program
Is resizing and image is more performant? I yes then i was wrong when coding with clusters, it’s always good to have another viewpoint for tasks like this
I didn’t even think of resizing an image)
About .len i think it’s fine as long as it works
The width of images should be resized depending on your terminal width and height, im still not sure how i can improve it, because every image is unique
get_brightness is a bit broken in performance right now, i will fix it later
:) no problem! i would assume resizing the image might be a little slower, because it creates a clone of the image, but if you use FilterType::NearestNeighbor, the speed is negligable in my opinion
Its the mathematical term for estimation and constructing new data from existing data.
In the context of what you are doing, it’s resizing images.
You are doing something called linear interpolation. This works great for shrinking an image.
However, have you considered what happens when your ASCII resolution is greater than your image resolution? This is where bilinear and bicubic interpolation come in.
These algorithms are cool but are also massive overkill for your average use case. They only make a different in a very niche use case (when your ASCII resolution is greater than your image, such as pixelart)
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.
And in the end you turned it back to an image.
because tiles like this are not supported on lemmy
It’s always fun building interesting things, good job!
Thanks!
What languages did you come to rust from?
Python… you can guess by my shitty code
i read through the code, and i have some tips, which you may find helpful (or not):
--coloris not the first argument, it will try to open a file named--color, which i assume is unintended. i would suggest checking out theclapcrate to easily parse argsimage.resize()is easier.len()on a string returns length in bytes, not characters, so could break with non-ascii text. in the context of this program, the text will always be ascii, so it is of course not a problem, but it’s worth to keep in mind. to get character length, use.chars().count()get_brightness_of_cluster, pushing to aVecand then calling.sum()can be replaced with a loop which increments a mutableu32variable. this is a nitpick, but it can avoid unnecessary memory allocationcheck out this example. sorry if this comes off as rude or a nitpick, i’m just trying to provide some advice :)
Thank you for your help this is not rude at all and very helpfull! I know about argument parsing with clap, and started thinking about it as I started to add more functional to the program
Is resizing and image is more performant? I yes then i was wrong when coding with clusters, it’s always good to have another viewpoint for tasks like this I didn’t even think of resizing an image)
About .len i think it’s fine as long as it works
The width of images should be resized depending on your terminal width and height, im still not sure how i can improve it, because every image is unique
get_brightness is a bit broken in performance right now, i will fix it later
Thanks you for your tips, really helpfull! Дякую!
:) no problem! i would assume resizing the image might be a little slower, because it creates a clone of the image, but if you use FilterType::NearestNeighbor, the speed is negligable in my opinion
Took 4 months to what? Download this image?
yes.
Very cool! Did you consider any other interpolation algorithms?
What is interpolation?
Its the mathematical term for estimation and constructing new data from existing data. In the context of what you are doing, it’s resizing images.
You are doing something called linear interpolation. This works great for shrinking an image. However, have you considered what happens when your ASCII resolution is greater than your image resolution? This is where bilinear and bicubic interpolation come in.
These algorithms are cool but are also massive overkill for your average use case. They only make a different in a very niche use case (when your ASCII resolution is greater than your image, such as pixelart)
Great code! Very cool
thank you so much! have a good day!