Why store images in a database if you can store a database in an image?
Find a file
2025-12-27 00:41:41 +01:00
LICENSE init 2025-12-27 00:39:09 +01:00
README.md add concept 2025-12-27 00:41:41 +01:00

ImageDB

Disclaimer: Until this notice disappears everything here (even the code) should be considered confused rambling.

What

idfk 💀

How

This type uses lots of markers to define where keys and values are stored. (Or only the scheme itself? lets see)

The header needs to have the following information: magic byte (imagedb) + version (for known header fields) + address size (+ checksum?) (+ free address map?)

Each database has header + scheme + map + data

Each pixel is considered a node/datapoint. There is different kinds of nodes: addresses, datapoints (raw) and datapoints delimited by markers

Objects/Tables are basically arrays of adresses to names in the map. (+ datatype?)

Adresses may have different lengths (which determine the max size of the database, changing this requires rewriting the whole database).

Adresses may be reused for deduplication. Even the scheme + map may reuse adresses as long as their fields are expected to be adresses.

Adresses point to individual pixels in the image.

Key-Value-Map

  • key: address to name of key
  • value: address to value for key

A storage strategy similar to sqlite may be implemented (free storage doesnt make the db smaller, vacuuming is required)

Async read access is easily possible, async write access requires rescanning the scheme + map.

Locking may be used to prevent other processes from accessing the database.

Algorithms for data distributions may be implemented to generate specific patterns i.e. to imitate actual images.

C will be used for this, codec will be png (-> libpng) without compression