Re: [Gimp-developer] Re: [CinePaint-dev] GIMP GBR format spec

2003-07-11 Thread pcg
On Thu, Jul 10, 2003 at 04:08:21PM +0200, Sven Neumann [EMAIL PROTECTED] wrote:
 in such an approach and I am sure that not many XML parsers will like
 CDATA blocks of several megabytes.

_all_ xml parsers cope with cdata blocks of several megabytes.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED]  |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Re: [CinePaint-dev] GIMP GBR format spec

2003-07-11 Thread Leonard Rosenthol
At 12:04 PM +0200 7/11/03, Marc wrote:
On Thu, Jul 10, 2003 at 04:08:21PM +0200, Sven Neumann [EMAIL PROTECTED] wrote:
 in such an approach and I am sure that not many XML parsers will like
 CDATA blocks of several megabytes.
_all_ xml parsers cope with cdata blocks of several megabytes.

	But the fact is that you're going to end up having to Base64 
encode all the image data - which will blow the physical file size 
WAY out of proportion.  And if don't do that (ie. attempt to leave in 
binary data), then you are violating the spirit of XML's design goals.

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


Re: [Gimp-developer] Re: [CinePaint-dev] GIMP GBR format spec

2003-07-11 Thread Sven Neumann
Hi,

Leonard Rosenthol [EMAIL PROTECTED] writes:

   But the fact is that you're going to end up having to Base64
 encode all the image data - which will blow the physical file size WAY
 out of proportion.  And if don't do that (ie. attempt to leave in
 binary data), then you are violating the spirit of XML's design goals.

That's why we dropped the idea of embedding the image data in XML.

XML is very well suited to describe the structure of a multi-layered,
multi-framed image/animation and it can be used perfectly to embed
meta information as well as vector layers, paths and the like. XML
namespaces make it easy to add application-specific extensions
later. As you can see, the format I imagine here is not really GIMP
specific. It could serve as a general exchange format for complex
images.

We discussed to bundle one XML file with a set of files that store the
image data. These files would preferably be known image formats or
perhaps even strict subsets of known image formats. That could be PNG
for example but I'm not sure if PNG would suit our needs for higher
bitdepths and the like. Most likely we will need a different format
for the actual image data.

I would suggest that these files are then put together in an ar
archive. Such an uncompressed archive has the advantage that the XML
metadata can easily be extracted.

As you can see all this is very rough and not clearly layed out. It's
a vague idea and it will need a lot of work to specify such a format
in detail.


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


Re: [Gimp-developer] Re: [CinePaint-dev] GIMP GBR format spec

2003-07-11 Thread Nathan Carl Summers
On Fri, 11 Jul 2003, Leonard Rosenthol wrote:

   But the fact is that you're going to end up having to Base64
 encode all the image data - which will blow the physical file size
 WAY out of proportion.  And if don't do that (ie. attempt to leave in
 binary data), then you are violating the spirit of XML's design goals.

Honestly I can't think of a way to put image data into a file format at
all that wouldn't violate SGML's design goals.  XML may differ in some
aspects from SGML, but the fact is that SGML was designed to be a markup
language for documents written in human languages, and the design
decisions that created that also make storing binary in *ML cumbersome.

GIMP needs a file format that is extensible, and a native representation
for tree structures is essential, but there are plenty of ways to do this
other than the XML method.  Storing images, which ar almost all binary
data, in true XML is a lesson in inefficiency.

Oh wait, I take it back.  I can think of a image format that retains the
spirit of XML:

gimpimage
 commentCreated by the GIMP!/commment
 layers colorspace=rgb bitdepth=8
  layer width=6 height=6
   row
pixel r=127 g=127 b=127 /
pixel r=127 g=127 b=127 /
pixel r=127 g=127 b=127 /
pixel r=127 g=127 b=127 /
pixel r=127 g=127 b=127 /
pixel r=127 g=127 b=127 /
   /row
   row
.
.
.
   /row
  /layer
 /layers
/gimpimage

Determining whether this is a good format is left as an exercise to the
reader.

Rockwalrus

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


Re: [Gimp-developer] Re: [CinePaint-dev] GIMP GBR format spec

2003-07-11 Thread Leonard Rosenthol
At 06:34 AM 7/11/2003 -0700, Nathan Carl Summers wrote:
Oh wait, I take it back.  I can think of a image format that retains the
spirit of XML:
gimpimage
 commentCreated by the GIMP!/commment
 layers colorspace=rgb bitdepth=8
  layer width=6 height=6
   row
pixel r=127 g=127 b=127 /
pixel r=127 g=127 b=127 /
pixel r=127 g=127 b=127 /
pixel r=127 g=127 b=127 /
pixel r=127 g=127 b=127 /
pixel r=127 g=127 b=127 /
You know what is really scary about that...

About 6 months ago, someone posted to the SVG mailing list a 
proposal for an XML-based raster image format that pretty much exactly 
that...And he was SERIOUS about it!!!

Leonard 

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


[Gimp-developer] Re: [CinePaint-dev] GIMP GBR format spec

2003-07-10 Thread Robin Rowe
David,

 As a proposal for a modification which would bring back
 compatibility, we could expand the header by 4 bytes to include
 bit depth (8 or 16), which could then be factored into the load
 routines of both our apps (we would crush 16 bit nbrushes down to
 8 bits, and you would expand 8 bit brushes to 16 bits). As a file
 format change, it would allow is backward compatibility, since
 the format changes nothing in the other header fields.

We're open to that. However, until someone volunteers and sends us a patch,
we have no one ready to take that effort when our format is about to be
replaced anyway.

 The GIMP Paintbrush File Format Version 2 (.gbr)
 

 HEADER
 --

 Bytes 0  - 3:  header_size:
 Type: 32 bit unsigned int
 Value: size of brush header (28) + length of brush name

 Bytes 4  - 7: version
 Type: 32 bit unsigned int
 Value: The file format version. Currently

 Bytes 8  - 11: width
 Type: 32 bit unsigned int
 Value: Brush width

 Bytes 12 - 15: height
 Type: 32 bit unsigned int
 Value: Brush height

 Bytes 16 - 19: bytes
 Type: 32 bit unsigned int
 Value: Colour depth of brush.
 1 = greyscale, 4 = RGBA

 Bytes 20 - 23: magic_number
 Type: 32 bit unsigned int
 Value: GIMP brush magic number.
 ('G'  24) + ('I'  16) + ('M'  8) + 'P'

 Bytes 24 - 27: spacing
 Type: 32 bit unsigned int
 Value: Default spacing to be used for brush. Percentage
 of brush width.

 Bytes 28 - (header_size - 28):
 Type: char *
 Value: UTF-8 string - name of brush


 BODY
 
 Size: width * height * bytes
 Type: uchar *
 Value: Pixel values (row-first) for brush

Thanks, appreciate the docs!

To return the favor, enclosed is the spec for CPX that I posted in June. It
is so new it hasn't made it onto our web page docs yet. For clarification,
since my preliminary spec was rather terse, the data blob in CPX is a raw
write of the raster like the PPM P6 format. The CPX format was inspired by
the simplicity of PPM, but with the enhancement of XML tags. Like PPM, all
CPX tags are text but raster data is binary. See at the bottom below.

 it would be incorrect to say that we don't identify our team.

I can clarify my meaning, although it seems a moot point. Some GIMP
developers are identified in internal documents within the source code, as
you correctly point out. However,when I asked for a list of developers on
the GIMP list I was told those documents were too inaccurate to be trusted.
It was suggested I could get the names of the GIMP developers by grepping
the check-in names from GIMP CVS -- which seemed a bit of bother -- but I
took the effort to do so anyway. I offered to give that list back to GIMP so
they could post a better public list of developer acknowledgements. The
response was that no new list should be posted by GIMP until it was perfect,
and that my list was inaccurate because Sven and others often check in
patches on behalf of others. I was also told my help wasn't needed.

FYI, using the best information I could gather, we have a list on our web
site recognizing the GIMP developers.

http://cinepaint.sourceforge.net/people/gimp.html

Cheers,

Robin
---
[EMAIL PROTECTED]   Hollywood, California
www.CinePaint.org   Free motion picture and still image editing software

- Original Message -
From: Robin Rowe [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, June 07, 2003 3:11 PM
Subject: [CinePaint-dev] cpx file type


 Hi. Just FYI, creating a new image format called CPX (CinePaint XML).

 This format will be similar in simplicity to PPM but more flexible using
XML
 tags. Both spec and code will be made available.

 A 640x480 8-bit image file example.cpx would be laid out something like
 this:

 CPX
 IMG width=640 height=480 depth=8u raster=RGB compress=none bytes=921600
 data=...[921,600 raw bytes]...

 'depth' may be 8u|16u|16f-ilm|16f-rnh|32f
 'raster' may be RGB|RGBA|RGBAZ or alternatively 'planes' with the same
 choices

 A lot more features could be added later. This is just to let everyone
know
 this is in the works and coming maybe in July.

 Cheers,

 Robin
 --
-
 [EMAIL PROTECTED]   Hollywood, California
 www.CinePaint.org   Free motion picture and still image editing software


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


Re: [Gimp-developer] Re: [CinePaint-dev] GIMP GBR format spec

2003-07-10 Thread Christopher Curtis
Sven Neumann wrote:

We actually had something else in mind but since you don't seem to be
interested I won't waste my time explaining our ideas.
It is very sad to see that Sven thinks that Robin Rowe is the only 
person to whom his ideas should be told.  Pity the rest of the GIMP 
developers (current and future) who might like to comment on it.

Christopher

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


Re: [Gimp-developer] Re: [CinePaint-dev] GIMP GBR format spec

2003-07-10 Thread Sven Neumann
Hi,

Christopher Curtis [EMAIL PROTECTED] writes:

 We actually had something else in mind but since you don't seem to be
 interested I won't waste my time explaining our ideas.

 It is very sad to see that Sven thinks that Robin Rowe is the only
 person to whom his ideas should be told.  Pity the rest of the GIMP
 developers (current and future) who might like to comment on it.

We will certainly write down more about this later but at the moment I
focus on the release and on the developer conference. The ideas we had
so far are quite rough but I will try to summarize them after the
conference. I'm only willing to spend time on this right now if
someone expresses actual interest.


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