Leonard Rosenthol wrote:

At 8:47 AM -0700 8/12/03, Nathan Carl Summers wrote:

This is what I mean by a standard that people can have confidence in -- people should trust that if their program writes good XCF's that a good program will be able to read it.

Right!

If a program writes GOOD XCF...

As long as a program follows the rules, TIFF is compatible. If you break the rules, all bets are off...

The difference is that TIFF is read and written by dozens of ad'hoc software packages. Some use 'libtiff' - but most do not.

If you look at a format like PNG, hardly anyone reads and writes it using their own code - almost everyone uses libpng - so there are no problems with PNG compatibility.

So, I think what is needed to make a reliable file format is to provide a well written library for reading and writing the files that's freely available and properly maintained on every modern platform FROM DAY ONE. If you then write in the specification document something like:

"You are strongly encouraged to use the standard file reading/writing library rather than writing your own"

...then better still.

I don't think it matters very much how the format is specified. The reliability and transportability of the resulting files depends mostly on the quality of the support library.

Another problem with TIFF is that it's easy to extend. That sounds like a good idea - there are ways to simply ignore tags that your program doesn't understand - so how bad could that be?

Well, if you have programs that invent tags that say things like "What follows is a block of pixels in MacPaint format", or "If this tag is set, the pixels are stored bottom-to-top instead of top-to-bottom" - then ignoring a tag you don't recognise results in a very screwed up image.

---- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sjbaker@link.com http://www.link.com Home: sjbaker1@airmail.net http://www.sjbaker.org

Tor Lillqvist wrote:

www.gimp.org/win32/gimp-head-20030813.zip.

Thank you so much!

I couldn't satisfy the dependency on libart_lgpl_2-2.dll though. Any clue on where to find a working libart binary DLL?

Pedro Gimeno

On 13 Aug 2003, at 5:32, Tor Lillqvist wrote:

www.gimp.org/win32/gimp-head-20030813.zip.

Perhaps I read over this somewhere, but GIMP HEAD for Windows also seems to require libart. The libart for Windows I downloaded from somewhere off the internet had to be renamed to libart_lgpl_2-2.dll.

Bug reports to bugzilla, please.

Will do.

On 13 Aug 2003, at 19:30, Pedro Gimeno wrote:

Tor Lillqvist wrote:

www.gimp.org/win32/gimp-head-20030813.zip.

Thank you so much!

I couldn't satisfy the dependency on libart_lgpl_2-2.dll though. Any clue on where to find a working libart binary DLL?

I got mine from
. That version
is more recent, though, so I had to rename it. I don't know if that has any averse effects, but at least it allowed me to run the GIMP.

"Branko Collin" wrote:

I got mine from
. That version
is more recent, though, so I had to rename it. I don't know if that has any averse effects, but at least it allowed me to run the GIMP.

Thank you very much. Now I've got it running. There are still issues but it works at least. No plug-in is loaded at all: lots of messages like this one are output to the console.

C:\gimp-head-20030813\bin\gimp-1.3.exe: Unable to run Plug-In: "zealouscrop.exe"
(C:\gimp-head-20030813\lib\gimp\1.3\plug-ins\zealouscrop.exe) Failed to execute helper program

The path is correct and the executables are is there. Any ideas?

Finally the mouse wheel works in Windows! Yoo-hoo!

Pedro Gimeno

On 13 Aug 2003, at 21:00, Pedro Gimeno wrote:

"Branko Collin" wrote:

I got mine from
. That version
is more recent, though, so I had to rename it. I don't know if that has any averse effects, but at least it allowed me to run the GIMP.

Thank you very much. Now I've got it running. There are still issues but it works at least. No plug-in is loaded at all: lots of messages like this one are output to the console.

C:\gimp-head-20030813\bin\gimp-1.3.exe: Unable to run Plug-In: "zealouscrop.exe"
(C:\gimp-head-20030813\lib\gimp\1.3\plug-ins\zealouscrop.exe) Failed to execute helper program

The path is correct and the executables are is there. Any ideas?

I am sorry, but I experienced no such problems. I installed this GIMP at work, so I cannot check before tomorrow.

Pedro Gimeno wrote:

works at least. No plug-in is loaded at all: lots of messages like this one are output to the console.

I found the cause. I missed the gspawn-win32-helper.exe from the glib archive. Thanks anyway.

Pedro Gimeno

Since there is all sort of mind storming going around, I will add my comments here.

People have considered TIFF, PSD in this newer thread - before the Camp, on the list, we were almost closed in an ar archive, with XML informatin and possibly PNG raster data inside.

That kind of archive does sound good for me.

But on this new thread were proprietary formats batle along with mutant ideas, here I go:
Why not settle for a Postscript subset?

It may sound weird at first, but maybe it can have a couple more advantadges that have not been considered so far.

The major one, of course, is that the file would be essentialy "auto renderable" - no need of GIMP, neither of any other program, to get it printed.

Since PSD and TIFF are used by ADOBE, ADOBE also has a program that makes use of postscript subsets.. I just do not remember which file type it is.

It can have color profiling support - it is on the specifications. It has support for multiple compression standards... (ok, maybe you have to encode the decompressor algorithm inside the file as well if you want something too different)

Text layers would have trivial, transformation independent, support.

However, it would be no easy task. There would be the need to implement at least a basic PS VM on the Gimp itself - it cannot rely on GS for it's prime image format.

But it can support all the meta information needed, and with such a basic VM, the files would also be auto-queryable.

I myself don't know postscript THIS lot. I am just commenting on it as a possibility, alltogether in this thread.

Regards,

JS ->

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

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

On Wed, Aug 20, 2003 at 10:53:14PM -0400, Leonard Rosenthol wrote:

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

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

Yes to both...

Hmm, got a reference to that? It wasn't immediately apparent in my reading of the spec.

See Section 19 for Floating point support in data.

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

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

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

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

GEGL uses XYZ as a native format.

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

It's there to make sure that people don't duplicate tags - so as long as we pick pretty unique tags related to the GIMP, it's not a problem.

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

Another thing I'm worried about is simply adding to the confusion of "what is a tiff file". There are few tiff readers/writers that support the entire feature set of tiff, and many broken implementations out there.

True - but that's the case with EVERY SINGLE file format (graphic, wp, etc.). Only the original application for which the format was created will usually support all features. Not every feature of PNG is supported by all tools. GIMP doesn't support all features of PSD files.

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

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

There's an advantage of starting from a clean slate, and not having to worry about existing baggage.

There is indeed...and there are disadvantages as well (including a LOT more time to design and then code).

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

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

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

-Yosh

* Adam D. Moss [030814 09:59]:

Stephen J Baker wrote:

So, I think what is needed to make a reliable file format is to provide a well written library for reading and writing the files that's freely available and properly maintained on every modern platform FROM DAY ONE.

I agree with this -- I think it's really important.

(That's if we either want or expect the new XCF to become a defacto standard in the first place. Personally I'm not sure either way, but in any case it makes sense to library-ise the XCF load/saver just from a technical abstraction standpoint.)

Which is why I in an earlier mail suggested developing a GEGL file format that gimp could extend and use a subset of. By doing it this way, gegl would be the aforementioned file loading, and compositing library,. (e.g. if an application needs to load an XCF2 file, but don't support layers, the library would be capable of compositing it, putting the logic to do compositing of layers, layer groups, adjustment layers, u8, u16, float, double, cmyk, rgb, ycbcr and spotcolors into a file loading library,. makes very little sense,..

For those who were not at GimpCon2,. http://phpweb.hig.no/~oey_kola/ccc/ contains three images of how a GEGL compositing graph correlates with the current gimp layer stack,. a layer stack with groups, and a layer stack with some effect/adjustment layers added.

/Øyvind K

Hi,

I'd like to mention that none of the proposed formats except the XML approach would be capable of supporting the stuff we want to add to GIMP with GEGL. I don't think any existing format could be sanely extended to support complex render graphs as will be introduced with GEGL. We are not talking about simple layer lists or trees any longer but we need to be able to store complex processing intructions with each node. XML seems to be the only reasonable choice here.

According the library that reads and writes the new format, GEGL should provide this functionality. The basic file format should be defined by GEGL and GIMP will only add some user interface specific things in its own namespace.

Sven

On Wed, 20 Aug 2003, Leonard Rosenthol wrote:

At 11:42 PM +0000 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

On Thu, 14 Aug 2003, Sven Neumann wrote:

[Note: quote blocks have been reordered for clarity]

Hi,

I'd like to mention that none of the proposed formats except the XML approach would be capable of supporting the stuff we want to add to GIMP with GEGL.

On the contrary, my proposal would handle graphs as easily as XML would.

We are not talking about simple layer lists or trees any longer but we need to be able to store complex processing intructions with each node. XML seems to be the only reasonable choice here.

My proposal is tree-based just like XML. And you can do graphs in it exactly the same way it is done in XML -- by labeling elements of the tree and using the labels to denote the links between the nodes on the graph.

I don't think any existing format could be sanely extended to support complex render graphs as will be introduced with GEGL.

Depends on what you mean by "sanely extended." Of course it is unlikely that you could create something that interoperates well with existing applications, but there is nothing inheritly wrong with takiing an existing format, or more than one, and using it for the basis of the new XCF.

According the library that reads and writes the new format, GEGL should provide this functionality. The basic file format should be defined by GEGL and GIMP will only add some user interface specific things in its own namespace.

I can imagine that parasites, at the minimum, would also go in the GIMP namespace.

Rockwalrus

On Wed, Aug 13, 2003 at 08:32:00PM -0300, Joao S. O. Bueno wrote: | But on this new thread were proprietary formats batle along with mutant | ideas, here I go:
| Why not settle for a Postscript subset?

PostScript is a proprietary format controlled by Adobe. Adobe has several patents on various aspects of the PostScript format any implementation would be affected by.

| The major one, of course, is that the file would be essentialy "auto | renderable" - no need of GIMP, neither of any other program, to get it | printed.

This is a good idea, but it would also mean GIMP would have to read back a PostScript file. PostScript is a huge standard outside the scope of an application such as the GIMP.

Developers would have to put in kludges and special comments which'll help them represent structures which cannot be natively represented using PostScript. Isn't this just as expensive as implementing a new specification?

What's more easier?

A> Have a native file format designed for the GIMP. Those who want to use it with PostScript aware applications export the native format using a plug-in. If XML is used for the underlying data representation, any XML parser can be used to parse information, especially information such as the author of an image, size and colour depth of the image, etc.

B> Use a subset PostScript as the native file format. Design and implement representation of unrepresentable structures in PostScript comments. Implement a PostScript parser (which is as good as a stack based interpreter).

| Since PSD and TIFF are used by ADOBE, ADOBE also has a program that | makes use of postscript subsets.. I just do not remember which file type | it is.
|
| It can have color profiling support - it is on the specifications. It | has support for multiple compression standards... (ok, maybe you have to | encode the decompressor algorithm inside the file as well if you want | something too different)

Support for multiple compression algorithms can be implemented in an XML based format. One can also have data in other image formats such as TIFF, PNG or even the same GIMP native format itself embedded as CDATA, or the file format may be an archive of associated images, etc.

The features implemented depend on how far developers want to take the new file format. The developers themselves are capable of doing what they want :-)

Mukund

* Leonard Rosenthol [030814 18:06]:

At 4:41 PM +0200 8/14/03, Øyvind Kolås wrote:

The baseline GEGL library will be exactly the baseline functionality needed to be able to something useful with the file,. compositing the layers, layer groups, and effect layers into a single image. And in that process handling the various kinds of layers (8bit, 16bit 16bit float, 32bit float, rgb, cmyk etc.)

Sure, if I don't already have that type of functionality in my own application that would be useful.

But let's say that I am Photoshop or ImageMagick, which already have layer (with effects), a compositing engine, etc. All I want is to load GEGL/GIMP data from disk into my own data structures. I do NOT want/need all of your functionality - just want to read the file!

Then you jsut want to be able to understand the XML file, which is the reason I proposed using something like xml in the first place, the rest of the logic would then be contained in your application. Then only additional kind of logic would then be a small api allowing you to get to each individual "file" within the archive or directory.

On Wed, Aug 20, 2003 at 07:45:33PM -0400, Leonard Rosenthol wrote: |
| Because Postscript is dead. It hasn't been updated in over 6 | years, and Adobe themselves are slowly moving towards PDF-based | solutions, including printing.

PostScript is far from dead. You would be banishing the entire publishing industry if you say PostScript is dead :-)

Are you sure it hasn't been updated for so long? Take a look at the PostScript 3 reference manual.

| Also, Postscript is a programming language. You would need | to implement a full parser and interpreter for it. NOT a fun thing. |
| You'd be better off heading down the PDF route...All the | benefits of PS, but a LOT easier to implement and MUCH more | extensible and supported.

Implementing a full PDF parser is definitely much harder than a full PostScript parser. PDF more or less encompasses PostScript.

PostScript is much more widely supported than PDF. It is just as extensible as PDF as far as imaging goes.

| >The major one, of course, is that the file would be essentialy | >"auto renderable" - no need of GIMP, neither of any other program, | >to get it printed.
|
| Assuming a PS printer...
|
| But most users either have PCL or raster-based printers...

Most printers are raster based at the core, except for certain plotters (which are very interesting to watch BTW). Some printing solutions implement the RIP in software on the host computer (such as Ghostscript or Adobe's PressReady -- not sure if the latter has been deprecated by something else). Others implement it on the printer itself, such as a few printers in the HP LaserJet family.

More or less, most people are able to print PostScript on their printers on most major operating systems.

| >Since PSD and TIFF are used by ADOBE, ADOBE also has a program that | >makes use of postscript subsets.. I just do not remember which file | >type it is.
|
| Versions of Adobe Illustrator It can have color profiling support - it is on the specifications. | >It has support for multiple compression standards... (ok, maybe you | >have to encode the decompressor algorithm inside the file as well if | >you want something too different) |
| PS doesn't support "plug-in" filters...

As compared to PDF? In the context of the original poster's comment, what did you have in mind for using plug-in filters? How is the PDF plug-in support useful in any way with image representation?

The original poster was talking about color profiles.

Mukund

Thank you for the comments.

I quite much agree with all of them, I just threw it in because I think it'd more interesting than TIFF or PSD alltogether.

Quite informative is the part about Adobe patents.

I will no longer mention PS as a native file format, GSview is quite good as a PS loader as it is today.

As to Leonard who suggested that " postscript doesn't accept plugins", I have to point him for the fact that it i s a programing language - and the dedcoding algorithns I mentioned would just be placed in the file as postscript procedures. And why PS instead of PDF? You can edit good Postscript files with a text editor, just as you can do with XML.

Regards,

JS ->

Mukund wrote:

On Wed, Aug 13, 2003 at 08:32:00PM -0300, Joao S. O. Bueno wrote: | But on this new thread were proprietary formats batle along with mutant | ideas, here I go:
| Why not settle for a Postscript subset?

PostScript is a proprietary format controlled by Adobe. Adobe has several patents on various aspects of the PostScript format any implementation would be affected by.

| The major one, of course, is that the file would be essentialy "auto | renderable" - no need of GIMP, neither of any other program, to get it | printed.

This is a good idea, but it would also mean GIMP would have to read back a PostScript file. PostScript is a huge standard outside the scope of an application such as the GIMP.

Developers would have to put in kludges and special comments which'll help them represent structures which cannot be natively represented using PostScript. Isn't this just as expensive as implementing a new specification?

What's more easier?

A> Have a native file format designed for the GIMP. Those who want to use it with PostScript aware applications export the native format using a plug-in. If XML is used for the underlying data representation, any XML parser can be used to parse information, especially information such as the author of an image, size and colour depth of the image, etc.

B> Use a subset PostScript as the native file format. Design and implement representation of unrepresentable structures in PostScript comments. Implement a PostScript parser (which is as good as a stack based interpreter).

| Since PSD and TIFF are used by ADOBE, ADOBE also has a program that | makes use of postscript subsets.. I just do not remember which file type | it is.
|
| It can have color profiling support - it is on the specifications. It | has support for multiple compression standards... (ok, maybe you have to | encode the decompressor algorithm inside the file as well if you want | something too different)

Support for multiple compression algorithms can be implemented in an XML based format. One can also have data in other image formats such as TIFF, PNG or even the same GIMP native format itself embedded as CDATA, or the file format may be an archive of associated images, etc.

The features implemented depend on how far developers want to take the new file format. The developers themselves are capable of doing what they want :-)

Mukund

Hi,

On Thu, 2003-08-21 at 16:27, Leonard Rosenthol wrote:

I'd like to mention that none of the proposed formats except the XML approach would be capable of supporting the stuff we want to add to GIMP with GEGL.

Well, that pretty much settles that discussion...

So let's start talking XML + archive again, shall we ;).

I never understood the reasoning for this discussion anyway. IMHO the format that Nathan suggested seems like something from the dark ages of file formats (where TIFF and the like originated from). I haven't heard a single good argument for it except that it can do most of the things that the XML/archive approach can do. There was however nothing mentioned that it can do better. Or did I miss something?

According the library that reads and writes the new format, GEGL should provide this functionality.

Requiring an application to incorporate all of GEGL in order to read/write an XCF file is, in my opinion, a recipe for it not getting used by other applications. (and I say this as one of those other application developers).

We will need the dependency on GEGL since we want to develop GIMP to a point where no image manipulation program has gone before. However there is still the need for a good format for exchanging layered images between applications. So perhaps it makes sense to also develop such an exchange format.

Sven

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

On Thu, Aug 14, 2003 at 01:34:01PM -0400, Leonard Rosenthol wrote: |
| >Implementing a full PDF parser is definitely much harder than a full | >PostScript parser. PDF more or less encompasses PostScript. |
| You are quite misinformed...
|
| PDF is a static file format of structured objects referenced | by a single catalog (cross reference table). It's pretty easy to | write a PDF parser - a couple of days at most, which is why there are | so many of them. (the hard part is getting all the object management | correct for later modification). It has NO variables, loops, | conditionals, etc.
|
| Postscript is a full fledged programming language with all | that at entails (stack managements, variables, loops, functions, | conditionals, turing completeness, etc.).

Person! I said it more or less encompasses PostScript.

I do agree that the interpreter is much simpler in case of the PDF due to the absence of procedures, variables, conditionals, etc. But PDF has a lot of other features which add complexity to it over PostScript. You yourself have listed features such as JPEG2000, 16-bit images and JBIG. PDF also supports more types of fonts, supports hyperlinks, annotations, bookmarks, thumbnails, scripting -- there you go, encryption and signatures, plug-ins and more.

| >PostScript is much more widely supported than PDF. |
| Only as far as direct/native printing goes - that's true. |
| On the application side, PDF has wider support due to the | ease of implementation.

See above. PDF has become popular on screen displays (and even for printing as a result), but I think it has more to do with Adobe pushing the PDF format with a free viewer, and due to it's document capabilities.

| > It is just as extensible as PDF as far as imaging goes. |
| To an extent - there are things that PDF does by default that | PS can't do (eg. 16bit images, JPEG2000, JBIG2), and there are areas | of PDF that provide extensibility that PS does not.

We were talking about extensibility, not about features that come bundled. There are areas of PDF that provide extensibility, but none of them directly apply to the GIMP or processing of imaging information.

| Sure, at some point the printer is just putting bits on a | page - but only the home-level inkjets are ONLY raster-based. | Professional office and prepress printers use a page description | language (usually either PCL or PS) to keep traffic down and then | rasterize on the device.
|
| Most implement RIPping on the device itself... |
|
| >More or less, most people are able to print PostScript on their printers | >on most major operating systems.
|
| Not out of the box! They would need to install Ghostscript | (and associated drivers, which might also require something like | GIMP-print).

To print PostScript, one doesn't need GIMP-print. My OS (Red Hat Linux) came with Ghostscript installed out of the box. I assume Mac OS X can also handle PostScript out of the box as it has a unix toolchain. IIRC it uses CUPS as its print system. I am not sure about Windows as I haven't worked with it in a long time.

The point of my statements was to say that despite them being PCL or raster-based printers, they can still print PostScript. They can sure print PDF as well in the same way. The point Joao was trying to make was that one can print PostScript on a printer way easier than one might print a custom GIMP file format as they don't need to find a copy of GIMP to print it, and that gives weightage to going with a PostScript file format.

Mukund

Sven Neumann wrote:

I never understood the reasoning for this discussion anyway. IMHO the format that Nathan suggested seems like something from the dark ages of file formats (where TIFF and the like originated from). I haven't heard a single good argument for it except that it can do most of the things that the XML/archive approach can do. There was however nothing mentioned that it can do better. Or did I miss something?

I think there are three separate problems to solve here.

1) How to store the compositing tree (and other meta-data) that GEGL needs.

2) How to store bulk texels in a variety of data formats (byte, int, float, etc) and in a variety of colour representations (RGBA, CMYK, etc).

3) How to put together (1) and potentially many (2)'s into a single file.

It seems to me that XML was just *made* to do (1) nicely. It's also rather nice that this is human readable and the parsers for it are likely to be easy. XML is nice and modern and there are loads of supporters of it. I don't think this should even be a matter of debate - it's *so* obvious that this is the way to go.

(3) Looks a lot like taking an XML file and a bunch of simple images and stuffing them together into an archive. There are lots of choices for the archive format - and it probably doesn't matter which one you choose. I rather like the idea of using 'ar' - but that's a UNIX-centric viewpoint. Something like 'zip' with it's ability to compress *and* archive multiple files into one file would be good. But the obvious OpenSourced candidates (bzip2 and gzip) don't do that. Tar+Gzip would work though. The only argument I heard against it was that tar doesn't allow arbitarily long filenames...that's irrelevent because the XML code at the top of the archive can map long layer names into short sub-image names for the benefit of those who care.

Bulk image storage (2) seems a bit more problematic. It would be nice to use a standard file format so that you could unbundle a GIMP 'archive' into an XML file and a bunch of standard images, operate on them individually with other tools that know nothing about GIMP, GEGL, etc - and then put them all back together again with the archiver. So what's needed is a standard (and hopefully rather simple) image file format. However, we don't seem to be finding any nice modern, robust, well-known and portable formats that can do bizarre things like full floating point CMYK.

I think you could resolve the issue of how to store bulk image data by not making a decision!

Allow any of the file formats that GIMP uses to be used to represent a layer in the total image archive. The XML file can tell us what format each sub-image is stored in...and GIMP already has loaders for gazillions of file formats.

That way, we could use (say) PNG for storing run-of-the-mill RGB images, and invent custom formats (or TIFF with tags or whatever) for storing the bizarro stuff.

----
Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sjbaker@link.com http://www.link.com Home: sjbaker1@airmail.net http://www.sjbaker.org

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: sjbaker@link.com http://www.link.com Home: sjbaker1@airmail.net http://www.sjbaker.org

On Thu, Aug 21, 2003 at 10:16:13AM -0400, Leonard Rosenthol wrote:

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

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

Why would you only use half of a 32bit float?? That reduces your accuracy/precision and makes you incompatible with the rest of the world doing floating point imaging.

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

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

And makes the file size twice as big...

One of the goals of GEGL is to allow GIMP to be adapted to wacky formats like these easily.

I would argue that using "wacky formats" is a bad thing. The more wacky you make things, the less change you have for interoperability with other tools.

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

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

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

The spec is only updated every 18-24 months when Adobe releases a new version of Photoshop - so you definitely don't wait for that! As for the other, yes, that is true you could wait, but nobody does...

And Foo organization adds a tag with the the same value as Bar organization, for different purposes, since neither cares to wait. Part of the reason why there is a lot of bad tiff processors out there I think.

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

Never implemented a file format, have you ;).

What widely used formats have you implemented? :)

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

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

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

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

Worth the work, sure! Trivial - no way!

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

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

There is no need to touch libtiff - and if there is, you don't work, you modify and then submit your changes back. libtiff is an active library, and the maintainers would happily accept changes...

Yeah, but there are people out there still running outdated installed, it's harder to get them to upgrade a system library.

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

Also, one has to wonder why Adobe is keeping PSD around if TIFF does everything.

-Yosh

Leonard Rosenthol writes:

With a bunch of work, you can use GS to print to Windows - but not to every printer (I don't believe GIMP-print, for example, works on Windows).

There's nothing fundamental stopping you. I've built it under Cygwin and run the testsuite, and there were no suprises. It could probably be used as a native Windows driver, if someone cares to write the glue to use libgimpprint and create a nice GUI interface.

I've not tested recent 4.3.x releases, so I'm not sure if the loadable family driver modules and embedded mxml XML interpreter function correctly, but there's no reason why they shouldn't.

On Thu, Aug 14, 2003 at 09:10:37PM +0200, Sven Neumann wrote:

point where no image manipulation program has gone before. However there is still the need for a good format for exchanging layered images between applications. So perhaps it makes sense to also develop such an

I don't think there is a need for such an extra format. Existing formats like MIFF can easily cope with layered images and can easily be extended (linearly) with additional metadata.

And surely if people want to read/write xcf and don't want to use GEGL i'd firmly say it's their problem entirely. I mean, if people want to read/write PNG without libpng it's their problem, too, and png was designed as interchange format, while xcf is not, should not, and will not.

Stephen J Baker wrote:

It seems to me that XML was just *made* to do (1) nicely. It's also rather
nice that this is human readable and the parsers for it are likely to be easy.
XML is nice and modern and there are loads of supporters of it. I don't think
this should even be a matter of debate - it's *so* obvious that this is the
way to go.

I second the "obvious" part to this. I have been seriously caught off guard lately as this seems so obvious to me that I could not begin to envision a conversation being needed to support it.

However, I have had great success with xml, only after I had my own tools built for it. The nice thing about xml is that you can build your "own issues" into it. This is also why I found it necessary to build our own.

carol

On 13 Aug 2003, at 5:32, Tor Lillqvist wrote:

www.gimp.org/win32/gimp-head-20030813.zip.

Haven't really tested GIMP HEAD much at all myself, but it starts OK and some random painting and filtering did work.

Bug reports to bugzilla, please.

I was hoping to get in some real-word testing, as I don't have much time for anything else. Unfortunately, proves a real
blocker for me.

Would you have an alternative way to enter such values? I often need to save JPEG images for my work, but the JPEG save plug-in uses floating point values.