Re: [Gimp-developer] GimpCon dates
Carol wrote: perhaps Mr. Neary can publish a list of people he will allow to attend so that those people who are not allowed will not waste their time? Open to the public means open to the public. I'd love you to come, but not as [EMAIL PROTECTED] Dave. -- Dave Neary [EMAIL PROTECTED] Lyon, France ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon dates
On Fri, Sep 16, 2005 at 08:31:47PM +0200, David Neary wrote: Carol wrote: perhaps Mr. Neary can publish a list of people he will allow to attend so that those people who are not allowed will not waste their time? Open to the public means open to the public. I'd love you to come, but not as [EMAIL PROTECTED] it is tattooed on my rear end now, so i invite you to divert your eyes from my netherquarters. carol ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GimpCon dates
Hi,
The dates for the next GimpCon are march 17h-18th-19th 2006.
Please have a look at http://wiki.gimp.org/GimpCon and confirm if you
will come as soon as possible,
Cheers,
DindinX
--
[EMAIL PROTECTED]
D[4],n,d,*T,l,L;main(i,v)char**v;{if(i3)return;L=atoi(v[1]);l=atoi(v[2]);T=
alloca(4*L*l);while(nL*l){for(i=D[d];i(d1?l:L)-D[d^2];i++)T[!d?i+L*D[1]:d
2?L-D[2]-1+L*i:d3?-i-1+L*(l-D[3]):*D+L*(l-i-1)]=++n;D[d=++d3]++;}while(n)
printf(--n%L?%5d:%5d\n,*T++);}
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon dates
Hi!
As I said, I am looking forward to come. I could give a talk about
siox - whatever people want to hear about it.
Regards,
Gerald
On 9/13/05, David Odin [EMAIL PROTECTED] wrote:
Hi,
The dates for the next GimpCon are march 17h-18th-19th 2006.
Please have a look at http://wiki.gimp.org/GimpCon and confirm if you
will come as soon as possible,
Cheers,
DindinX
--
[EMAIL PROTECTED]
D[4],n,d,*T,l,L;main(i,v)char**v;{if(i3)return;L=atoi(v[1]);l=atoi(v[2]);T=
alloca(4*L*l);while(nL*l){for(i=D[d];i(d1?l:L)-D[d^2];i++)T[!d?i+L*D[1]:d
2?L-D[2]-1+L*i:d3?-i-1+L*(l-D[3]):*D+L*(l-i-1)]=++n;D[d=++d3]++;}while(n)
printf(--n%L?%5d:%5d\n,*T++);}
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
--
Gerald Friedland Raum 164 Tel: ++49 (0)30/838-75134
Freie Universität Berlin Takustr. 9 http://www.gerald-friedland.org
Institut für Informatik 14195 Berlin [EMAIL PROTECTED]
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon dates
On Tue, Sep 13, 2005 at 12:07:25PM -0700, Carol Spears wrote: On Tue, Sep 13, 2005 at 04:00:58PM +0200, David Odin wrote: The dates for the next GimpCon are march 17h-18th-19th 2006. Please have a look at http://wiki.gimp.org/GimpCon and confirm if you will come as soon as possible, perhaps Mr. Neary can publish a list of people he will allow to attend so that those people who are not allowed will not waste their time? I for one will be honored if you can come. -- [EMAIL PROTECTED] He's not dead, He's electroencephalographically challenged. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon dates
On Tue, Sep 13, 2005 at 09:42:56PM +0200, David Odin wrote: On Tue, Sep 13, 2005 at 12:07:25PM -0700, Carol Spears wrote: On Tue, Sep 13, 2005 at 04:00:58PM +0200, David Odin wrote: The dates for the next GimpCon are march 17h-18th-19th 2006. Please have a look at http://wiki.gimp.org/GimpCon and confirm if you will come as soon as possible, perhaps Mr. Neary can publish a list of people he will allow to attend so that those people who are not allowed will not waste their time? I for one will be honored if you can come. thank you. :) this is the first smile i have had this week which was not about the tidyness of gimp workspaces. carol ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GIMPCon 2004 in Norway
Hello gimp lists, We are getting close to have the GIMPCon 2004 in Norway and I would like to say that I am going to GIMPCon, at the same time I would like to ask who else is going to Norway? So now to the point of this mail. It would be good if we could have a small meeting conserning the website(s) at GIMPCon. This would help alot now when the websites are being worked on really hard. At the moment I haven't had time to setup any list of things we should discuss but it would be really good to have this kind of meeting now. To my questions then: Who will attend at the meeting? Any suggestions from the outside about problems conserning the website? I hope this mail is at least a little informative and that people will join us at GIMPCon. I will later create a little list on my own about things that I find would be good to discuss at the conference and then announce it here on this list. Regards, -- Niklas Mattisson scizzoNOSPAM-at-sector7-dot-nu ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMPCon
Hi, Henrik Brix Andersen wrote: Well, I think we should discuss the road map (or whatever you prefer to call it) for the release to come after 2.2 (2.4? 3.0?). We need to talk about stuff like PDB rewrite, GEGL integration, next generation XCF, plug-in policies etc. Is anyone actually working on a requirements list for a new PDB? It would be nice to know what exactly we expect from it, and whether the PDB should be refactored or re-written with gegl nodes in mind. Also, is there any way currently to have standalone out-of-process or threaded GeglNodes? As to the next generation XCF, pippin has a pretty good file format which he is currently using with libgggl and bauxite, currently there is no competing format around. For gegl migration, there has been quite a bit of talk already. Last I heard there were two ideas, which can generally be called data first or structure first - either we keep the same image data objects, and start using GeglGraphs for compositing first, then start changing data structures (I guess that going this way means turning GeglNodes into more or less an interface which delegate operations to a GIMP data based implementation, or to a gegl data based implementation, then eventually killing off the GIMP based ones)., or we change the data structures first (which implies that the data structures and the methods for accessing them are finished) and once we have the data in gegl, start migrating the internal compositing engine and plug-ins to GeglNodes. There was no concrete decision out of the last conversation we had about this. Dan and Calvin's proposal to Mark Shuttleworth on bounties will help lay down tracks here, but it's currently looking unlikely that gegl will be ready to integrate into the GIMP this Sumemr at its current rate of change. Dan has said he'll have less time to spend on it from now on, which means that gegl right now needs some people to work on the data structures end. If this doesn't happen soon, Calvin's proposition of migrating the rendering framework first, and following up with the data structures when they're done, will look a lot more attractive. I recently posted a link to a requirements document that Lourens Veen did for plug-in distribution, but I haven't seen any comments on it. Again, this is one of those things that needs someone actually working on it, rather than just saying to ourselves that needs to be done. I know yosh was thinking about this - perhaps he has comments? We also need to talk about the GIMP Foundation and how it fits in with GIMP development. I think that this will be resolved before GUADEC. I hope it will be resolved by the end of this week... Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMPCon
Dave Neary wrote: Hi all, In a mail I just sent off, I said we should have some information about what we plan to do at GIMPCon... What do we plan to do at GIMPCon? I'd like to say that, for the record I won't be able to attend GimpCon. I simply don't have the time or money at the moment (and the soonest I would is months and months away). And in case anyone missed my previous PS, I'm quite busy with my real life atm and have found myself quite without much time to put into The GIMP. Both setting up the bounties and the Foundation are things that are consuming all my free time. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GIMPCon
Hi all, In a mail I just sent off, I said we should have some information about what we plan to do at GIMPCon... What do we plan to do at GIMPCon? Cheers, Dave. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMPCon
Hi, On Wed, 2004-04-28 at 11:06, Dave Neary wrote: In a mail I just sent off, I said we should have some information about what we plan to do at GIMPCon... What do we plan to do at GIMPCon? Well, I think we should discuss the road map (or whatever you prefer to call it) for the release to come after 2.2 (2.4? 3.0?). We need to talk about stuff like PDB rewrite, GEGL integration, next generation XCF, plug-in policies etc. We also need to talk about the GIMP Foundation and how it fits in with GIMP development. These are the topics that come to mind right now - I am sure there a lots more... Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon 2004 (follow-up)
On Fri, 21 Nov 2003 12:00:51 +0100, David Neary [EMAIL PROTECTED] wrote: So far there are 5 propositions in various stages of development, each of which has some + points and some - points. 1) GUADEC 2) Lyon 3) London 4) Dublin 5) Chemnitz Are there others? We need volunteers. I could also mention FOSDEM (Free Open Source Software Developers' European Meeting) in Brussels. The 4th edition will take place on the 21st and 22nd of February 2004. Some GIMP people have been there in the previous years, such as jimmac giving some great demos (as usual) and he will do it again for the 2004 edition. Plus: - Brussels is easy to access by train or plane. FOSDEM is organized on the university campus, which is well served by bus, subway, etc. - It should not be too difficult to reserve a room for the GIMP developers. Network access and other facilities will be available. - Although we would have to organize the accomodations, the FOSDEM site lists several decent youth hostels that should be suitable. Minus: - Not much time between now and the end of February. And I don't think that they would shift FOSDEM to June only for us. ;-) - Only two days (Saturday and Sunday). It may be difficult to extend our meeting before or after that week-end because most of the rooms will be booked for courses. Although from my point of view, two days for gimpcon2004 would be enough so I wouldn't have to take days off of work (except for recovering, maybe). - May be a bit crowded. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GimpCon 2004 (follow-up)
I want to start a new thread to get this discussion (which I consider important) back on track. LOCATION So far there are 5 propositions in various stages of development, each of which has some + points and some - points. 1) GUADEC 2) Lyon 3) London 4) Dublin 5) Chemnitz Are there others? We need volunteers. FACILITIES What facilities do we need? I've been working (in my head) with figures of 20-30 people, needing fairly liberal access to conference facilities and computer network, preferably staying with LUGgers, but perhaps in a hotel. MONEY Who will manage the money side of things? We need someone who is good with numbers, to organise a few people to do fundraising. DATE When is the earliest we could meet? When's the latest reasonable date? I like late June, I think June/July/August is our target area. Any comments? Like I said, feedback is *required* for this. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon 2004 (follow-up)
Hi, On Fri, 2003-11-21 at 12:00, David Neary wrote: I want to start a new thread to get this discussion (which I consider important) back on track. Good idea. LOCATION So far there are 5 propositions in various stages of development, each of which has some + points and some - points. 1) GUADEC 2) Lyon 3) London 4) Dublin 5) Chemnitz Are there others? We need volunteers. Personally I think it would be best to piggy-back on an existing event given that the organizers wouldn't mind, of course. This would give us the benefit of an existing infrastructure. FACILITIES What facilities do we need? I've been working (in my head) with figures of 20-30 people, needing fairly liberal access to conference facilities and computer network, preferably staying with LUGgers, but perhaps in a hotel. 20-30 people sounds right to me. We need a conference room or similar (the GimpTent at GIMPCon 2003 wasn't exactly a conference room, but it filled our need perfectly) and access to the internet. Of course we need a place/places to sleep as well, but anything from a tent to a hotel would fit this need. MONEY Who will manage the money side of things? We need someone who is good with numbers, to organise a few people to do fundraising. It would be ideal if The GIMP Foundation was a reality when we start the fund-raising. We could then use the conference to evaluate the steps taken to raise funds - and perhaps improve the process. DATE When is the earliest we could meet? When's the latest reasonable date? I like late June, I think June/July/August is our target area. Any comments? I agree. I would say late June, July or early August. Sincerely, ./Brix -- Henrik Brix Andersen [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon 2004 (follow-up)
Hi Henrik, thanks for the feedback. Henrik Brix Andersen wrote: LOCATION Personally I think it would be best to piggy-back on an existing event given that the organizers wouldn't mind, of course. This would give us the benefit of an existing infrastructure. In this case, what IT events do people know of in the timescale we're looking at? GUADEC obviously fits, the Chemnitz event is a little early for my tastes, but is certainly an option. What other events are there that people know about? MONEY Who will manage the money side of things? We need someone who is good with numbers, to organise a few people to do fundraising. It would be ideal if The GIMP Foundation was a reality when we start the fund-raising. We could then use the conference to evaluate the steps taken to raise funds - and perhaps improve the process. I don't think we can rely on the foundation existing in time. And even if we did, the foundation would need a treasurer to be the person In Charge. In either case, we need someone to say they'll take responsibility for money. It might well be reasonable that that person then become the treasurer of the foundation. Are there any candidates? Personally I think it would be a good idea to separate the organisation of physical structures from fundraising - they're 2 very different jobs, and teach represents a considerable workload. If one person does both, he's likely to be overloaded with work. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon 2004 (follow-up)
On 21 Nov 2003, at 12:00, David Neary wrote: I want to start a new thread to get this discussion (which I consider important) back on track. LOCATION So far there are 5 propositions in various stages of development, each of which has some + points and some - points. 1) GUADEC 2) Lyon 3) London 4) Dublin 5) Chemnitz Are there others? We need volunteers. Sven suggested (IIRC), Hacking Extreme http://www.hex2005.org, the follow-up event to Hackers At Large in 2001, but that is of course still more than one and a half year away. The advantage, from what I understood, and IIRC, was that it tied into a networked camping event. FACILITIES What facilities do we need? I've been working (in my head) with figures of 20-30 people, needing fairly liberal access to conference facilities and computer network, preferably staying with LUGgers, but perhaps in a hotel. I did not mind the camping thing, which is an option as long as it's not too cold. -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-user] Re: [Gimp-developer] GimpCon 2004 (follow-up)
Hi, David Neary [EMAIL PROTECTED] writes: In this case, what IT events do people know of in the timescale we're looking at? GUADEC obviously fits, the Chemnitz event is a little early for my tastes, but is certainly an option. What other events are there that people know about? Well, there will probably be LinuxTag again (www.linuxtag.org). It usually takes place in Juli but it's more of a trade fair and thus probably not that well suited. I also think that it would be boring to have the conference in Germany again. I expect that 2004 will see another Hackmeeting but the webpage doesn't mention a date nor a place yet: http://www.hackmeeting.org/2003/history_en Perhaps someone knows more about the plans for 2004. I heard a lot of good things about past Hackmeetings and it would probably fit well. Then, there seems to be a vague plan for a HackSchiff in 2004: http://www.unet.univie.ac.at/~a9900470/cngwiki/wiki.cgi?HackSchiff2004EN The planned route would probably take a few weeks so that would give us enough time for some decent hacking and chatting ;) Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-user] Re: [Gimp-developer] GimpCon 2004 (follow-up)
Hi, Sven Neumann wrote: I expect that 2004 will see another Hackmeeting but the webpage doesn't mention a date nor a place yet: http://www.hackmeeting.org/2003/history_en Perhaps someone knows more about the plans for 2004. I heard a lot of good things about past Hackmeetings and it would probably fit well. Sounds like a definite possibility. Then, there seems to be a vague plan for a HackSchiff in 2004: http://www.unet.univie.ac.at/~a9900470/cngwiki/wiki.cgi?HackSchiff2004EN The planned route would probably take a few weeks so that would give us enough time for some decent hacking and chatting ;) I can't speak for others, but there would be no chance of me taking 3 weeks on a ship this year. Add the cost, and the time to get to Hamburg and from Italy, and I'm voting against this :) Nice idea, though... wish I were still young happygolucky. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GimpCon 2004
Hi all, A while back (quite a while actually) I tried to start a discussion about where we might have next year's GimpCon. There were 2 main ideas - the first is to stage something more or less standalone - 20 odd people turn up somewhere and talk about the GIMP for 4 days. The second is to piggy-back on an existing event, taking advantage of the organisation and financing of the bigger event. I asked for ideas of events, and offers to organise the location for the 20 odd people. I also asked for proposals for dates. Unfortunately, the response was less than I'd expected, which means I probably didn't ask properly :) Today a few of us were talking about this on IRC, and a couple of concrete proposals came up. Well, more sandy-water proposals at the moment... 1) Lyon Myself and David Odin live here, we're both active in the local LUG and might get some organisational help there, David works in a university and has cleared the in principle issue with his boss. We would have some rooms in a university, with access to the university network, and probably guest accounts on the university network. There has been no talk of money, so we don't know how much all this access might cost. Plus: Facilities Minus: Lyon isn't easy to get to, which means higher transport costs. Dates after the 25th of June are best. 2) GUADEC The GNOME Users and Developers Conference is in the process of organising itself for the last week in June; this is about the time that I think it would be good to have a conference (around the time 2.2 comes out), before we break lots of stuff doing a gegl migration. Plus: Everything will be organised. Lots of smart people around. Minus: We're not a GNOME app, so we probably won't get travel expenses paid by the organisers (we can always ask, though - perhaps we can get a Graphics stream added, and have 4 or 5 people give presentations and get expenses that way). Again, Norway's not easy to get to. If we are having problems getting money, sponsorship might be tough (most people liable to sponsor us will also probably be sponsoring GUADEC) 3) London Sven knows some people in London who might be prepared to put in the organisational effort. Plus: London = cheap transport Minus: We don't know what facilities will be available. Other ideas (conferences we could hijack, or places where people would be able to organise stuff for us) are welcome, as well as comments on these. Please note that I have not talked about money at all really... IMHO, we need a someone who will handle the money, and a group of someones who will look for sponsorship. The problem is that we often need somebody, who could be anybody, but everybody thinks somebody will do it, and in the end nobody ends up doing it :) So it would be nice to start naming our somebodies now. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon RFC: Portable XCF
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
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 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] GimpCon RFC: Portable XCF
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 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] GimpCon RFC: Portable XCF
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
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
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 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] GimpCon RFC: Portable XCF
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 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
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
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 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] GimpCon RFC: Portable XCF
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
At 11:42 PM -0700 8/13/03, Manish Singh wrote: Supports IEEE floats, but not float16 (a 32-bit float cut in half). RH 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 Rosentholmailto:[EMAIL PROTECTED] http://www.lazerware.com ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GimpCon RFC: Portable XCF
Several XCF formats have already been proposed; why should I propose another? It seems to me like the existing proposals have all missed the main point. While they have nice properties for certain extreme cases, they miss the boat when it comes to the main point of a graphics format, which is to efficiently store (and load) graphical information. This has lead to proposals that are neither elegant nor simple; instead they are cumbersome, with redundant, and superficial information stored, along with potential for confict between different sections of the file. But rather than detail these problems, let me suggest my own solution. Let us start with an existing graphics format, for inspiration if nothing else. The format I chose is PNG, because it is arguably the best existing lossless portable graphics format available. Before we continue, though, allow me to ennumerate what charactoristics the Gimp native format should possess, in no particular order: 1 lossless 2 portable between architectures and programs 3 extensible 4 capable of representing trees and graphs 5 recoverable from corruption 6 fast random access of data 7 able to support many color depth and spaces 8 able to represent any state that gimp maintains 9 fast loads and saves 10 compact 11 good compression of graphical data PNG certainly supports 1,2,6,7,9,10, and 11. Let us examine the other issues in more detail. Extensablity: PNG supports some degree of extensiblity, but the namespace available is quite small, being only four letters. While we could use the same chunk type name for all of our additions, say 'GIMP', and then have the first field in the chunk contain which kind of chunk it really is. But this is an inelegant hack. Capablitity of representing trees and graphs: Obviously, png's minimal extension facilities could be used to implement chunks that envelope an entire tree of chunks, but this would be difficult to reconsile with PNG's current order-based approach to metadata association, and would be awkward for GIMP-aware and non-GIMP-aware PNG readers alike. Corruption Recovery: PNG has good corruption detection, but little to facilitate corruption recovery. Representation of GIMP state: see extensibility. While PNG's faults aren't serious, we can do better. A pure XML format, by way of comparison, would fulfill requirements 1,2,3,4,7, and 8. 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. An archive with XML metadata and png graphical data, on the other hand, would satisfy requirements 1,2,3,4,7,8, and 11. 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. 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. Such a format would bear strong resemblence to both PNG and XML. 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. 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. 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. image data chunks should use png-style adaptive predictive compression. They should also use adam-7. An example is worth a thousand words. Here is a simple RGB image with two layers (one with a parasite) and a comment. This is just a rough sketch of what it would look like: (labels in all capitial letters are for illustrative purposes and do not take up any space in the file.) FILE HEADER: portable xcf file version major - 1 byte version minor - 1 byte CHUNK: chunk start, optional - 2 byte bitmask with some png-like flags xcf-comment total size of chunk and subchunks - 4 bytes size of chunk - 4 bytes This is the comment chunk end (flags) - 2 bytes xcf-comment 1 (subchunk depth) - 1 byte crc32 - 4bytes CHUNK: chunk start, manditory - 2 bytes xcf-layerstack total size - 4 bytes size - 4 bytes SUBCHUNK: chunk start, manditory - 2 bytes xcf-colorspace total size - 4 bytes size - 4 bytes xcf-sRGB chunk end (flags) - 2 bytes xcf-colorspace 2 (depth) - 1 byte crc32 - 4 bytes SUBCHUNK: chunk start, manditory - 2 bytes xcf-layer total
Re: [Gimp-developer] GimpCon RFC: Portable XCF
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
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 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
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 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] GimpCon RFC: Portable XCF
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. If the old versions are
Re: [Gimp-developer] GimpCon RFC: Portable XCF
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 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] GimpCon RFC: Portable XCF
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 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
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). RH 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 RH 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
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 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] GimpCon RFC: Portable XCF
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). RH 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
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] http://www.lazerware.com ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon RFC: Portable XCF
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 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] GimpCon RFC: Portable XCF
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 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] GimpCon RFC: Portable XCF
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 formats for corruption detection. It works. One of the major advantages of this hybred technique is that if an implementation does
