Re: [Gimp-developer] GimpCon RFC: Portable XCF

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

 



At 4:37 PM -0700 8/9/03, Nathan Carl Summers wrote:
 >	Trees, yes - for things like layers.   But why a graph??

GEGL supports graphs.  If we use GEGL graphs, we'll need a representation
;)

Ah...

I haven't seen/used GEGL - just keep hearing about it here on the list as the new "imaging engine".


I see fast loads as an absolute requirement.

Then we need to also look at the GIMP itself and what can be done there.



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.


 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.




> * 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.



> 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.

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).


LDR -- --------------------------------------------------------------------------- Leonard Rosenthol <mailto:leonardr@xxxxxxxxxxxxx> <http://www.lazerware.com>

[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