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

[Carol Spears]

Leonard Rosenthol wrote:

At 3:33 PM -0400 8/14/03, Carol Spears wrote:

So this combination would answer your LAB & CMYK issues and possibly 
my need to use a greater than 256 color palette then?


No, it would not.

ICC profiling is a VERY different thing that actual "raw" CMYK or 
Lab data...

Paletizing of an image is also different...
Well, I don't understand the color issues that well.  Merely my own 
limitations with TheGIMP so far.



Complaints I remember reading from more "technically inclined" people 
about tiff were mostly about the lwz compression.  I guess while it 
was not free it was also not the best way to go about doing such a 
thing.


Yes, that was a legal issue, not a truly technical one. (LZW, not 
lwz).
Here is an example of my lazy brain working for me.  As soon as I read 
something that makes me think "expensive, selfish and substandard" (as 
this compression and those three letters make me think) my brain stops 
giving time and space to the idea.

My worst fear is that TheGIMP will settle for something that came from 
this sort of thought process and development cycle.

Eh, something like "spiritually unsound" is fine if we are getting the 
best thing.  I don't think we would be if we took this tiff route.

Does tiff have a comments area?  I use jpeg comment often and am anxious
to start using comments in pngs.  Rumor has it that the capability is 
there 




However, I read recently about artifacts appearing in compressed 
pngs, so this might not be the miracle fix I had hoped for.


PNG won't artifact images unless you are palettizing them, which 
is NOT the default.
This was someone bitching on the irc.  I don't know all of the details 
and I did not see the image.

I was without power for more than a day, I am hoping to read the rest
of the mail and see that we will be using mng as a base and redesigning
it some.  :)
carol



___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

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

[Leonard Rosenthol]

At 2:13 PM -0700 8/14/03, Manish Singh wrote:
 >	Never implemented a file format, have you ;).

What widely used formats have you implemented? :)
	Well, let's see...

	I'm responsible for the design & implementation of the 
StuffIt archive file format (.sit), MacBinary III, AppleSingle & 
AppleDouble, PGML (the predecessor to SVG) and the Adobe PhotoDeluxe 
Image Archiving System (which, by the way, uses XML and ZIP).

	I have also written readers and writers for XCF and PSD as 
part of my job as maintainer of the ImageMagick/GraphicsMagick 
library, PDF (3 different times), and during my work on the StuffIt 
product wrote the encoders and decoders for all the major archiving & 
encoding formats including Zip, Tar, Arc, Arj, UUcode, and BinHex. 
And I am sure there are others I am forgetting over my 20 years in 
this industry.

	OK???


ar supports random access and single file extraction just fine.
	I never said the format doesn't support it - I said that most 
libraries that work with such formats don't support that particular 
feature...BIG difference!!

	It is MUCH easier to write a reader/writer for a format when 
you treat it as a sequential entity and handle all contents of it - 
than if you have to deal with dynamic random access requests.

Leonard
--
---
Leonard Rosenthol
 
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

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

[Phil Harper]

From: Leonard Rosenthol <[EMAIL PROTECTED]>
To: Nathan Carl Summers <[EMAIL PROTECTED]>
CC: The Gimp Developers' list <[EMAIL PROTECTED]>
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:[EMAIL PROTECTED]>
 

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

[Manish Singh]

On Thu, Aug 21, 2003 at 01:38:01AM -0400, Leonard Rosenthol wrote:
> At 8:12 PM -0700 8/13/03, Manish Singh wrote:
> >On Wed, Aug 20, 2003 at 10:53:14PM -0400, Leonard Rosenthol wrote:
> > > At 6:51 PM -0700 8/13/03, Manish Singh wrote:
> >> >Does TIFF support, for example, float16 data, or a CIE XYZ colorspace?
> >>
> >>Yes to both...
> >
> >Hmm, got a reference to that? It wasn't immediately apparent in my reading
> >of the spec.
> 
>   See Section 19 for Floating point support in data.

Supports IEEE floats, but not float16 (a 32-bit float cut in half). R&H
added this to filmgimp since they had established this format in their
workflow with other tools already.

One of the goals of GEGL is to allow GIMP to be adapted to wacky formats
like these easily. TIFF only specs unsigned integer, signed integer, and
IEEE floats.

>   I forget the section, but a simple search of the TIFF6 spec 
> led to a number of references on CIE XYZ support.

Only CIE LAB is given an official type. It's a derivative of CIE XYZ, hence
the references to it, but they aren't completely the same thing.

GEGL uses XYZ as a native format.

> 
> >What's the turnaround time for that? Taking weeks or months isn't really
> >acceptable...
> 
>   It's there to make sure that people don't duplicate tags - so 
> as long as we pick pretty unique tags related to the GIMP, it's not a 
> problem.

It's not just the tags, but extending value ranges for tags (needed for
the two cases above). And a lag time means either waiting for an updated
spec, which is a holdup, or going ahead and running the risk it not being
granted because someone else tried to get their conflicting values in first. 
Also nonstandard implementations that may use previously unallocated values
or tags which we are trying to use.

> >Another thing I'm worried about is simply adding to the confusion of
> >"what is a tiff file". There are few tiff readers/writers that support
> >the entire feature set of tiff, and many broken implementations out there.
> 
>   True - but that's the case with EVERY SINGLE file format 
> (graphic, wp, etc.).  Only the original application for which the 
> format was created will usually support all features.   Not every 
> feature of PNG is supported by all tools.  GIMP doesn't support all 
> features of PSD files.
> 
>   The fact is, WHATEVER format we end up, it needs to be 
> understood that there will be other consumers of that format that 
> will not (or can not) implement a full 100% of it.

Yes, but TIFF has got this situation much much worse than other formats.
It'd be adding more confusion to an already bad situation.

> >There's an advantage of starting from a clean slate, and not having to
> >worry about existing baggage.
> >
> 
>   There is indeed...and there are disadvantages as well 
> (including a LOT more time to design and then code).

Not really. Nailing down a featureset has to be done regardless of the format.
With the XML+AR idea, there's a little work needed to make a DTD, and then
just putting some building blocks together, like an xml library and some ar
processing code (multiple implementations exist) and some convenience wrappers.

Also, suppose customizing libtiff is needed (and it sounds like it would be),
that'd mean forking libtiff and the maintainence problem of tracking
the original for bugfixes and enhancements.

For GIMP, we're better off to have a native file format we have the last word
on rather than trying to co-opt something else and twisting things to work.
Certainly, there should be a libxcf for other programs to use, and include
thumbnails and other convenience ancillary data for simpler programs to
work with.

-Yosh
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

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

[Leonard Rosenthol]

At 9:33 PM -0400 8/13/03, Carol Spears wrote:
The last time I got the mng libraries, they came along with liblcms. 
Are you sure that liblcms does not do all of this?
	A quick reread of the PNG/MNG format reveals that you can use 
ICC profiles, but NOT CMYK, Lab or other color spaces.   That's why 
lcms - to handle the embedded profiles that might exist.


Rightly or wrongly, I consider ImageMagick to be the gimps command line
until it gets too ugly and you need to start scripting.  Probably this
is wrong also?
	That's as good a use for IM as any ;).


tiff is so old.
	True, but that in and of itself isn't a bad thing...


it seems like many old ideas have a lousy way of handling some of 
the new ideas.
	Such as?  Can you give a specific technical example of a 
problem/limitation of TIFF???

Leonard
--
---
Leonard Rosenthol
 
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

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

[Manish Singh]

On Wed, Aug 20, 2003 at 10:53:14PM -0400, Leonard Rosenthol wrote:
> At 6:51 PM -0700 8/13/03, Manish Singh wrote:
> >Does TIFF support, for example, float16 data, or a CIE XYZ colorspace?
> 
>   Yes to both...
 
Hmm, got a reference to that? It wasn't immediately apparent in my reading
of the spec.
 
> >I'm somewhat concerned with going with an externally standardized format,
> >then running into a wall with it at some later point, and not being able
> >to add a feature without breaking standards compliance.
> >
> 
>   Worse case is that we add new tags (that we've registered 
> with Adobe) and other readers don't support that information...

What's the turnaround time for that? Taking weeks or months isn't really
acceptable... 

Another thing I'm worried about is simply adding to the confusion of 
"what is a tiff file". There are few tiff readers/writers that support
the entire feature set of tiff, and many broken implementations out there.
There's an advantage of starting from a clean slate, and not having to
worry about existing baggage.

-Yosh
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

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

[Leonard Rosenthol]

At 8:12 PM -0700 8/13/03, Manish Singh wrote:
On Wed, Aug 20, 2003 at 10:53:14PM -0400, Leonard Rosenthol wrote:
 > At 6:51 PM -0700 8/13/03, Manish Singh wrote:
 >Does TIFF support, for example, float16 data, or a CIE XYZ colorspace?

	Yes to both...
Hmm, got a reference to that? It wasn't immediately apparent in my reading
of the spec.
	See Section 19 for Floating point support in data.

	I forget the section, but a simple search of the TIFF6 spec 
led to a number of references on CIE XYZ support.


What's the turnaround time for that? Taking weeks or months isn't really
acceptable...
	It's there to make sure that people don't duplicate tags - so 
as long as we pick pretty unique tags related to the GIMP, it's not a 
problem.


Another thing I'm worried about is simply adding to the confusion of
"what is a tiff file". There are few tiff readers/writers that support
the entire feature set of tiff, and many broken implementations out there.
	True - but that's the case with EVERY SINGLE file format 
(graphic, wp, etc.).  Only the original application for which the 
format was created will usually support all features.   Not every 
feature of PNG is supported by all tools.  GIMP doesn't support all 
features of PSD files.

	The fact is, WHATEVER format we end up, it needs to be 
understood that there will be other consumers of that format that 
will not (or can not) implement a full 100% of it.


There's an advantage of starting from a clean slate, and not having to
worry about existing baggage.
	There is indeed...and there are disadvantages as well 
(including a LOT more time to design and then code).

	And those are the tradeoffs that someone (Sven?  Mitch? 
etc.?) will have to make sooner or later...

Leonard
--
---
Leonard Rosenthol
 
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

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

[Manish Singh]

On Thu, Aug 21, 2003 at 10:16:13AM -0400, Leonard Rosenthol wrote:
> At 11:42 PM -0700 8/13/03, Manish Singh wrote:
> >Supports IEEE floats, but not float16 (a 32-bit float cut in half). R&H
> >added this to filmgimp since they had established this format in their
> >workflow with other tools already.
> 
>   Why would you only use half of a 32bit float??  That reduces 
> your accuracy/precision and makes you incompatible with the rest of 
> the world doing floating point imaging.

But if your other tools already use it (for whatever reason, technical
or historical) easier have GIMP support it rather than change the rest.
This is precisely the reason R&H decided to go with an open source solution
like GIMP (they could hack float16 support in) instead of Photoshop or
some other closed paint program.

>   And admittedly, it's not a big deal to convert...
 
And makes the file size twice as big...
 
> >One of the goals of GEGL is to allow GIMP to be adapted to wacky formats
> >like these easily.
> 
>   I would argue that using "wacky formats" is a bad thing.  The 
> more wacky you make things, the less change you have for 
> interoperability with other tools.

If you make it easier to accept wacky things, you interoperate better.
Suppose someone wants to use GIMP to manipulate what their neurological
imaging scanner spits out at full precision; GEGL is supposed to make
that possible.

Yes, there should be efforts to make the common case easily interoperable,
but uncommon things should be possible with the minimum amount of hoops.

> >It's not just the tags, but extending value ranges for tags (needed for
> >the two cases above). And a lag time means either waiting for an updated
> >spec, which is a holdup, or going ahead and running the risk it not being
> >granted because someone else tried to get their conflicting values in 
> >first.
> 
>   The spec is only updated every 18-24 months when Adobe 
> releases a new version of Photoshop - so you definitely don't wait 
> for that!   As for the other, yes, that is true you could wait, but 
> nobody does...
 
And Foo organization adds a tag with the the same value as Bar organization,
for different purposes, since neither cares to wait. Part of the reason
why there is a lot of bad tiff processors out there I think.

> >With the XML+AR idea, there's a little work needed to make a DTD, and then
> >just putting some building blocks together, like an xml library and some ar
> >processing code (multiple implementations exist) and some 
> >convenience wrappers.
> 
>   Never implemented a file format, have you ;).

What widely used formats have you implemented? :)
 
>   Reading/Writing the 'ar' archive, and reading/writing the XML 
> is the easy part - because you can leverage existing libraries to 
> some extent.   The toughest part is putting it all together in a 
> library of its own that allows for full random access.   Most 
> archiving libraries are "all at once" solutions, they aren't designed 
> for single file extraction.  We, of course, need that.  We also, as 

ar supports random access and single file extraction just fine. Take a look
at the manpage for it sometime. :)

> part of the DTD/Schema work need to define how you go from a GIMP 
> image in memory to a disk representation and then back and work out 
> the details.

And for TIFF we need to define how you go from a GIMP image in memory to
TIFF tags and values. Remember GIMP has to carry around a fair amount
of metadata, like layer settings, paths, parasites, etc.

>   Worth the work, sure!  Trivial - no way!

It doesn't seem to me that using libtiff saves us a significant amount of
work.

> 
> >Also, suppose customizing libtiff is needed (and it sounds like it would 
> >be),
> >that'd mean forking libtiff and the maintainence problem of tracking
> >the original for bugfixes and enhancements.
> 
>   There is no need to touch libtiff - and if there is, you 
> don't work, you modify and then submit your changes back.  libtiff is 
> an active library, and the maintainers would happily accept changes...
 
Yeah, but there are people out there still running outdated installed,
it's harder to get them to upgrade a system library.

If we add and extend tags, their definitions should go in the library, no?
So what to do in the time before those changes are accepted...

Also, one has to wonder why Adobe is keeping PSD around if TIFF does
everything.
 
-Yosh
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

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

[Stephen J Baker]

Carol Spears wrote:

However, I read recently about artifacts appearing in compressed pngs, 
so this might not be the miracle fix I had hoped for.
!!!

Where did you see that?

PNG uses a lossless compression scheme - if there are 'artifacts' in the
image that were not there when the image was given to the PNG library then
that is an extremely serious bug!!
I find this very hard to believe.

However, there are people who take an image (eg from a digital camera) in
JPEG (which is lossy and has artifacts) and CONVERTING them to PNG and then
seeing artifacts.

Steve Baker  (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: [EMAIL PROTECTED]   http://www.link.com
Home: [EMAIL PROTECTED]   http://www.sjbaker.org
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

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

[Leonard Rosenthol]

At 11:42 PM -0700 8/13/03, Manish Singh wrote:
Supports IEEE floats, but not float16 (a 32-bit float cut in half). R&H
added this to filmgimp since they had established this format in their
workflow with other tools already.
	Why would you only use half of a 32bit float??  That reduces 
your accuracy/precision and makes you incompatible with the rest of 
the world doing floating point imaging.

	And admittedly, it's not a big deal to convert...


One of the goals of GEGL is to allow GIMP to be adapted to wacky formats
like these easily.
	I would argue that using "wacky formats" is a bad thing.  The 
more wacky you make things, the less change you have for 
interoperability with other tools.


GEGL uses XYZ as a native format.
	Why?   Lab is a richer model esp. for handling chromanicity 
and is also a standard in the print world natively.   Why limit to 
XYZ??


It's not just the tags, but extending value ranges for tags (needed for
the two cases above). And a lag time means either waiting for an updated
spec, which is a holdup, or going ahead and running the risk it not being
granted because someone else tried to get their conflicting values in first.
	The spec is only updated every 18-24 months when Adobe 
releases a new version of Photoshop - so you definitely don't wait 
for that!   As for the other, yes, that is true you could wait, but 
nobody does...


Nailing down a featureset has to be done regardless of the format.
	That part is most certainly true.


With the XML+AR idea, there's a little work needed to make a DTD, and then
just putting some building blocks together, like an xml library and some ar
processing code (multiple implementations exist) and some 
convenience wrappers.
	Never implemented a file format, have you ;).

	Reading/Writing the 'ar' archive, and reading/writing the XML 
is the easy part - because you can leverage existing libraries to 
some extent.   The toughest part is putting it all together in a 
library of its own that allows for full random access.   Most 
archiving libraries are "all at once" solutions, they aren't designed 
for single file extraction.  We, of course, need that.  We also, as 
part of the DTD/Schema work need to define how you go from a GIMP 
image in memory to a disk representation and then back and work out 
the details.

	Worth the work, sure!  Trivial - no way!


Also, suppose customizing libtiff is needed (and it sounds like it would be),
that'd mean forking libtiff and the maintainence problem of tracking
the original for bugfixes and enhancements.
	There is no need to touch libtiff - and if there is, you 
don't work, you modify and then submit your changes back.  libtiff is 
an active library, and the maintainers would happily accept changes...


For GIMP, we're better off to have a native file format we have the last word
on rather than trying to co-opt something else and twisting things to work.
	"Better off" for what reasons??

	Does it have advantages, yes.  Does it have disadvantages, 
yes.  Where do we draw the line???

Leonard
--
---
Leonard Rosenthol
 
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

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

[Stephen J Baker]

Leonard Rosenthol wrote:
At 8:26 PM -0400 8/13/03, Carol Spears wrote:

What about mng?  It contains png and has layers and comments.


Yes, but still has the limitations of no-CMYK (Lab, ICC, etc.) 
colorspaces (among other things) out of the box...
Has anyone considered going to the PNG maintainers and asking for
these things to be included?
The GIMP project is not without influence in the OpenSource world.


Steve Baker  (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: [EMAIL PROTECTED]   http://www.link.com
Home: [EMAIL PROTECTED]   http://www.sjbaker.org
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

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

[Leonard Rosenthol]

At 6:51 PM -0700 8/13/03, Manish Singh wrote:
Does TIFF support, for example, float16 data, or a CIE XYZ colorspace?
	Yes to both...


I'm somewhat concerned with going with an externally standardized format,
then running into a wall with it at some later point, and not being able
to add a feature without breaking standards compliance.
	Worse case is that we add new tags (that we've registered 
with Adobe) and other readers don't support that information...

Leonard
--
---
Leonard Rosenthol
 
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

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

[Tino Schwarze]

On Thu, Aug 21, 2003 at 01:33:50AM -0400, Leonard Rosenthol wrote:

> >why would i want to save to a file format that would render my image 
> >that's built up of layer masks and vector text layers really badly 
> >if opened in a standard viewer
> 
>   Because at least you COULD open it up in a standard viewer.
> 
>   Is it better to be able to get at the data in SOME format, 
> but not perfect, using a 3rd party tool - OR not get ANY of your 
> data?!?!

I see no point in being able to open a GIMP-file called .tif with CIE
XYZ data in it - most of the viewer would simply say: "this is broken".

I suppose that most of the time, the GIMP-TIFFs are so special that they
cannot be viewed with a standard TIFF viewer. As already noted, if your
audience cannot read GIMP-files, you can always export the image.

IMO we gain nothing by using TIFF (apart from (ab?)using an existing
file format). I'm still for the archive+XML+image data as PNG (or TIF?)
approach - it allows the image to be manipulated externally. A thumbnail
could be embedded such that it's easy to extract, so viewers have a
chance to display something.

> >so why use a format that all consumers would expect to be able to 
> >utilise 100%, it would surely confuse the hell out of your average 
> >photo$hop users to use TIFF in this way, especially if we're looking 
> >at cross compatibility.
> 
>   Actually, many users already DO use Photoshop and TIFF this 
> way!  If you have a multi-layered PSD file,  including text layers, 
> layer effects, etc and you save as TIFF, Photoshop writes out all the 
> information necessary for it to coime back into Photoshop with full 
> fidelity.  BUT if you open it up in some simple TIFF viewer - of 
> course, you don't get the same effect.
> 
>   GIMP's use of TIFF would be EXACTLY the same...

I don't see the point of being able to get a rough approximation (or
total garbage) of the image when opening it in a "simple viewer".

> >in which case you'd have to do something about a workaround, like 
> >maybe have an optional pre-rendered version of the image stored in 
> >the XCF for viewers that don't support it properly,
> 
>   Which is what Photoshop does in PSD...
> 
>   For applications that support layers, you can read them.  If 
> you don't, there is an already rendered/flattend version available.

I don't like the idea of having my A3/300dpi poster stored prerendered
in the file. Of course, this could be an option. But I had to work with
such beasts and even on kick-ass machines, you need some patience and
the files tend to get huge.

> >GIMP has this handy thing called export, if your target audience 
> >wont be able to read an XCF then don't give them one, give then a 
> >PNG instead.
> 
>   Sure, and lose all the extra information that might be useful 
> to them in other authoring environments...
> 
>   And what about posting things online or to archives??

I think, this could be implemented as an extra: If you export an MNG,
the XML description could be embedded into the file. Then you have
the archive+XML+imagedata approach but a bit reversed. It would also
work for TIFF.

The biggest problem I see is that users will start using weird image
formats if GEGL becomes available. Maybe, I want my images to be 16.8
fixed point in HLS colorspace? There are probably only a few readers
out there which are able to display this... but I may overestimate this.

Also, being able to get at the layer data does not mean that you can
represent the image appropiately. You'd need to implement lots of layer
blending modes etc. Of course, a feature-rich libxcf could solve part of
that problem.

Bye, Tino.

-- 
 * LINUX - Where do you want to be tomorrow? *
  http://www.tu-chemnitz.de/linux/tag/
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

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

[Nathan Carl Summers]

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

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

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

[Leonard Rosenthol]

At 3:33 PM -0400 8/14/03, Carol Spears wrote:
So this combination would answer your LAB & CMYK issues and possibly 
my need to use a greater than 256 color palette then?
	No, it would not.

	ICC profiling is a VERY different thing that actual "raw" 
CMYK or Lab data...

	Paletizing of an image is also different...


Complaints I remember reading from more "technically inclined" 
people about tiff were mostly about the lwz compression.  I guess 
while it was not free it was also not the best way to go about doing 
such a thing.
	Yes, that was a legal issue, not a truly technical one. 
(LZW, not lwz).


However, I read recently about artifacts appearing in compressed 
pngs, so this might not be the miracle fix I had hoped for.
	PNG won't artifact images unless you are palettizing them, 
which is NOT the default.

LDR
--
---
Leonard Rosenthol
 
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

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

[Raphaël Quinet]

On Wed, 13 Aug 2003 23:42:36 -0700, Manish Singh <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 21, 2003 at 01:38:01AM -0400, Leonard Rosenthol wrote:
> > At 8:12 PM -0700 8/13/03, Manish Singh wrote:
> > >What's the turnaround time for that? Taking weeks or months isn't really
> > >acceptable...
> > 
> > It's there to make sure that people don't duplicate tags - so 
> > as long as we pick pretty unique tags related to the GIMP, it's not a 
> > problem.
> 
> It's not just the tags, but extending value ranges for tags (needed for
> the two cases above).

If I am not mistaken, one cannot extend the value range of tags that
are already registered.  So the only solution is to define a new tag
based on the old one and extending its capabilities.  This also means
that most TIFF readers will just discard the new tags because they are
not able to deal with them.  One solution (kludge) would be to encode
as much of the data as possible in the "standard" tags (i.e., for CIE
LAB) and then encoding the differences in a new tag (whatever parts of
XYZ do not fit in LAB).  That would allow more software to read at
least a part of the data, but do we really want to do that?  Probably
not.

> For GIMP, we're better off to have a native file format we have the last word
> on rather than trying to co-opt something else and twisting things to work.
> Certainly, there should be a libxcf for other programs to use, and include
> thumbnails and other convenience ancillary data for simpler programs to
> work with.

>From my point of view, this is the best solution.  However, there is
one thing that has not been mentioned in this discussion until now: we
have to state very clearly that the new XCF is meant to be an open
format (or not!).  There has always been some confusion about whether
the current XCF could be used by other applications (e.g. file
managers, indexing programs or other image editing software).  I think
that we have to choose one of the following two solution and not
something in between:

- XCF is an open format that can be used by other applications and can
  be used as an interchange format.  In this case, every single
  feature of the file format has to be documented very clearly.  The
  documentation should not lag behind the implementation (even during
  development).  Also, the file format should use version numbers or
  tag names for each part of the file and there should be a way for
  other applications to know if understanding a given part of the file
  is mandatory or if it is optional (like PNG does with the naming of
  its tags).  Ideally, the code for loading and/or saving XCF files
  should be available as one or two libaries distributed under the
  LGPL or maybe a BSD license.  If XCF files can be produced by other
  applications than the GIMP (and other libraries than the XCF library
  included in the GIMP), then we should be prepared to handle files
  that are broken in various ways and fail gracefully.

- XCF is mostly a GIMP internal file format and XCF files are not
  intended to be distributed widely and read or written by other
  applications.  In this case, we can have some documentation but we
  make no promises to other applications.  The file format can change
  at any time (as the GIMP developers add new features or fix some
  bugs in the file format) and the others have to deal with it.  This
  also means that the file format is not a standard so nothing would
  prevents another application from extending XCF in some incompatible
  way: if XCF files are not intended for distribution, any application
  can do whatever it wants to do with its private version of XCF.
  Although I think it could have been done in a better way (more
  communication and more care about XCF version numbers), there is
  nothing really wrong in creating an incompatible version of XCF for
  FilmGimp/CinePaint as long as XCF files are intended to be private
  files for the application that created them.

We are leaning towards the first solution for the new XCF file format.
Previously, XCF was usually defined as belonging to the second
category.  If we want XCF to be an open standard that can also be used
for distribution of images and exchange of files between several
applications, we have to do it in the right way.  We also have to be
prepared to deal with the consequences: one of them will be that we
cannot make any assumptions about the correctness of the files that we
try to read.  From now on, the GIMP will have to be (more) careful
when reading the XCF files and implement some (more) error detection
and recovery.

Also, if we define a new version of the XCF file format to be used in
GIMP 2.2 or 3.0, this means that the old versions used in GIMP 1.x and
2.0 and the versions used in FilmGimp/CinePaint will become frozen.
This may not be true for the CinePaint version if the CinePaint
developers do not want to adopt the new XCF file format, but I hope
that we can define a new format that will suit everybody.  I

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

[Leonard Rosenthol]

At 3:03 AM + 8/14/03, Phil Harper wrote:
the last thing Adobe wants to do is support XCF, it's a competing 
format belonging to a competing(and competatively priced) app.
	Actually, the fact that it comes from GIMP has NOTHING to do 
with.  The fact that few (if any) of theirs users are asking for that 
feature, is what is driving it (or not).



why would i want to save to a file format that would render my image 
that's built up of layer masks and vector text layers really badly 
if opened in a standard viewer
	Because at least you COULD open it up in a standard viewer.

	Is it better to be able to get at the data in SOME format, 
but not perfect, using a 3rd party tool - OR not get ANY of your 
data?!?!


rather than in a format engineered from the ground up for all of the 
requirements i could have, and that is distinctive as being a GIMP 
image format, rather than just a really ugly TIFF?
	Having a distinctive image format for the GIMP is also an 
option - one we discussed pre-camp...I was just putting forward other 
alternatives that have their own advantages and disadvantages.


so why use a format that all consumers would expect to be able to 
utilise 100%, it would surely confuse the hell out of your average 
photo$hop users to use TIFF in this way, especially if we're looking 
at cross compatibility.
	Actually, many users already DO use Photoshop and TIFF this 
way!  If you have a multi-layered PSD file,  including text layers, 
layer effects, etc and you save as TIFF, Photoshop writes out all the 
information necessary for it to coime back into Photoshop with full 
fidelity.  BUT if you open it up in some simple TIFF viewer - of 
course, you don't get the same effect.

	GIMP's use of TIFF would be EXACTLY the same...


in which case you'd have to do something about a workaround, like 
maybe have an optional pre-rendered version of the image stored in 
the XCF for viewers that don't support it properly,
	Which is what Photoshop does in PSD...

	For applications that support layers, you can read them.  If 
you don't, there is an already rendered/flattend version available.


but, at that point it's questionable that you'd want to view an 
XCFin something other than GIMP, remember,
	Except in the case where the user does not HAVE the GIMP - 
either because they just don't have it, or perhaps it doesn't exist 
on that OS platform...


GIMP has this handy thing called export, if your target audience 
wont be able to read an XCF then don't give them one, give then a 
PNG instead.

	Sure, and lose all the extra information that might be useful 
to them in other authoring environments...

	And what about posting things online or to archives??

Leonard
--
---
Leonard Rosenthol
 
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

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

[Phil Harper]

From: Leonard Rosenthol <[EMAIL PROTECTED]>
To: "Phil Harper" <[EMAIL PROTECTED]>,[EMAIL PROTECTED]
Subject: Re: [Gimp-developer] GimpCon RFC: Portable XCF
Date: Wed, 20 Aug 2003 20:54:55 -0400
MIME-Version: 1.0
At 11:42 PM + 8/13/03, Phil Harper wrote:
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.)
	They support a number of formats that they don't control - because they 
are standard formats that their customers are requesting.   But today XCF 
isn't one of them, and probably won't be for a while.
the last thing Adobe wants to do is support XCF, it's a competing format 
belonging to a competing(and competatively priced) app.


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.
	It might, but again, I can't see them doing it.  What's the ROI for them 
to invest in this?   They already support PSD and TIFF as the two richest 
formats for layered raster images.  (not to mention PS and PDF).

there's very little, but eveything else seems rather speculative at this 
stage, so why not.


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),
	That is true, and a big reason to not use PSD...


as for TIFF, you wouldn't be able to do it in a standard readable TIFF,
	This, however, is wrong!   We can represent EVERYTHING in GIMP today, and 
EVERYTHING for GEGL (etc.) in the future with TIFF. And other programs 
simply will ignore them as they do with other features of TIFF they don't 
support.

why would i want to save to a file format that would render my image that's 
built up of layer masks and vector text layers really badly if opened in a 
standard viewer rather than in a format engineered from the ground up for 
all of the requirements i could have, and that is distinctive as being a 
GIMP image format, rather than just a really ugly TIFF?


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.
	Easy enough to create one with ImageMagick using a bunch of other files.

	convert a.png b.jpg c.gif +adjoin output.tiff
thanks i might try that.


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.
	EXACTLY my point!

	Whatever file format we end up with, we need to accept that not all 
consumers of that file format will be able to support 100% of the features 
(perhaps not even GIMP itself).

so why use a format that all consumers would expect to be able to utilise 
100%, it would surely confuse the hell out of your average photo$hop users 
to use TIFF in this way, especially if we're looking at cross compatibility.


	Adobe does that with .ai, which is really .pdf...
i thought it was a kind of encapsulated post script
	It was through version 8, but since version 9, it has been PDF...
ah, i see


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.

	You could get that just as easily with XCF when a given consumer/reader 
doesn't support 100% of the features of the format...
in which case you'd have to do something about a workaround, like maybe have 
an optional pre-rendered version of the image stored in the XCF for viewers 
that don't support it properly, but, at that point it's questionable that 
you'd want to view an XCFin something other than GIMP, remember, GIMP has 
this handy thing called export, if your target audience wont be able to read 
an XCF then don't give them one, give then a PNG instead.

Phil.

Leonard
--
---
Leonard Rosenthol
<mailto:[EMAIL PROTECTED]>
 			 <http://www.lazerware.com>
_
Use MSN Messenger to send music and pics to your friends 
http://www.msn.co.uk/messenger

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

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

[Carol Spears]

Leonard Rosenthol wrote:

At 6:51 PM -0700 8/13/03, Manish Singh wrote:

Does TIFF support, for example, float16 data, or a CIE XYZ colorspace?


Yes to both...


I'm somewhat concerned with going with an externally standardized 
format,
then running into a wall with it at some later point, and not being able
to add a feature without breaking standards compliance.

Worse case is that we add new tags (that we've registered with 
Adobe) and other readers don't support that information...
Adobe needs to register with us first.

carol



___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

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

[Carol Spears]

Leonard Rosenthol wrote:

At 9:33 PM -0400 8/13/03, Carol Spears wrote:

The last time I got the mng libraries, they came along with liblcms. 
Are you sure that liblcms does not do all of this?


A quick reread of the PNG/MNG format reveals that you can use ICC 
profiles, but NOT CMYK, Lab or other color spaces.   That's why lcms - 
to handle the embedded profiles that might exist.
So this combination would answer your LAB & CMYK issues and possibly 
my need to use a greater than 256 color palette then?





Rightly or wrongly, I consider ImageMagick to be the gimps command line
until it gets too ugly and you need to start scripting.  Probably this
is wrong also?


That's as good a use for IM as any ;).


tiff is so old.


True, but that in and of itself isn't a bad thing...
Well, there are a few well designed computer things that have made it 
fairly unscathed throughout computer history.  It takes foresight and
flexiblity and probably some luck and good drugs as well. 

Complaints I remember reading from more "technically inclined" people 
about tiff were mostly about the lwz compression.  I guess while it 
was not free it was also not the best way to go about doing such a 
thing.

However, I read recently about artifacts appearing in compressed pngs, 
so this might not be the miracle fix I had hoped for.

I will always feel a little bitter about the lwz thing.




it seems like many old ideas have a lousy way of handling some of 
the new ideas.
   

Such as?  Can you give a specific technical example of a 
problem/limitation of TIFF???
I tried to explain my thoughts on this earlier.  I am very pleased 
that historically GIMP has only "borrowed" methods and ideas from 
Photoshop that were the best idea or approach to the problem.  I hope 
that we continue to do this.

Unfortunately, this is not always the *easiest* approach; but nothing 
says it needs to be the hardest way either.

Technically, I really liked the mng animation that I made.  It was a 
beautiful web graphic.  Lush even.

carol



___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

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

[Nathan Carl Summers]

On Wed, 20 Aug 2003, Leonard Rosenthol wrote:

> At 11:42 PM + 8/13/03, Phil Harper wrote:
> >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.)
>
>   They support a number of formats that they don't control -
> because they are standard formats that their customers are
> requesting.   But today XCF isn't one of them, and probably won't be
> for a while.

AFAICT, there is nothing stopping Gimp developers from creating a
potatoshop plugin that can read 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.
>
>   EXACTLY my point!
>
>   Whatever file format we end up with, we need to accept that
> not all consumers of that file format will be able to support 100% of
> the features (perhaps not even GIMP itself).
>
>
>
> >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.
> >
>
>   You could get that just as easily with XCF when a given
> consumer/reader doesn't support 100% of the features of the format...

With a PNG style format, this becomes much less of an issue.  First, PNG
requires all readers to be able to interpret a core subset -- anything
that can't interpret it violates the standard.  Second, all chunks are
tagged "optional" (meaning that they can be safely ignored if not
understood" or "mandatory" (in which case the reader will give up if it
doesn't understand the chunk.)  This means that a baseline PNG can be read
by any compliant program (hello, IE!) without problem, and any extensions
will either degrade gracefully or cause an error, but in no case will  the
decoder become confused and return a strange and wrong result.

In this way, for example, someone could create a PNG chunk that indicated
that the data was in Lab space, and a decoder that didn't recognize that
feature would just give up instead of returning some garbage where the red
channel gets luminence, etc.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

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

[Carol Spears]

Leonard Rosenthol wrote:

At 8:26 PM -0400 8/13/03, Carol Spears wrote:

What about mng?  It contains png and has layers and comments.


Yes, but still has the limitations of no-CMYK (Lab, ICC, etc.) 
colorspaces (among other things) out of the box...
The last time I got the mng libraries, they came along with liblcms.  
Are you sure that liblcms does not do all of this?



Seems to be basically unmaintained.


PNG/MNG/JNG is fully supported and maintained by the libpng group, 
which is headed by Glenn Randers-Pehrson who is also one of the 
maintainers (along with myself) of ImageMagick and GraphicsMagick.
Sorry, my confusion.  It is the plugin at that other ill-maintained 
godforsaken software package that is having maintenance reviews or 
something.

Rightly or wrongly, I consider ImageMagick to be the gimps command line
until it gets too ugly and you need to start scripting.  Probably this
is wrong also?
tiff is so old.  it seems like many old ideas have a lousy way of 
handling some of the new ideas.  Sort of like comparing oggs to mp3's,
the way I understand it, the framing idea is sort of a miracle to work
in mp3's the way it does while with oggs this idea was built in from 
the beginning.  This explanation explains the sound quality differences
to me.  I am wondering if this same line of thinking can be applied to
tiffs?

carol



___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

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

[Daniel Rogers]

Leonard Rosenthol wrote:
At 11:42 PM -0700 8/13/03, Manish Singh wrote:

GEGL uses XYZ as a native format.


Why?   Lab is a richer model esp. for handling chromanicity and is 
also a standard in the print world natively.   Why limit to XYZ??

I am not sure what you mean by a "richer model."  Lab is a one-to-one mapping of XYZ. 
Every color in Lab is also in XYZ and visa versa.  The transforms to/from XYZ from most 
other colorspaces is faster.  Besides, Lab is _defined_ in terms of the XYZ colorspace. 
(well actually Lab is defined in terms of the xyY colorspace, which in turn is defined by 
the XYZ color space).  And XYZ is not a "limit."  XYZ is, to the best of the worlds 
scientific ability, contains every other 3 components human perception colorspace.  You 
can convert from any colorspace to XYZ without a loss of information.  And as far as it 
being gegl's "native" format, what he really means is that XYZ is used precisly in this 
fation.  As a connection space between different colorspaces (just like most generic ICC 
color profiles are designed to do).

--
Dan
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

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

[Leonard Rosenthol]

At 8:26 PM -0400 8/13/03, Carol Spears wrote:
What about mng?  It contains png and has layers and comments.
	Yes, but still has the limitations of no-CMYK (Lab, ICC, 
etc.) colorspaces (among other things) out of the box...


Seems to be basically unmaintained.
	PNG/MNG/JNG is fully supported and maintained by the libpng 
group, which is headed by Glenn Randers-Pehrson who is also one of 
the maintainers (along with myself) of ImageMagick and GraphicsMagick.

Leonard
--
---
Leonard Rosenthol
 
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

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

[Carol Spears]

Phil Harper wrote:

From: Leonard Rosenthol <[EMAIL PROTECTED]>
To: Nathan Carl Summers <[EMAIL PROTECTED]>
CC: The Gimp Developers' list <[EMAIL PROTECTED]>
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:


 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
What about mng?  It contains png and has layers and comments.  Seems 
to be basically unmaintained.  I suggested it at another not so 
important software project and the idea went over real big!!  I would 
like to know the GAP authors idea about mng, actually.

carol

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

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

[Manish Singh]

On Wed, Aug 20, 2003 at 08:54:55PM -0400, Leonard Rosenthol wrote:
> At 11:42 PM + 8/13/03, Phil Harper wrote:
> >as for TIFF, you wouldn't be able to do it in a standard readable TIFF,
> 
>   This, however, is wrong!   We can represent EVERYTHING in 
> GIMP today, and EVERYTHING for GEGL (etc.) in the future with TIFF. 
> And other programs simply will ignore them as they do with other 
> features of TIFF they don't support.

Does TIFF support, for example, float16 data, or a CIE XYZ colorspace?

I'm somewhat concerned with going with an externally standardized format,
then running into a wall with it at some later point, and not being able
to add a feature without breaking standards compliance.

-Yosh
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

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

[Leonard Rosenthol]

At 6:13 AM -0700 8/14/03, Nathan Carl Summers wrote:
AFAICT, there is nothing stopping Gimp developers from creating a
potatoshop plugin that can read XCF.
	That is definitely true!  Absolutely nothing prevents this - 
and certainly sounds like a great idea for someone...


 >	You could get that just as easily with XCF when a given
 consumer/reader doesn't support 100% of the features of the format...
With a PNG style format, this becomes much less of an issue.  First, PNG
requires all readers to be able to interpret a core subset -- anything
that can't interpret it violates the standard.
	True, but the subset for PNG support is a low barrier for 
entry.  The "core" of XCF is (potentially) a MUCH higher barrier...

Leonard
--
---
Leonard Rosenthol
 
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

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

[Leonard Rosenthol]

At 11:42 PM + 8/13/03, Phil Harper wrote:
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.)
	They support a number of formats that they don't control - 
because they are standard formats that their customers are 
requesting.   But today XCF isn't one of them, and probably won't be 
for a while.


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.
	It might, but again, I can't see them doing it.  What's the 
ROI for them to invest in this?   They already support PSD and TIFF 
as the two richest formats for layered raster images.  (not to 
mention PS and PDF).



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),
	That is true, and a big reason to not use PSD...


as for TIFF, you wouldn't be able to do it in a standard readable TIFF,
	This, however, is wrong!   We can represent EVERYTHING in 
GIMP today, and EVERYTHING for GEGL (etc.) in the future with TIFF. 
And other programs simply will ignore them as they do with other 
features of TIFF they don't support.


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.
	Easy enough to create one with ImageMagick using a bunch of 
other files.

	convert a.png b.jpg c.gif +adjoin output.tiff


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.
	EXACTLY my point!

	Whatever file format we end up with, we need to accept that 
not all consumers of that file format will be able to support 100% of 
the features (perhaps not even GIMP itself).


	Adobe does that with .ai, which is really .pdf...
i thought it was a kind of encapsulated post script
	It was through version 8, but since version 9, it has been PDF...


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.

	You could get that just as easily with XCF when a given 
consumer/reader doesn't support 100% of the features of the format...

Leonard
--
---
Leonard Rosenthol
 
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

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

[Leonard Rosenthol]

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.

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


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?


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

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


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


We might want to change the magic number as well.
	Wouldn't do that, since the whole idea is to maintain compatibility...


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


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


	Definitely!

Leonard
--
---
Leonard Rosenthol
 
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

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

[Nathan Carl Summers]

Good to get some high-quality feedback.

On Sat, 9 Aug 2003, Leonard Rosenthol wrote:
> At 6:01 PM -0700 8/8/03, Nathan Carl Summers wrote:
> >Let us start with an existing graphics format, for inspiration if nothing
> >else.
>
>   OK.
>
>
> >The format I chose is PNG, because it is arguably the best existing
> >lossless portable graphics format available.
>
>   Well, I would argue that TIFF has the "crown"...
>
>   However, PNG is an excellent standard, regardless.

Good point.  It can't hurt to take a look at several graphics formats and
take the best parts from each of them.

> >4 capable of representing trees and graphs
>
>   Trees, yes - for things like layers.   But why a graph??

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

> >5 recoverable from corruption
> >6 fast random access of data
> >9 fast loads and saves
> >10 compact
>
>   Good goals, but not a requirements.  Perhaps you should
> separate those two things out...

I see fast loads as an absolute requirement.  Being compact is nice as
well, because not everyone has 3 terrabyte harddrives and a T3 line into
their house.

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.  A VIPS-like demand-driven pipeline would increase gimp
responsiveness a lot.

>   And I can think of other goals that I'd like to see:
>
> * 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.

> * rich metadata
>   (this may be your 7, but needs to be spelled out)

Well, that was what I meant by extensibility and the ablity to represent
anything GIMP can.  I agree that this is important.

> >PNG certainly supports 1,2,6,7,9,10, and 11.  Let us examine the other
> >issues in more detail.
>
>   I would argue that PNG doesn't do 7 - it has no native
> support for CMYK, for example.  (but yes, it does RGB,  Gray and
> indexed).
>
>
>   And for comparison, I would offer that TIFF does the same
> list and REALLY does 7, including CMYK, Lab, ICC and Spot color
> spaces.   It's extensibility is similar to PNG (in fact, PNG's chunks
> were modelled on TIFF chunks).

Indeed.

> >A pure XML format, by way of comparison, would fulfill requirements
> >1,2,3,4,7, and 8.
>
>   I'd add 9, just being in XML doesn't mean it can't be fast.

I guess if you used raw image data instead of base64 or something similar

> >  Requirement 5 in practice would be difficult to fulfill
> >in a pure XML format without hand-hacking, which is beyound the skills of
> >most users.  A zlib-style compression step could make some progress
> >towards 10.
>
>   But gzipping the entire XML block would then pretty make 6
> impossible unless you want to seriously increase in-memory
> requirements.

right.

> >An archive with XML metadata and png graphical data, on the other hand,
> >would satisfy requirements 1,2,3,4,7,8, and 11.
>
>   An archive (zip, tar, ar) with XML metadata plus raster image
> data (ie. my previous proposal) would meet 1,2,3,4,6,7,8,10,11.   5 &
> 10 are related to the archive format of choice since some are better
> at these than others.  But yes, I suspect that it would probably be a
> bit slower.
>
>
>
> >Requirement 6 is
> >fulfilled for simple images, but for more complex images XML does not
> >scale well, since every bite from the begining of the XML file to the
> >place in which the data you are interested in is.
>
>   But the XML is just a "catalog" of what's in the archive (at
> least in my proposal).  So you read the catalog up front and then use
> it to quickly find the part of the archive you want and viola - fast
> random access to data.
>
>
> >It seems like all we have to do is combine the strengths of PNG and the
> >strengths of XML to create a format that satisfies our requirements.  What
> >we really need is not an extensible text markup language, but an
> >extensible graphics markup format.
>
>   That's what TIFF and PNG were designed for.
>
>
> >Portable XCF would use a chunk system similar to PNG, with two major
> >differences.  First, chunk type would be a string instead of a 32-bit
> >value.  Second, chunks can contain an arbitrary number of subchunks, which
> >of course can contain subchunks themselves.
>
>   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)?

> >At the end of each chunk is a checksum, as well as a close-chunk marker.
> >The purpose of the close-chunk marker is to help recover in case of
> >corruption; if no corruption is detected, the close-chunk marker is
> >ignored.
>
>   This is a common technique in many file 

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

[Leonard Rosenthol]

At 6:01 PM -0700 8/8/03, Nathan Carl Summers wrote:
Let us start with an existing graphics format, for inspiration if nothing
else.
	OK.


The format I chose is PNG, because it is arguably the best existing
lossless portable graphics format available.
	Well, I would argue that TIFF has the "crown"...

	However, PNG is an excellent standard, regardless.


4 capable of representing trees and graphs
	Trees, yes - for things like layers.   But why a graph??


5 recoverable from corruption
6 fast random access of data
9 fast loads and saves
10 compact
	Good goals, but not a requirements.  Perhaps you should 
separate those two things out...

	And I can think of other goals that I'd like to see:

* incremental update
just update a single layer w/o rewriting the whole file!
* rich metadata
(this may be your 7, but needs to be spelled out)

PNG certainly supports 1,2,6,7,9,10, and 11.  Let us examine the other
issues in more detail.
	I would argue that PNG doesn't do 7 - it has no native 
support for CMYK, for example.  (but yes, it does RGB,  Gray and 
indexed).

	And for comparison, I would offer that TIFF does the same 
list and REALLY does 7, including CMYK, Lab, ICC and Spot color 
spaces.   It's extensibility is similar to PNG (in fact, PNG's chunks 
were modelled on TIFF chunks).



A pure XML format, by way of comparison, would fulfill requirements
1,2,3,4,7, and 8.
	I'd add 9, just being in XML doesn't mean it can't be fast.


 Requirement 5 in practice would be difficult to fulfill
in a pure XML format without hand-hacking, which is beyound the skills of
most users.  A zlib-style compression step could make some progress
towards 10.
	But gzipping the entire XML block would then pretty make 6 
impossible unless you want to seriously increase in-memory 
requirements.


An archive with XML metadata and png graphical data, on the other hand,
would satisfy requirements 1,2,3,4,7,8, and 11.
	An archive (zip, tar, ar) with XML metadata plus raster image 
data (ie. my previous proposal) would meet 1,2,3,4,6,7,8,10,11.   5 & 
10 are related to the archive format of choice since some are better 
at these than others.  But yes, I suspect that it would probably be a 
bit slower.



Requirement 6 is
fulfilled for simple images, but for more complex images XML does not
scale well, since every bite from the begining of the XML file to the
place in which the data you are interested in is.
	But the XML is just a "catalog" of what's in the archive (at 
least in my proposal).  So you read the catalog up front and then use 
it to quickly find the part of the archive you want and viola - fast 
random access to data.


It seems like all we have to do is combine the strengths of PNG and the
strengths of XML to create a format that satisfies our requirements.  What
we really need is not an extensible text markup language, but an
extensible graphics markup format.
	That's what TIFF and PNG were designed for.


Portable XCF would use a chunk system similar to PNG, with two major
differences.  First, chunk type would be a string instead of a 32-bit
value.  Second, chunks can contain an arbitrary number of subchunks, which
of course can contain subchunks themselves.
	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.


At the end of each chunk is a checksum, as well as a close-chunk marker.
The purpose of the close-chunk marker is to help recover in case of
corruption; if no corruption is detected, the close-chunk marker is
ignored.
	This is a common technique in many file formats for 
corruption detection.  It works.


One of the major advantages of this hybred technique is that if an
implementation does not understand or is not interested in a particular
chunk, it can seek to the next chunk without having to read or parse any
of the data in-between.
	How does it do that?  How do you find "start of chunk" 
without a catalog?  How do you get random access to a particular 
chunk w/o a catalog?


image data chunks should use png-style adaptive predictive compression.
They should also use adam-7.
	Great - but that's not specific to a file format - we can do 
that anywhere...

Leonard
--
---
Leonard Rosenthol
 
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

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

[Leonard Rosenthol]

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
 
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer