Recent searches
Search options
There are a number of rust crates that seem to make it easy to create valid JPEGs (or PNGs). The question is, what should they contain, and is the generation fast enough?
Or, perhaps another approach: what if SVG, but partially built by a markov generator? Can I make that valid? Is it something the scrapers would even care about? Or should I stick to playing with jpeg & png?
The image crate looks like a simple way to create PNGs and JPEGs.
Question remains: what shall be the content? I suppose, the easiest is to make it user-controlled, somewhat. Provide a few template helpers that can insert various types of images at certain points.
Like, there'd be purely random, slightly randomized mandelbrot or julia fractals, and so on.
I have a ton of other ideas, but... this'll do for starters. Still need to do some benchmarking, to make sure this is even viable.
Ideally, the images would be trainable too... but that's beyond my expertise. It would also require a lot of images to train on, and that's much more expensive than training on text.
So sticking with untrained, but procedurally generated or random images is the way to go for now, assuming the performance hit is acceptable.
@algernon I think the key is keeping the resource use down, I'm most interested in iocaine to save resources, and if generating images uses too much resources, we're better off sticking with text.
@skyfaller Yep, agreed. If I add image generation, it will be entirely optional, and off by default.
@algernon @skyfaller This is why I went with "not quite jpeg" generation.
On my laptop, with FakeJPEG, I can generate around 8,500 1280x1024 "fake" jpegs per second. That's in pure Python.
Using the PIL library (where the compressor is compiled C), I can only generate about 400 per second.
Creating a JPEG is a fairly CPU-heavy operation.
@pengfold @skyfaller Ooof.
Just did a quick test with the image crate, to create 1280x1024 jpeg of pure randomness, and it was going at 10 / sec. Generating a PNG is much faster (~100 / sec), and I suppose I could make it faster if I disabled compression.
Though, the bottleneck in this case is not just the png/jpeg compression, but the generation is costly too. Would need considerably smaller images, or faster (less naive) image generation in the first place for this to be viable.
I guess I'm not generating images just yet!