On Sat, 9 Aug 2003, Leonard Rosenthol wrote: > >I see fast loads as an absolute requirement. > > Then we need to also look at the GIMP itself and what can be > done there. Of course. > >Hopefully, GIMP's file handling will improve to the point where it will > >load thing on an as-needed basis. Therefore, fast random access is > necessary. > > Having load on demand via random access is what will really > get you the fast loads!! If you don't solve that, then any work on > the file format will be a waste towards your goal. Exactly, it's a big priority. > > Being compact is nice as > >well, because not everyone has 3 terrabyte harddrives and a T3 line into > >their house. > > Agreed, but what does this really mean in "real world" terms. > Are we willing to sacrifice functionality to get a couple of bytes > here and there? The image data is the big hit in this format - the > structure will end up as a small fraction of any XCF file. We certainly shouldn't sacrifice high-priority stuff for size, but size should still be a consideration. > > > * incremental update > >> just update a single layer w/o rewriting the whole file! > > > >This seems like an excellent goal. It seems like you are suggesting a > >database-like format. > > Not necessarily. You should be able to do it with any format > with a good catalog system, but some will be easier than others. How would you handle resizes? Either we could do immediate compaction or garbage collection. Both have their disadvantages. > > > I think sub-chunks is a bad idea. Although a common way to > >> represent hierarchical relationship, they can also put overhead on > >> random access and also slow down read/write under certain conditions. > > > >How about a TIFF-like directory chunk at the beginning (except > >hierarchical)? > > That would be one solution - sure. Can you think of a better one? > I just think that doing a full "reinvent" of an image format > seems like a waste of time. Let's look at Photoshop... > > Photoshop is able to do 100% round-tripping of ALL of its > functionality in three formats - PSD, TIFF and PDF. PDF is done via > throwing their private info into an undocumented blob - so it doesn't > really count. So let's look at the other two. > > Both PSD and TIFF are rich image formats that already address > most of your original list and are well defined and supported by many > existing tools (including GIMP itself). Both are extensible (TIFF > more so) and would allow for additional blocks to meet our needs. > > Is there a good reason not to use either PSD or TIFF as the > native format? The only possible argument for either is that Adobe > controls them both. However, I would state that TIFF has pretty much > taken on a life of its own outside Adobe (via libtiff). I think the goal of the XCF redesign is to become the de-facto standard for interchange of layered images. Certainly one aspect of this is freedom from Adobe, but in addition to being an open standard, it needs to be a standard that people have confidence in. In other words, any XCF reader should be able to read any XCF writer's output. A layered TIFF by that name wouldn't cut it, because most tiff readers don't support layered images. Of course, we could always use TIFF internally but call it XCF. We might want to change the magic number as well. I have no problem with basing Portable XCF on TIFF. It seems to be well designed without really being too overdesigned. On the other hand, I think there are a few improvements that we could make to make it better for the purposes of GIMP. /me wonders if the CinePaint people have any thoughts... Rockwalrus
