SQLar[1], see [2] for some reasoning around why a database is preferred over zipped XML. Though, I'd be fine with a DBM-style database too as we only need the key-value part of it.
the SQLite archive format (it's probably worth linking to the main documentation[1], instead of the very old experimental repository) may not really be a good fit for something like GIMP's native file format. (To be clear, "SQLite archives" are not special compared to any other database: it's just a well-defined schema for an sqlar table, which the sqlite3 command line tool is able to create, update, and extract using syntax like the tar command.)
That being said, SQLite would still be a good choice, especially as it's a format that's really intended to be modified in-place, and has good data integrity features (eg: keep WAL enabled so that mid-save crashes/shutdowns don't corrupt your file), neither of which are provided by Zip. You could even just run zlib on data (be it XML or what have you) if optimizing the on-disk size of the file is desirable.
The problem with using database blobs for load/save is that you usually need a full database client in the application. SQlite advertises that use case, but it is complete overkill. You never need to run any sort of complex SQL query on an image file format for instance. Using XML+ZIP in this day and age is also a strange decision, but at least that way the data is inspectable with unzip, a text editor and an image viewer (assuming they use a standard image format to store the raw pixel data).
> You never need to run any sort of complex SQL query on an image file format for instance.
Sure you will. Plenty of features that don't exist, or are implemented badly, because you can't easily do it.
Quick mental translation table: if you think "iterate over every ..." or a `for` loop, that's your SELECT query. If you think about `if` conditions, that's the parts that go after FROM clause.
In order to have any advantage from this, you would have the added complexity of splitting your file format into tables that can be queried in a useful manner. However, for an image file format, you most likely need to hold the entire definition in memory at all times anyway. Assuming that’s the case, doesn’t XPath get you there most of the way (assuming XML), with _way_ less complexity?
Image data is just binary blobs. You aren't splitting that into channel columns or anything. But an image file for an editor like Gimp isn't one image blob. It's dozens or hundreds of them - one or more per layer - along with tons of associated metadata at every level.
All that tends to fit sensible schemas and managing it is what SQLite shines at.
I don’t see how this addresses my point that zipped XML gives you the same thing, but simpler. I understand that a GIMP file is many images, so that makes a zip feel like a great fit to me. The only advantage I see for using a full-blown DB is ensuring consistency with references, which admittedly is a plus. But beyond that, what do you gain?
- Continuously parsing and writing and reparsing text, 90% of which is useless (that's the JSON/S-expressions vs XML argument)
- Forcing a diverse relational structure to fit a tree hierarchy, hand-writing all the logic that manages representation change - either explicitly, at serialization boundary, or implicitly, in every single access operation you're doing to refer to some data;
- Or worse, using an off-the-shelf, generic object/XML mapper, in which case you just compound the bloat even more.
SQLite is one of the single most battle-tested and ubiquitous piece of software in the history of mankind. Anything "simpler" you're going to pick up is much more likely to be buggy and broken, and will definitely be orders of magnitude slower.
SQLite is fast, but it won't be faster than a hot loop in C. Having the loop construct dictated by the file format seems bad. For images it seems more reasonable to have them in-memory, except for huge image edge cases.
Images are the red herring. Pixel data is best read in hot loops in C, but that would be stored as blobs in SQLite anyway.
It's all the metadata around the image that's interesting. Images have layers, dozens or hundreds of them (this literally scales with how good your software is at handling those - the faster, and more powerful layer UX is, the more they get used). Some are pixel layers, other are effect layers, text layers, vector layers. Layers have metadata - names, sizes, colors, tags, types, special effects, and a bunch of other stuff I don't know because I don't use that 80% of features of GIMP/Photoshop/Affinity.
Then you have document level metadata, UI-specific metadata, etc. Also undo history. A lot of that is relevant to the work on images themselves, and changes in realtime, and can get even more useful if querying it wasn't such a PITA.
That - not the binary pixel blobs - is the selling case of using SQLite as application data format.
Think of Lightroom or automation over files. Many semi professionals from wedding photographers to designers want some form of batch automation and organization system over their files.
Several megabytes/gigabytes assets and you want to extract metadata, a preview, running as a batch some filter/compression/, conversion to CMYK, text injection ... fast partial read/write access would be nice.
Right now, most reads are performed through indexes because those files are slow to read.
If we take 10k sqlite files and want to retrieve a row, we would be around 3s on SSD, maintaining preemptive indexes become less important for a lot of use cases.
Change management and versioning also becomes quite efficient - sqlite can be configured to not offset bytes, so CVS like Epic Lore can efficiently delta the files and store minimal delta, or the file format itself can keep its edit history. Oh and it's 3x-10x less bytes without compressing the whole thing, so pages are stable through time.
About needing SQLite client, it's real but it's roughly the same size as an XML parser.
> About needing SQLite client, it's real but it's roughly the same size as an XML parser.
what I like about it being XML is I can just open it with any text tool and inspect it. It's human readable so I can edit and debug it manually, no need to have a parser or an extra application just to see what's in my file
Sqlite is probably overkill, you will probably never have actual relational data in an image format, But what it does bring to the table is a built in b-tree based storage, that is, you don't need to load the entire file into memory to edit it, in a prior age we would use Berkeley db for this. Sqlite in this role(a file format) is probably best thought of as a better superset of the berkleydb style key value store, more than one table per file and additional columns/indexes to keep metadata in.
Nothing wrong with XML, it is well understood, and the tooling is pretty good. But partial loads/edits is one thing it can not do.
To answer seriously, my parent comment is a joke, JSON is a simpler format that maps better to most programming languages internal memory representations. Developers tend to prefer JSON’s simplicity over XML.
> most programming languages internal memory representations
Often heard wrt JSON but incorrect. It maps to the primitive types in JavaScript. But almost all programming languages treat floats and integers different, make distinction between char and strings and many have some form of date/time. JSON has neither.
In that direction, XML is much closer since every node is a triple (name, value, attributes) so can have type info, json is a tuple. And Protobuf, while not popular, gets this completely right.
I think it's too risky to treat numbers in JSON as something else than IEEE754 64bits floats. But yes, JSON is small and doesn't do datetimes, char, comments, and a million other things XML does.
But you don't need to think much about memory representation when you parse a JSON, and the developer experience is a lot more pleasing than browsing a XML tree. That what used to matter.
Yes, this is not too rare to see base64 images in JSON but I won't recommend that.
You gain back most of the base64 overhead when you compress it though. It's slower but probably often worth it if the alternative is few more async HTTP queries that you would only fetch once.
SQLar[1], see [2] for some reasoning around why a database is preferred over zipped XML. Though, I'd be fine with a DBM-style database too as we only need the key-value part of it.
[1] https://sqlite.org/sqlar/doc/trunk/README.md
[2] https://www.sqlite.org/affcase1.html
the SQLite archive format (it's probably worth linking to the main documentation[1], instead of the very old experimental repository) may not really be a good fit for something like GIMP's native file format. (To be clear, "SQLite archives" are not special compared to any other database: it's just a well-defined schema for an sqlar table, which the sqlite3 command line tool is able to create, update, and extract using syntax like the tar command.)
That being said, SQLite would still be a good choice, especially as it's a format that's really intended to be modified in-place, and has good data integrity features (eg: keep WAL enabled so that mid-save crashes/shutdowns don't corrupt your file), neither of which are provided by Zip. You could even just run zlib on data (be it XML or what have you) if optimizing the on-disk size of the file is desirable.
[1] https://sqlite.org/cli.html#sqlite_archive_support
Isn't the implementation the spec for SQLite?
Not really a great option for an image format, where we therefore can't have multiple implementations. Unless I misremembered.
SQLite file format spec: <https://sqlite.org/fileformat.html>
Thank you for the prompt clarification!
The problem with using database blobs for load/save is that you usually need a full database client in the application. SQlite advertises that use case, but it is complete overkill. You never need to run any sort of complex SQL query on an image file format for instance. Using XML+ZIP in this day and age is also a strange decision, but at least that way the data is inspectable with unzip, a text editor and an image viewer (assuming they use a standard image format to store the raw pixel data).
> You never need to run any sort of complex SQL query on an image file format for instance.
Sure you will. Plenty of features that don't exist, or are implemented badly, because you can't easily do it.
Quick mental translation table: if you think "iterate over every ..." or a `for` loop, that's your SELECT query. If you think about `if` conditions, that's the parts that go after FROM clause.
In order to have any advantage from this, you would have the added complexity of splitting your file format into tables that can be queried in a useful manner. However, for an image file format, you most likely need to hold the entire definition in memory at all times anyway. Assuming that’s the case, doesn’t XPath get you there most of the way (assuming XML), with _way_ less complexity?
Image data is just binary blobs. You aren't splitting that into channel columns or anything. But an image file for an editor like Gimp isn't one image blob. It's dozens or hundreds of them - one or more per layer - along with tons of associated metadata at every level.
All that tends to fit sensible schemas and managing it is what SQLite shines at.
I don’t see how this addresses my point that zipped XML gives you the same thing, but simpler. I understand that a GIMP file is many images, so that makes a zip feel like a great fit to me. The only advantage I see for using a full-blown DB is ensuring consistency with references, which admittedly is a plus. But beyond that, what do you gain?
You're not:
- Continuously parsing and writing and reparsing text, 90% of which is useless (that's the JSON/S-expressions vs XML argument)
- Forcing a diverse relational structure to fit a tree hierarchy, hand-writing all the logic that manages representation change - either explicitly, at serialization boundary, or implicitly, in every single access operation you're doing to refer to some data;
- Or worse, using an off-the-shelf, generic object/XML mapper, in which case you just compound the bloat even more.
SQLite is one of the single most battle-tested and ubiquitous piece of software in the history of mankind. Anything "simpler" you're going to pick up is much more likely to be buggy and broken, and will definitely be orders of magnitude slower.
SQLite is fast, but it won't be faster than a hot loop in C. Having the loop construct dictated by the file format seems bad. For images it seems more reasonable to have them in-memory, except for huge image edge cases.
Images are the red herring. Pixel data is best read in hot loops in C, but that would be stored as blobs in SQLite anyway.
It's all the metadata around the image that's interesting. Images have layers, dozens or hundreds of them (this literally scales with how good your software is at handling those - the faster, and more powerful layer UX is, the more they get used). Some are pixel layers, other are effect layers, text layers, vector layers. Layers have metadata - names, sizes, colors, tags, types, special effects, and a bunch of other stuff I don't know because I don't use that 80% of features of GIMP/Photoshop/Affinity.
Then you have document level metadata, UI-specific metadata, etc. Also undo history. A lot of that is relevant to the work on images themselves, and changes in realtime, and can get even more useful if querying it wasn't such a PITA.
That - not the binary pixel blobs - is the selling case of using SQLite as application data format.
Think of Lightroom or automation over files. Many semi professionals from wedding photographers to designers want some form of batch automation and organization system over their files.
Several megabytes/gigabytes assets and you want to extract metadata, a preview, running as a batch some filter/compression/, conversion to CMYK, text injection ... fast partial read/write access would be nice. Right now, most reads are performed through indexes because those files are slow to read.
If we take 10k sqlite files and want to retrieve a row, we would be around 3s on SSD, maintaining preemptive indexes become less important for a lot of use cases.
Change management and versioning also becomes quite efficient - sqlite can be configured to not offset bytes, so CVS like Epic Lore can efficiently delta the files and store minimal delta, or the file format itself can keep its edit history. Oh and it's 3x-10x less bytes without compressing the whole thing, so pages are stable through time.
About needing SQLite client, it's real but it's roughly the same size as an XML parser.
> About needing SQLite client, it's real but it's roughly the same size as an XML parser.
what I like about it being XML is I can just open it with any text tool and inspect it. It's human readable so I can edit and debug it manually, no need to have a parser or an extra application just to see what's in my file
> Using XML+ZIP in this day and age is also a strange decision
I agree with you that SQlite is overkill but honestly curious to know why you think xml+zip is strange? what would you use instead?
Sqlite is probably overkill, you will probably never have actual relational data in an image format, But what it does bring to the table is a built in b-tree based storage, that is, you don't need to load the entire file into memory to edit it, in a prior age we would use Berkeley db for this. Sqlite in this role(a file format) is probably best thought of as a better superset of the berkleydb style key value store, more than one table per file and additional columns/indexes to keep metadata in.
Nothing wrong with XML, it is well understood, and the tooling is pretty good. But partial loads/edits is one thing it can not do.
Compressed JSON with the binary content encoded in base64 strings, obviously.
Why would zipped JSON be fundamentally superior to zipped XML?
To answer seriously, my parent comment is a joke, JSON is a simpler format that maps better to most programming languages internal memory representations. Developers tend to prefer JSON’s simplicity over XML.
> most programming languages internal memory representations
Often heard wrt JSON but incorrect. It maps to the primitive types in JavaScript. But almost all programming languages treat floats and integers different, make distinction between char and strings and many have some form of date/time. JSON has neither.
In that direction, XML is much closer since every node is a triple (name, value, attributes) so can have type info, json is a tuple. And Protobuf, while not popular, gets this completely right.
I think it's too risky to treat numbers in JSON as something else than IEEE754 64bits floats. But yes, JSON is small and doesn't do datetimes, char, comments, and a million other things XML does.
But you don't need to think much about memory representation when you parse a JSON, and the developer experience is a lot more pleasing than browsing a XML tree. That what used to matter.
So you compress a format that inflates binaries with 30%?
That not only ends up larger than "just the binary", it also eats a lot of extra CPU to (de)compress AND encode-decode.
This idea is novel, but wasteful.
(edit: I thought you were serious, so I answered serious. You were not ;)
Yes, this is not too rare to see base64 images in JSON but I won't recommend that.
You gain back most of the base64 overhead when you compress it though. It's slower but probably often worth it if the alternative is few more async HTTP queries that you would only fetch once.