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

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

 



From: Leonard Rosenthol <leonardr@xxxxxxxxxxxxx>
To: Nathan Carl Summers <rock@xxxxxxxx>
CC: The Gimp Developers' list <gimp-developer@xxxxxxxxxxxxxxxx>
Subject: Re: [Gimp-developer] GimpCon RFC: Portable XCF
Date: Wed, 20 Aug 2003 10:40:51 -0400

At 8:45 AM -0700 8/12/03, Nathan Carl Summers wrote:
> 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.

Correct.


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

Well, it needs to be a directory of some sort - whether it is TIFF-like, XML-based, ZIP-like, whatever..



I think the goal of the XCF redesign is to become the de-facto standard
for interchange of layered images.

Unless you get Adobe to adopt support for it in their applications - that simply won't happen! Whether you like it or not, Adobe is the standards bearer in this regard, followed by the other major commercial players - Corel, Jasc, etc.

well, it'd be interesting to see if Adobe added XCF to Photo$hop, after all, GIMP is the competition, it wouldn't be in their interests to support a multilayered image format that it controlled by someone else(although they might support PSP, i don't know haven't checked.)


it would be good if Jasc and Corel were to pick it up as a standard interchange format, that would put Adobe under some pressure at least.

And that is also part of my suggestion for using a pre-existing format like TIFF or PSD. There is always wide support for them...

but that means you'd have to leave out any new improvements to GIMP layer handling that are made, otherwise you'd be breaking compatibility with the "standard"(yes, that is a joke), PSD is only fully supported really by adobe, if we're going to have a standard file format that's simply a broken version of PSD5 i don't see much point.


as for TIFF, you wouldn't be able to do it in a standard readable TIFF, you'd need to update the format entirely, or simply break it, which, again, defeats the object.


In other words, any XCF
reader should be able to read any XCF writer's output.

A reasonable requirement, to an extent. Do we expect that every XCF reader support ALL features of XCF?

i wouldn't expect them to, some would only want to produce a thumbnail, as with Nautilus, but i guess the standard decoder could provide a way of doing that anyway.



A layered TIFF by that name wouldn't cut it, because most tiff readers don't support layered images.

Sure they do! Well, at least for any program that supports multiple layers/pages to begin with. And this goes to the question above...

can you post a multilayer TIFF somewhere for me to try out, i've never encountered one before, and it would be interesting to see how it's handled.


If my application doesn't support a particular feature of XCF, am I not compliant? Should I not bother doing XCF?

it'd be nice if your app could read and render a flat version of the image if you don't support layers i supose, this is an interesting one since all these different target apps will handle things like layermodes differently, and some wouldn't even be supported.



Of course, we could always use TIFF internally but call it XCF.

We could do that.

Adobe does that with .ai, which is really .pdf...

i thought it was a kind of encapsulated post script


We might want to change the magic number as well.

Wouldn't do that, since the whole idea is to maintain compatibility...

no, that simply wouldn't be flexible enough, surely, i mean you could have extra data about how do use the layers in the TIFF but if those aren't recognised by other readers you just get a strange result and a confused decoder.



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.

I agree, though I think we can add all of these through additional tags and not having to redesign...

i'm sure it's fine for a basis, but not to keep compatible with the existing TIFF format.



/me wonders if the CinePaint people have any thoughts...


Definitely!

hmmm, yes, would be interesting, but they're sticking with their current tree aren't they, they wont make the eventual move to GEGL, and i thought this discussion was about the XCF version designed for it.


Phil.


Leonard
--
---------------------------------------------------------------------------
Leonard Rosenthol <mailto:leonardr@xxxxxxxxxxxxx>
<http://www.lazerware.com>
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

_________________________________________________________________
Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger



[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