@@GenerativeGarden It looks like it’s been a year since you last posted a video, but I’m leaving my notifications on for your channel just in case you do still have some tricks up your sleeve 👀 I’m excited to see what else I can learn from any future videos of yours 👌
Glad you liked it! And thanks for the tip. I don't know anything about Hungarian but I tried to pronounce it as well as I could, but I guess I missed something 😅
I wrote (basically) this program independently a summer or two ago and have been calling it watercolors. I've been looking for the video that inspired it since then, a sort of similair version in 3D where each voxl is colored based on its neighbors. Randomly tonight I saw this video and instantly recognized it. I've never seen the name Rainbow Smoke before but at last I have an actual name!! P.S. Using an image as a color space is super cool, I've never thought of doing that!
would you mind answering a question of mine regarding this algorithm? in the video it is said, that the algorithm picks a random pixel which is adjacent to one that has already been filled in. so first I guess you need to keep track of which pixel has already been filled in. the main thing that I don't understand is what the algorithm does, if it picks a filled pixel that has four adjacent pixels to it that are also filled in. does it just try the next filled pixel then? I guess that would be highly inefficient, the bigger the already filled in area gets
@@christophseibel1765 The algorithm I wrote varied ever so slightly I think, but what I did was have each spot on screen (pixel) also have two booleans, one for if it was filled, and one for if it was next in line to be filled. The steps were: 1. if it's next-in-line, calculate its color based on its filled neighbors. While doing so, set any unfilled neighbors as next-in-line. 2. Fill the pixel with the appropriate calculated color, set its filled boolean to true, and its next-in-line boolean to false. 3. rinse and repeat. (I also set up a probability variable so if it was next-in-line to be filled it wasn't guaranteed to fill every round.) Another thing (essentially the same) you could try is keep some sort of list of the unfilled neighbors and every time you fill a pixel, remove it from the list but add its unfilled neighbors to the front or back of the list depending on how you want the algorithm to look. I'd also recommend looking into breadth-first-searches and dpeth-first-searches on trees as the idea is somewhat related. My algorithm does in fact slow down over time though yes, as each frame there's more pixels to fill than there were previously, as a rule of thumb. It's not that bad though.
Looking at the video more carefully, if you wanted to replicate it exactly here's what I'd do: Keep a list of all the unfilled neighbors. Every time you fill one remove it, and add its unfilled neighbors if they aren't in the list already. Then, each frame, pick randomly (not first or last, my mistake) from the list, and proceed with the coloring stuff.
I'm having trouble understanding how to convert an image to color space. Do you treat each pixel of input image as single color and ignore duplicates? In video output from "Mona Lisa" appeared to be much larger in scale and squarish, if it's pretty much same as rearranging pixels, how is that possible? Also what's the method/approach for finding "similar" color from color space? Do you compare each individual channel (R, G, B) of each pixel in color space?
If you want to use an image as a color space, you basically assign pairs of image coordinates to each pixel in your smoke grid, and then fill the pixels in with the color at the assigned coordinates in the original image. So in that case you don't really compare the colors directly, you just compare pairs of coordinates. Similarity is measured in terms of euclidean distance - when choosing which value to assign to a pixel, you pick the one that minimizes the distance to the values assigned to its neighbor(s). If you're doing the classic "rainbow" smoke algorithm then you measure the distance between rgb vectors, i.e. sqrt((r1-r2)^2 + (g1-g2)^2 + (b1-b2)^2), but if you're using an image as a color space you measure the distance between pairs of coordinates, i.e. sqrt((x1-x2)^2 + (y1-y2)^2). Checking all of the distances individually to find the nearest neighbor can be slow, but you can speed it up by using a quadtree or octree. You're right that the output for the mona lisa that I showed was larger than the original, and that you can't really achieve that if you're just rearranging the pixels. If you were just re-arranging the pixels you'd start out with a population of coordinate pairs containing exactly one pair for each pixel in the original image. But if you want to create something that isn't exactly the same size as your source image, you can instead start with a population of any arbitrary size, where each coordinate pair is just a random point inside the original image. This means that there's no guarantee that all of the pixels in the original image will be exactly once - some will get used more than once, and some, depending on your implementation, might not get used at all. With this approach you're not quite literally "rearranging the pixels" of the original image, but the results look pretty much the same, and it means you don't have to worry about sticking to the same resolution as the original image.
Not sure if you're still online but your videos are really well made and high quality. Also are there any ways to optimize this algorithm? I tried it and it takes a few hours to generate a full screen for me. I'm doing this in javascript btw so that's why its performance might be low.
Awesome video, really well made. Do you know how I can find the person who made the music for this video? I think the musician might have changed their name.
This person created a channel, dropped three masterpieces, and left.. and nobody knows about it? this is an injustice, but it was a great series :)
Thank you for the kind words :D
I've been quiet for a while but don't worry, I haven't left entirely. There will be more to come, so stay tuned!
@@GenerativeGarden It looks like it’s been a year since you last posted a video, but I’m leaving my notifications on for your channel just in case you do still have some tricks up your sleeve 👀 I’m excited to see what else I can learn from any future videos of yours 👌
Just found this channel - really hoping you come back soon with some more videos :)@@GenerativeGarden
Beautiful explanation. What a ride!
Well, done. This series feels like a Generative Art version of 3Blue1Brown. Hope more of these are made.
Very well presented. The algorithm reminds me of the basic concept behind 12 tone music, but applied to a visual space
That's a really interesting connection, I never thought about that!
@@GenerativeGarden why dont you make any videos anymore?
This channel is great! Wish there was more
WOWW! This is amazing! This video is amazing! You are amazing! This is just so good... Keep up the great work!
Amazing content, really great work. Looking forward to more!
Amazing. Can't wait for more videos to be uploaded.
Fantastic explanation. And the graphics, especially the 64 colors was spot on. I hope you make many many more videos! Wishing you the very best.
Love this!!!! I did not know what I want until I found your video!! Such a great content and explanation!! Thank you so much!!!
Your videos are incredible. Looking forward to more.
Amazing, didn't know about it.
Love the final sneak peek :) and very interesting results!
Amazing! Thank you for uploading
This video is awesome. Can't wait for your next one
Fascinating video! I love how you explain things
Please make more videos, these are great!!
Awesome. Thanks. I love your style to explain.
Fantastic video. Thanks for the explanation!
Awesome! Also FYI, in Hungarian, the zs (as in József) is pronounced like the g in genre.
But seriously, this is insanely good
Glad you liked it!
And thanks for the tip. I don't know anything about Hungarian but I tried to pronounce it as well as I could, but I guess I missed something 😅
@@GenerativeGarden Oh its alright, don't worry about it. I didn't mean to sound rude or anything..
Masterpiece!
Awesome videos. Thank you for these
incredibly clear and interesting! Subscribed.
I wrote (basically) this program independently a summer or two ago and have been calling it watercolors. I've been looking for the video that inspired it since then, a sort of similair version in 3D where each voxl is colored based on its neighbors. Randomly tonight I saw this video and instantly recognized it. I've never seen the name Rainbow Smoke before but at last I have an actual name!!
P.S. Using an image as a color space is super cool, I've never thought of doing that!
would you mind answering a question of mine regarding this algorithm? in the video it is said, that the algorithm picks a random pixel which is adjacent to one that has already been filled in. so first I guess you need to keep track of which pixel has already been filled in. the main thing that I don't understand is what the algorithm does, if it picks a filled pixel that has four adjacent pixels to it that are also filled in. does it just try the next filled pixel then? I guess that would be highly inefficient, the bigger the already filled in area gets
@@christophseibel1765 The algorithm I wrote varied ever so slightly I think, but what I did was have each spot on screen (pixel) also have two booleans, one for if it was filled, and one for if it was next in line to be filled.
The steps were:
1. if it's next-in-line, calculate its color based on its filled neighbors. While doing so, set any unfilled neighbors as next-in-line.
2. Fill the pixel with the appropriate calculated color, set its filled boolean to true, and its next-in-line boolean to false.
3. rinse and repeat.
(I also set up a probability variable so if it was next-in-line to be filled it wasn't guaranteed to fill every round.)
Another thing (essentially the same) you could try is keep some sort of list of the unfilled neighbors and every time you fill a pixel, remove it from the list but add its unfilled neighbors to the front or back of the list depending on how you want the algorithm to look. I'd also recommend looking into breadth-first-searches and dpeth-first-searches on trees as the idea is somewhat related.
My algorithm does in fact slow down over time though yes, as each frame there's more pixels to fill than there were previously, as a rule of thumb. It's not that bad though.
Looking at the video more carefully, if you wanted to replicate it exactly here's what I'd do:
Keep a list of all the unfilled neighbors. Every time you fill one remove it, and add its unfilled neighbors if they aren't in the list already. Then, each frame, pick randomly (not first or last, my mistake) from the list, and proceed with the coloring stuff.
More please
Mesmerizing!
wow, cool!
Amazing stuff
How can I learn how to do these cool things?
I'm having trouble understanding how to convert an image to color space. Do you treat each pixel of input image as single color and ignore duplicates?
In video output from "Mona Lisa" appeared to be much larger in scale and squarish, if it's pretty much same as rearranging pixels, how is that possible?
Also what's the method/approach for finding "similar" color from color space? Do you compare each individual channel (R, G, B) of each pixel in color space?
If you want to use an image as a color space, you basically assign pairs of image coordinates to each pixel in your smoke grid, and then fill the pixels in with the color at the assigned coordinates in the original image. So in that case you don't really compare the colors directly, you just compare pairs of coordinates.
Similarity is measured in terms of euclidean distance - when choosing which value to assign to a pixel, you pick the one that minimizes the distance to the values assigned to its neighbor(s). If you're doing the classic "rainbow" smoke algorithm then you measure the distance between rgb vectors, i.e. sqrt((r1-r2)^2 + (g1-g2)^2 + (b1-b2)^2), but if you're using an image as a color space you measure the distance between pairs of coordinates, i.e. sqrt((x1-x2)^2 + (y1-y2)^2). Checking all of the distances individually to find the nearest neighbor can be slow, but you can speed it up by using a quadtree or octree.
You're right that the output for the mona lisa that I showed was larger than the original, and that you can't really achieve that if you're just rearranging the pixels. If you were just re-arranging the pixels you'd start out with a population of coordinate pairs containing exactly one pair for each pixel in the original image. But if you want to create something that isn't exactly the same size as your source image, you can instead start with a population of any arbitrary size, where each coordinate pair is just a random point inside the original image. This means that there's no guarantee that all of the pixels in the original image will be exactly once - some will get used more than once, and some, depending on your implementation, might not get used at all. With this approach you're not quite literally "rearranging the pixels" of the original image, but the results look pretty much the same, and it means you don't have to worry about sticking to the same resolution as the original image.
@@GenerativeGarden Thank you!
Are processing codes available? If so, where?
Not sure if you're still online but your videos are really well made and high quality. Also are there any ways to optimize this algorithm? I tried it and it takes a few hours to generate a full screen for me. I'm doing this in javascript btw so that's why its performance might be low.
Awesome video, really well made. Do you know how I can find the person who made the music for this video? I think the musician might have changed their name.
That's so cool, easy sub
Woooooaavvvv !!!! That’s hilarious. I need a tutorial 🤩🤩🤩
please, can you turn the background music volume down? It messes with your voice. And please, keep on making videos, they are just great.