4 ms·

Why the use of two different random number generators and drawing these images one pixel at a time? Why not swap the entire image colorspace to black/white for

Why the use of two different random number generators and drawing these images one pixel at a time? Why not swap the entire image colorspace to black/white for black/white? Why the choice of using imageio to create the gif when Pillow (imported at the beginning) can already do that as well? These are questions that are discussable, maybe the author isn't yet very familiar with generating images :)

nightcracker 8y ago
I like the part where the author calls numpy.random.uniform(low=0.0, high=1.0, size=None), explicitly passing size=None. They have the parameter that they want to immediately generate the entire image in one shot, and proceed to ignore it to generate the image pixel by pixel.
minimaxir 8y ago
> Why the choice of using imageio to create the gif when Pillow (imported at the beginning) can already do that as well? Can Pillow generate GIFs from numpy matrices? I had a similar design decision and it seems like Pillow wanted PIL.Image only. I also went with imageio because it uses the rectangle trick to cut down on filesize. (not relevant if the image is 100% noise however)
- deleted 8y ago
  [deleted]
- yorwba 8y ago
  The last time I used Pillow to create GIFs [1], I also noticed that the files aren't exactly small. But instead of using a different library, I simply optimized the generated GIFs using gifsicle [2]. [1] https://github.com/Yorwba/kanjivg-gif https://github.com/Yorwba/kanjivg-gif [2] https://www.lcdf.org/gifsicle/ https://www.lcdf.org/gifsicle/
- dr_zoidberg 8y ago
  I abandoned PIL/Pillow a couple of years ago for OpenCV (a lot faster, and loads 16/32 bit int/float TIFs without problems), but I remember there were a couple of "utility functions" whose job was to translate from PIL.Image into a numpy.ndarray and back. I guess you'd convert every frame from the corresponding ndarray, and then save them into a list to build the GIF in memory.

nightcracker 8y ago

I like the part where the author calls numpy.random.uniform(low=0.0, high=1.0, size=None), explicitly passing size=None. They have the parameter that they want to immediately generate the entire image in one shot, and proceed to ignore it to generate the image pixel by pixel.

minimaxir 8y ago

> Why the choice of using imageio to create the gif when Pillow (imported at the beginning) can already do that as well? Can Pillow generate GIFs from numpy matrices? I had a similar design decision and it seems like Pillow wanted PIL.Image only. I also went with imageio because it uses the rectangle trick to cut down on filesize. (not relevant if the image is 100% noise however)

deleted 8y ago
[deleted]
yorwba 8y ago
The last time I used Pillow to create GIFs [1], I also noticed that the files aren't exactly small. But instead of using a different library, I simply optimized the generated GIFs using gifsicle [2]. [1] https://github.com/Yorwba/kanjivg-gif https://github.com/Yorwba/kanjivg-gif [2] https://www.lcdf.org/gifsicle/ https://www.lcdf.org/gifsicle/
dr_zoidberg 8y ago
I abandoned PIL/Pillow a couple of years ago for OpenCV (a lot faster, and loads 16/32 bit int/float TIFs without problems), but I remember there were a couple of "utility functions" whose job was to translate from PIL.Image into a numpy.ndarray and back. I guess you'd convert every frame from the corresponding ndarray, and then save them into a list to build the GIF in memory.