Re: [Gimp-developer] Portable XCF

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I won't take any stand on either side (or how many sides are there?) in
the ongoing discussion, just air some fresh thoughts...

Many of the image formats suggested are some kind of archive formats
(zip, ar) on the outside.

I understand that one important benefit from this is that you can
store layers and whatnot objects as different "files" in the archive,
and easily access them separately. Even with other tools like ar or
unzip if need be.

However, these formats have the drawback that even if you can easily
have read access to just one of the component "files" in the archive,
it is impossible to rewrite a component if its size has changed (well,
at least if it has grown) without rewriting at least the rest of the
archive. (Or, maybe leaving the old version of the component as
garbage bits in the middle, appending the new version and updating the
index, if that is estimated to be less expensive than rewriting.)

Now, what concept do the ar, zip, etc formats closely resemble? What
other thingie is it that you store files in? Yeah, file systems.

Wouldn't it be neat to use a real file system inside the image
file... I.e. the image file would be a self-contained file system,
with the image components (layers, XML files, whatnot) as files.

What file system would be good? I don't know. Presumably something as
small and simple as possible, but not any simpler. Maybe FAT? ;-)
Early V6 Unix style file system (but with longer file names)? Minix?
Or something completely different? ISO9960 (I have no knowledge of
this, it might be way too complex)? UDF?

Does this make any sense?

Yeah, I can think of some drawbacks: For instance, there would have to
be some code to defragment and/or compact the file system image files
when needed (if the amount of data in the file system has radically
decreased, it should be compacted, for instance). Another is that if
the blocks of a layer are scatered here and there, reading it might be
slow than from traditional image file formats, where the data is
contiguous in the image file.

One neat benefit would be that on some operating systems it would be
possible to actually mount the image file as a file system...

--tml

[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux