On Mercredi 01 Mars 2006 18:23, Bart wrote:

On the Blender-Wiki i found two links about the PSD format. It would be cool if we can make Gimp more compatible with the PSD format (the same conflict like OOO has with *.doc format - not lovely but needed ):

In the same way, is the XCF format specifications available somewhere ? I asked the developer of a non-free software to add XCF output support to his soft: he is ok, as long as he can have the complete specifications...

Thanks,

Von: Bart

Frédéric schrieb:

In the same way, is the XCF format specifications available somewhere ? I asked the developer of a non-free software to add XCF output support to his soft: he is ok, as long as he can have the complete specifications...

Up to now, there were none and using XCF in third-party apps has been discouraged because of this - the format might change without notice. AFAIK this hasn't changed yet.

With "make Gimp more compatible with the PSD format" i didn't prefer changing the Gimp-Format more then have a better PSD import and export filter :)

I'm not sure if I understand this correctly. Maybe you could rephrase it?

HTH, Michael

Le Jeudi 2 Mars 2006 13:08, Michael Schumacher a écrit :

Up to now, there were none and using XCF in third-party apps has been discouraged because of this - the format might change without notice. AFAIK this hasn't changed yet.

Ok, I understand. So, Gimp really needs a good import/export PSD format filter.

On Thursday, March 2, 2006, 13:08:04, Michael Schumacher wrote:

Up to now, there were none and using XCF in third-party apps has been discouraged because of this - the format might change without notice. AFAIK this hasn't changed yet.

Corel PhotoPaint 12 has some support for XCF format though.

On 3/2/06, Bart wrote:

8bi files working on Mac and Win only (as far as i know).

*cough* http://tml-blog.blogspot.com/2006/02/photoshop-filters-in-gimp-on-linux.html *cough*

Alexandre

Alexandre Prokoudine writes:
> > 8bi files working on Mac and Win only (as far as i know).

> *cough* http://tml-blog.blogspot.com/2006/02/photoshop-filters-in-gimp-on-linux.html

pspi handles only .8bf files ("filter" plug-ins), though. (It would be possible extend it to handle file format plug-ins, too, for some value of "possible".)

--tml

Le Vendredi 3 Mars 2006 02:18, Campbell Barton a écrit :

Hey Gimp dev's (by the way, how many gimp dev's are there?)

I'm afraid I'm not :o(

it often annoys me that people value a program based on its support for a foreign format.
PS Dev's dont waist time supporting other apps so why should we? (I know, cos Gimp isnt the standard.... :/ )

Yes and no. I think that Gimp should handle correctly PSD formats, because a lot of people need this, but XCF spec should also be available. This way, other programs could implement it. I don't beleive that PS will, but as I said, I know some developers who are ok to add XCF support in their program.

Gimp is OpenSource, and its file format should be open too. And so, well documented. Even if it still evolves, it is possible to make something without breaking previous rules when adding new features. Maybe by providing an complete API, like HDF does.

Supporting stuff like layer effects is okay, but Im guessing its not a small task...

I would love to see layer effects too ;o)

Frédéric (frederic.mantegazza@gbiloba.org) wrote:

Gimp is OpenSource, and its file format should be open too. And so, well documented. Even if it still evolves, it is possible to make something without breaking previous rules when adding new features. Maybe by providing an complete API, like HDF does.

Actually the current XCF format has its limitations and we are not really convinced that it is a really good (tm) format, it has some pretty severe limitations.

There were plans to work on a next-generation XCF resolving these issues. I too see the need for a widely accepted exchange format for multilayered images with a lot of additional information, but the current XCF format does not meet the "good enough" criteria.

The main documentation for XCF is in the source unfortunately, and for the reasons above we don't encourage support for XCF.

Bye, Simon

Campbell Barton (cbarton@metavr.com) wrote:

Hey Gimp dev's (by the way, how many gimp dev's are there?)

well, that depends on how you define "gimp developer" - there are about 180 people listed in the AUTHORS file. The listed persons have at least once added something to the GIMP in the last 10 years.

However, this number reflects the number of *active* developers very badly: this year 16 people have committed something to the gimp core, 10 more than once and 3 people more than five times[*].

So, there is no army of developers eager waiting for stuff to do, to the contrary - we really could use some more people contributing regularily.

Bye, Simon

[*] These numbers unfortunately ignore the people that are helping tremendously by giving good and detailed bug reports, sometimes with good patches. Thanks to you all, keep up the good work!

Le Jeudi 2 Mars 2006 15:18, Simon Budig a écrit :

So, there is no army of developers eager waiting for stuff to do, to the contrary - we really could use some more people contributing regularily.

I think it is better to have a few developers, with a lot of time to spend on Gimp, rather than a lot of developers with no time...

But it is also true that Gimp lacks some developers :o(

On 3/2/06, Simon Budig wrote:

There were plans to work on a next-generation XCF resolving these issues. I too see the need for a widely accepted exchange format for multilayered images with a lot of additional information, but the current XCF format does not meet the "good enough" criteria.

Could TIFF 6.0 possibly be a start? Or do you imagine an XML with binary data inside? I'm actually interested in raising such a file format, but I don't know if developers themselves are interested. if no, there is no point to develop something that is not going to be supported by anyone.

However, I started http://create.freedesktop.org/wiki/index.php/General_multilayered_bitmap_exchange_format If anyone is keen to contribute, go ahead.

Alexandre

On Thursday, March 2, 2006, 15:54:12, Alexandre Prokoudine wrote:

Or do you imagine an XML with
binary data inside?

Isn't XML limited to text only?

On 3/2/06, jernej@ena.si wrote:

On Thursday, March 2, 2006, 15:54:12, Alexandre Prokoudine wrote:

Or do you imagine an XML with
binary data inside?

Isn't XML limited to text only?

IIRC, it's not. At least when you save an SVG from Adobe Illustrator with a drop shadow effect, it save a PNG with a shadow inside.

Of course, OpenDocument document structure (ZIP archive with multiply files inside) could be followed.

Alexandre

Le Jeudi 2 Mars 2006 16:10, jernej@ena.si a écrit :

Or do you imagine an XML with
binary data inside?

Isn't XML limited to text only?

What about the solution like OpenDocument one, where the files are in fact archives, with several files inside?

On 3/2/06, Frédéric wrote:

Isn't XML limited to text only?

What about the solution like OpenDocument one, where the files are in fact archives, with several files inside?

Sure, I like this approach

Alexandre

On 3/2/06, Boudewijn Rempt wrote:

I tried to mail the gimp developers list, but I guess my mail is being held up somewhere. I wanted to propose cooperating on getting an OASIS OpenDocument spec done for layered raster images.

Is there some proposal already?

Alexandre

On Thu, Mar 02, 2006 at 05:54:12PM +0300, Alexandre Prokoudine wrote:

There were plans to work on a next-generation XCF resolving these issues. I too see the need for a widely accepted exchange format for multilayered images with a lot of additional information, but the current XCF format does not meet the "good enough" criteria.

Could TIFF 6.0 possibly be a start? Or do you imagine an XML with binary data inside? I'm actually interested in raising such a file format, but I don't know if developers themselves are interested. if no, there is no point to develop something that is not going to be supported by anyone.

However, I started http://create.freedesktop.org/wiki/index.php/General_multilayered_bitmap_exchange_format If anyone is keen to contribute, go ahead.

Have a look at a long discussion held about two years ago on this list:

http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-August/009642.html

http://comments.gmane.org/gmane.comp.video.gimp.devel/2692?set_lines=100000

Bye, Tino.

On 3/2/06, Alexandre Prokoudine wrote:

On 3/2/06, jernej@ena.si wrote:

On Thursday, March 2, 2006, 15:54:12, Alexandre Prokoudine wrote:

Or do you imagine an XML with
binary data inside?

Isn't XML limited to text only?

IIRC, it's not. At least when you save an SVG from Adobe Illustrator with a drop shadow effect, it save a PNG with a shadow inside.

You save binary data inside XML by encoding it as base64 (!!!!!) not very fast or efficient.

Of course, OpenDocument document structure (ZIP archive with multiply files inside) could be followed.

Yes, this sounds much more sensible.

John

On 3/2/06, Boudewijn Rempt wrote:

No, I wanted to start on it after I get Krita 1.5 out of the door -- and I didn't want to do this alone. There's no sense in starting an OpenDocument standard without buy-in from the major free raster image application.

There has been a discussion on exporting to XCF from Inkscape since yesterday or the day before yesterday. These guys might be interested as well. Can speak for myself only :)

(I do wish this mailing list would let my messages through, though.)

It does, at least now ;)

But I think then further discussion should be held in some other mailing list, either CREATE or OASIS. Opinions?

Alexandre

Von: Campbell Barton

Supporting stuff like layer effects is okay, but Im guessing its not a small task...

Things like this are already listed in Bugzilla http://bugzilla.gnome.org/show_bug.cgi?id=79025

The best way to start browsing Bugzilla for GIMP stuff is http://bugzilla.gnome.org/browse.cgi?product=GIMP

BTW- One feature Id be interested in seeing is layers with linked bitmap data, so you could move thenm about but theyd share pixel info. have been in a number of situations whis would be nifty, also cut down filesize.

Something like
http://bugzilla.gnome.org/show_bug.cgi?id=143138 or something else?

This proposal hasn't been pursued very far yet, as you can see.

HTH, Michael

On Thu, Mar 02, 2006 at 03:30:03PM +0000, John Cupitt wrote:

Of course, OpenDocument document structure (ZIP archive with multiply files inside) could be followed.

Yes, this sounds much more sensible.

As a concept, yes. Actually using ZIP is a stupid decision, and I wonder what the rationale for using it was.

-Yosh

Okay, so it turned out that I was still subscribed under an old email address, but my mailers sends everyone with the current one. Anyway, my fault, and I would like to thank Manish for helping me out of my bewilderment. What I wanted to propose & work on after my 1.5 release is the following:

Cooperating on get an OpenDocument specification for layered raster images done and into the OASIS OpenDocument standard. Krita would use that format for its native format, of course, as all of KOffice is moving to OpenDocument.

OpenDocument automatically means some choices are made for us: a zip file store, a certain layout inside that store, and xml main document and resources for the binary data. Those choices may not be the best possible technical choices, but Krita already uses a similar mechanism and it seems to work.

And since the Gimp and Krita have a different set of capabilities, we'd have to make a flexible and complete specification, one that includes all possible (possibly uninvented as yet) color models, adjustment layers, paths (which Krita doesn't have) and so on.

I would really like to cooperate on this, since a standard used by one application isn't a standard at all and since it would mean much better interchange of documents than would be possible through either Photoshop (ancient version 6 or reverse-engineered later versions) or XCF.

I'm prepared to do most of the writing & nagging of David Faure about procedures and guidelines, but I'm not knowledgeable enough to do it all on my own.

On Thu, 2 Mar 2006, Manish Singh wrote:

Date: Thu, 2 Mar 2006 11:11:42 -0800 From: Manish Singh
To: John Cupitt
Cc: GIMPDev
Subject: Re: [Gimp-developer] Photoshop PSD 6 format Spec / Gimp XCF format Spec

On Thu, Mar 02, 2006 at 03:30:03PM +0000, John Cupitt wrote:

Of course, OpenDocument document structure (ZIP archive with multiply files inside) could be followed.

Yes, this sounds much more sensible.

As a concept, yes. Actually using ZIP is a stupid decision,

It is a decision with some trade-offs.

I'm surprised you would dimiss it as "stupid" without knowing more about what problems they were trying to solve, obviously the smallest compression wasn't their only priority.

One thing Zip has that other archive formats don't seem to have is an internal filesystem, and some files inside the zip can be more compressed than others making it a good container format. An index or manifest can be left uncompressed, whereas other files within the archive can be more heavily compressed if desired.

and I wonder what the rationale for using it was.

There are more detailed explainations available (I read one very long and detailed report on it when it was first added to OpenOffice) but if you can find the list of requirements they had it should become clear.

No need to say unpleasant things about OpenDocument.

On Thu, Mar 02, 2006 at 08:36:41PM +0000, Alan Horkan wrote:

On Thu, 2 Mar 2006, Manish Singh wrote:

On Thu, Mar 02, 2006 at 03:30:03PM +0000, John Cupitt wrote:

Of course, OpenDocument document structure (ZIP archive with multiply files inside) could be followed.

Yes, this sounds much more sensible.

As a concept, yes. Actually using ZIP is a stupid decision,

It is a decision with some trade-offs.

I'm surprised you would dimiss it as "stupid" without knowing more about what problems they were trying to solve, obviously the smallest compression wasn't their only priority.

Why do you assume I'm calling it stupid because of compression issues?

One thing Zip has that other archive formats don't seem to have is an internal filesystem, and some files inside the zip can be more compressed than others making it a good container format. An index or manifest can be left uncompressed, whereas other files within the archive can be more heavily compressed if desired.

One big failure is that the manifest is at the *end* of the file, which makes recovering data from partial files a lot harder.

and I wonder what the rationale for using it was.

There are more detailed explainations available (I read one very long and detailed report on it when it was first added to OpenOffice) but if you can find the list of requirements they had it should become clear.

And this is what I asked about. Thanks for the handwave instead of an actual answer.

No need to say unpleasant things about OpenDocument.

No need to post emails that don't answer the question I asked about, and instead waste my time with baseless speculation.

-Yosh

On Thu, 2 Mar 2006, Simon Budig wrote:

There were plans to work on a next-generation XCF resolving these issues. I too see the need for a widely accepted exchange format for multilayered images with a lot of additional information, but the

As things stand the main option for image exchange besides XCF seems to be a flat lossless format like PNG. There is also PSD but that is not a great choice either and one I thinke we'd prefer not to recommend.

Rather than mentioning a future possible ideal format I'd like to mention MNG, which although far from perfect for all graphics tasks (print graphics). This is less than ideal but still a small improvement over PNG because at least you get to keep your layers intact (and gimp does already have some support for MNG).

I hope you will keep MNG in consideration as it might be useful until a more appropriate format is developed.

Sincerely

Alan Horkan

Inkscape http://inkscape.org

On 3/2/06, Alan Horkan wrote:

Rather than mentioning a future possible ideal format I'd like to mention MNG, which although far from perfect for all graphics tasks (print graphics). This is less than ideal but still a small improvement over PNG because at least you get to keep your layers intact (and gimp does already have some support for MNG).

IIRC, MNG is animated PNG + some minor features.Can't see much relation in this case

Alexandre

Im guessing this requires wine on linux?? - not ideal. does MacOSX run win32 *.8bi files?

Also People are quick to winge that stuff dosent work properly, but slow to provide example files, pictures of the problems and how it should look. Perhaps get some example files produced by photoshop and add in some of the features bit by bit.
Text seems fairly important- does gimp support most photoshop text functions?

- Cam

Bart wrote:

What about developing a format plugin that is a Photoshop compatible plugin (*.8bi). Most graphics apps area Photoshop plugin compatible and with a XCF.8bi apps like: Paintshop Pro, Corel Photopaint, XNView, Thumbd Plus, Paint Shop Pro could read GIMP files. Which was really great and making it much easier working together with others and using GIMP.

jernej@ena.si schrieb:

On Thursday, March 2, 2006, 13:08:04, Michael Schumacher wrote:

Up to now, there were none and using XCF in third-party apps has been discouraged because of this - the format might change without notice. AFAIK this hasn't changed yet.

Corel PhotoPaint 12 has some support for XCF format though.

_______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Hey Gimp dev's (by the way, how many gimp dev's are there?)

it often annoys me that people value a program based on its support for a foreign format.
PS Dev's dont waist time supporting other apps so why should we? (I know, cos Gimp isnt the standard.... :/ )

As said afore, Im realy happy with the gimps direction, and have enjoyed using since 1999, and even use for commercial 3d projects now.

Supporting stuff like layer effects is okay, but Im guessing its not a small task...

BTW- One feature Id be interested in seeing is layers with linked bitmap data, so you could move thenm about but theyd share pixel info. have been in a number of situations whis would be nifty, also cut down filesize.

- Cam

Bart wrote:

Right! That's what my post about: Gimp needs a much better support for the PSD-Format. As i wrote it is the same thing that the users of OpenOffice.org grows up after they have a much better support for M$ Word Doc-format.
Like M$ Word for text the Adobe Photoshop is a standard app for creating graphics (nearly 80% of all creatives use it). Gimp is a great application too but working together with others a much improved PSD support is needed:

- Gimp did not recognized which layers of the PSD visible or not and show allways all layers
- if possible it would be cool if Layer-Effects could be converted to Layers
- Text should be editable Text and not just pixels - May if Gimp supports one time herachies of layers it woulb be nice if Gimp could support them too

Frédéric schrieb:

Le Jeudi 2 Mars 2006 13:08, Michael Schumacher a écrit :

Up to now, there were none and using XCF in third-party apps has been discouraged because of this - the format might change without notice. AFAIK this hasn't changed yet.

Ok, I understand. So, Gimp really needs a good import/export PSD format filter.

_______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

On Mar 2, 2006, at 1:36 PM, Alexandre Prokoudine wrote:

On 3/2/06, Alan Horkan wrote:

Rather than mentioning a future possible ideal format I'd like to mention
MNG, which although far from perfect for all graphics tasks (print graphics). This is less than ideal but still a small improvement over PNG
because at least you get to keep your layers intact (and gimp does already
have some support for MNG).

IIRC, MNG is animated PNG + some minor features.Can't see much relation in this case

Not quite...

It's more like a packaging format that can hold multiple PNG images for animation. Or JPEG.

Hi,

Frédéric writes:

I think it is better to have a few developers, with a lot of time to spend on Gimp, rather than a lot of developers with no time...

The few people who are actively contributing to GIMP don't have a lot of time to devote to it though.

It is somewhat futile to point out that support for the PSD format needs to be improved. We know that. We know that for several years now. We simply need someone who invests the time to improve it. No need to convince anyone that it is a good idea.

Sven

On Thu, 2 Mar 2006, Alexandre Prokoudine wrote:

Date: Thu, 2 Mar 2006 21:36:42 +0000 From: Alexandre Prokoudine
To: GIMPDev
Subject: Re: Image exchange format [was Re: [Gimp-developer] Photoshop PSD 6 format Spec / Gimp XCF format Spec]

On 3/2/06, Alan Horkan wrote:

Rather than mentioning a future possible ideal format I'd like to mention MNG, which although far from perfect for all graphics tasks (print graphics). This is less than ideal but still a small improvement over PNG because at least you get to keep your layers intact (and gimp does already have some support for MNG).

IIRC, MNG is animated PNG + some minor features.Can't see much relation in this case

It isn't just about the animation, you can also think of it as a layered PNG even though it does more than that.

- Alan

I am starting to be lost in this thread spread over at least four mailing lists :) May I suggest the opening of a mailing list dedicaced to the talk about an OpenDocument for raster files ? Maybe on freedesktop as it is the most neutral organisation ;) But I have no contact with them :( But maybe some one of freedesktop is reading one of the mailing list and can do that ?

On 3/3/06, Cyrille Berger wrote:

I am starting to be lost in this thread spread over at least four mailing lists :) May I suggest the opening of a mailing list dedicaced to the talk about an OpenDocument for raster files ? Maybe on freedesktop as it is the most neutral organisation ;) But I have no contact with them :( But maybe some one of freedesktop is reading one of the mailing list and can do that ?

create@lists.freedesktop.org that would be

http://lists.freedesktop.org/mailman/listinfo/create

Alexandre

It is somewhat futile to point out that support for the PSD format needs to be improved. We know that. We know that for several years now. We simply need someone who invests the time to improve it. No need to convince anyone that it is a good idea.

rather than doing this job in the gimp, what would you think about extract the current related code to initialize the project of a lib for reading psd?

just an idea... ... perhaps more people would be able to get in this projet this way

On Fri, 3 Mar 2006, Florent Monnier wrote:

Date: Fri, 3 Mar 2006 17:27:30 +0100 From: Florent Monnier
To: gimp-developer@lists.xcf.berkeley.edu Subject: [Gimp-developer] support for the PSD

It is somewhat futile to point out that support for the PSD format needs to be improved. We know that. We know that for several years now. We simply need someone who invests the time to improve it. No need to convince anyone that it is a good idea.

rather than doing this job in the gimp, what would you think about extract the current related code to initialize the project of a lib for reading psd?

just an idea...
... perhaps more people would be able to get in this projet this way

Still faces of the problem of finding a developer interested in working on it. I wouldn't even know where to start.

- Alan

On Friday 03 March 2006 22:41, Florent Monnier wrote:

It is somewhat futile to point out that support for the PSD format needs to be improved. We know that. We know that for several years now. We simply need someone who invests the time to improve it. No need to convince anyone that it is a good idea.

rather than doing this job in the gimp, what would you think about extract the current related code to initialize the project of a lib for reading psd?

just an idea...
... perhaps more people would be able to get in this projet this way

Still faces of the problem of finding a developer interested in working on it. I wouldn't even know where to start.

Do you mean that extracting this code would be hard or long to do? Or that starting a new project requires work?

The big problem with writing a support library for photoshop files is not that it's hard to do -- it's a moderate amount of work, and then some because the public specs aren't complete, but the real problem is that there's nothing public beyond version 6; everything after is closed and forbidden. It's better to spend time getting something together that's open, extensible and fits in with the emerging open document landscape.

It is somewhat futile to point out that support for the PSD format needs to be improved. We know that. We know that for several years now. We simply need someone who invests the time to improve it. No need to convince anyone that it is a good idea.

rather than doing this job in the gimp, what would you think about extract the current related code to initialize the project of a lib for reading psd?

just an idea...
... perhaps more people would be able to get in this projet this way

Still faces of the problem of finding a developer interested in working on it. I wouldn't even know where to start.

Do you mean that extracting this code would be hard or long to do? Or that starting a new project requires work?

Bart writes:
> BTW the SDK is available on other sites on the net i posted the url at > the beginning of that thread.

Surely you aren't suggesting that we should use illegally (well, against its license anyway) redistributed copies of the PS6 SDK to improve the psd plug-in? That would be very unethical and also greatly increase the risk of attacks from Adobe's lawyers.

--tml

Bart wrote:

A PS6 version at ebay is about 40,- euro (new)

It would be difficult to find one that isn't just a pirated copy, though :)

HTH, Michael

P.S. Please reply below the quoted text.

On Thursday 02 March 2006 15:36, Alan Horkan wrote:

One thing Zip has that other archive formats don't seem to have is an internal filesystem, and some files inside the zip can be more compressed than others making it a good container format. An index or manifest can be left uncompressed, whereas other files within the archive can be more heavily compressed if desired.

I'm sorry, such a rational comment has no place in a flamewar. Please step aside.

Sven Neumann wrote:

It is somewhat futile to point out that support for the PSD format needs to be improved. We know that. We know that for several years now. We simply need someone who invests the time to improve it.

The trick is to find someone willing to work on this AND who has a copy of Photoshop that can read/write version 6 files. It might be something I'd be interested in taking on after I get a couple of other projects off my plate but I don't have a copy of PS available and have no plans to buy one.