Also realized I may be able to build a bot out of this idea, using indexes of things like "the animated hobbit movie" or "Star Trek the animated series" where someone could tag a bot with an image and a request like "hobbitize".

Ok, maybe not ... but I did finish the actual searchable index construction so now I just need to add the bit to the UI that breaks up the selected image into chunks and then feed them through the search to get bike the tiles to draw the thing.
So ... 🤏🏻

@dev.shitpost.world fix your shit

Oh right that doesn’t go anywhere yet.

>_>
<_<

Got distracted by other things and planning ahead so no new outputs today :/

Should be able to have it generate actual output tomorrow though.

Also maybe I can turn it into a bot on @ shitpost.world where people can send it an image and it’ll make a mosaic out of like, the Hobbit or Star Trek.

Who needs parallel CPU code when you can serialize it to the GPU in like 1/8th the time?

I think I like this better than python's "return foo if bar else baz" ternary structure.

It's not perfect. (I wrote an init for LABColor with a generic for BinaryInteger so it doesn't need to cast the RGB values to Int8 here)

Actually this was three or four successive tab completes starting with everything after "granularity:" (I'm going to default it to 5 so it doesn't do 16M checks)

Ok, so WTF am I actually going to do today?

1. go look at the indexer code and re-internalize how it all works.
2. figure out how to build the coordinator I mentioned above to delegate image types to sub indexers
3. build the sub indexers
4. maybe add UI elements to control these

When writing the sheets to local storage, I take a two tiered approach. Any sheet that is not full (has all 16 rows, all rows are full) is stored as a TIFF (lossless compression) so it can be appended to without generational loss.

Completed sheets are saved as HEIC, which is fine for tiles.

With the image sheets I can load however many I can fit into main memory. Since they're immutable when running the generation task, there are no concerns about concurrency because order of operations is irrelevant, thus no overhead for keeping track of what's accessing what.

Ok, but why store the sheets at all? Why not just read from the local thumbnail store when you're doing the index?

This would work, it would save some overhead and space on the index side, but pulling the individual thumbnails out while *drawing* the resulting image has more overhead.

They each build their own sub-index and then when they're all ready I can build a merged index on the fly as the user makes changes to what media types they allow.

Currently I just completely exclude Hidden images but this could allow the user to opt-in to including them.
(Would not pre-index them)

So I think my new approach will be to have an index coordinator that figures out what each incoming image type is, and hands it off to a separate indexer per relevant type. This would allow me to potentially do things like "use all frames of an animated GIF/Live Photo/etc".

Some people might have larger libraries. You could just use a 64 bit int and have 35 bits left over to store 35 billion sheets and 10 trillion total images but that would bring additional storage complications that are beyond the scope of this project.

I just store a sheet ID separately.

You also need to store which sheet it's in, but with a typical image size of 114x64 (16:9 frame) or 86x64 (4:3) you can fit ~18 to ~24 source images per strip (call it 20) and 16 strips per sheet so 320 per sheet. With a photo library of 20,000 images that's 63 sheets, which would give you 35 bits.