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] Portable XFC
At 8:32 PM -0300 8/13/03, Joao S. O. Bueno wrote: 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. Which is still a valid approach, but would DEFINITELY require a standard library since 'ar' isn't a standard outside the Linix world... Why not settle for a Postscript subset? 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. 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. 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... 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 = 8 used a subset of EPS (Encapsulated Postscript) as its native file format. As of version 9, it now uses PDF as the file format. 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... Text layers would have trivial, transformation independent, support. Storing the text isn't the hard part of text layers... 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 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
[Gimp-developer] PS vs. PDF
At 5:40 PM +0100 8/14/03, Mukund wrote: On Wed, Aug 20, 2003 at 07:45:33PM -0400, Leonard Rosenthol wrote: | Because Postscript is dead. PostScript is far from dead. You would be banishing the entire publishing industry if you say PostScript is dead :-) I guess I should say that Postscript is languishing and slowly being phased out in all areas in favor of PDF... Are you sure it hasn't been updated for so long? Take a look at the PostScript 3 reference manual. OK, 5 years instead of 6 (1998). But in today's world, that's a HUGE time... In that same time, PDF has had two MAJOR upgrades (PDF 1.4 and 1.5). 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.). 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. 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. | But most users either have PCL or raster-based printers... Most printers are raster based at the core, 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. 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). Very few anymore - but yes, they do exist... Others implement it on the printer itself, such as a few printers in the HP LaserJet family. 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). 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] Portable XFC
At 1:47 PM +0200 8/14/03, Sven Neumann 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 ;). 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). Leonard -- --- Leonard Rosentholmailto:[EMAIL PROTECTED] http://www.lazerware.com ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
At 10:06 AM +0200 8/14/03, Øyvind Kolås wrote: 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,. But that seems like an EXTREMELY heavyweight library to incorporate into a project just for reading/writing files... 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 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
[Gimp-developer] Re: GimpCon RFC: Portable XCF
At 7:52 PM +0200 8/14/03, Guillermo S. Romero / Familia Romero wrote: 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... Where are those updates? Is it some kind of errata or addon? The PDF I have says 1992 (TIFF v6.0). The updates were originally done as technical notes, now they are incorporated into the main TIFF v7 spec which is part of the Photoshop SDK. 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 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
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
At 6:29 PM +0200 8/14/03, Øyvind Kolås wrote: 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. Well, yes, I need to understand the FILE FORMAT...whether that be XML, PNG, TIFF, XCF, etc. But there seems to be a general belief that there should be a standard library for reading/writing the file format to help reduce the issues of multiple implementations. That library shoudl ONLY be a file format handler, it should NOT be all of GEGL... 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 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] Re: GimpCon RFC: Portable XCF
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! 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: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] Re: GimpCon RFC: Portable XCF
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... 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 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] Portable XFC
data in XML. But isn't this the case with ANY file format, including your PNG-like design!?!? 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] Third big serious meeting from GIMPcon
At 8:36 PM +0200 8/9/03, Dave Neary wrote: Another reason may be that it is difficult to build the development version because it depends on released versions of some libraries that are not included yet in the major GNU/Linux distributions (e.g., GTK+ version 2.2.2). Also, the number of dependencies for GIMP 1.3.x is much higher than the number of dependencies for GIMP 1.2.x, so it is more difficult to have a working build environment for the 1.3.x version. This problem may be solved as time passes, because more and more distributions will include the required libraries. I think the related reason here is that many open source projects get their contributors from non-Linux platforms, esp. Windows. And building GIMP/Windows is even more of a nightmare than building GIMP on Linux. 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] Third big serious meeting from GIMPcon
At 1:37 PM +0200 8/10/03, Michael Schumacher wrote: Well, building GIMP/Windows so that GIMP can be run isn't that complicated - It is for folks using Visual Studio - which (all free software stuff aside) is the standard for development on Windows. If you want people developing on GIMP/Windows (which would also mean GIMP in general), you need VC projects. Sure, building from CygWin and MinGW are nice - but that's not how folks work in the real world... 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 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
[Gimp-developer] Re: GimpCon RFC: Portable XCF
At 7:18 PM +0200 8/10/03, Guillermo S. Romero / Familia Romero wrote: You are right, PSD is not an option, it would mean always behind Adobe and never able to include new things. Agreed... About TIFF, every now and then someone appears with an horror story about TIFF files, so while better than PSD, I dunno if enough. :/ There are programs out there that generate bad TIFF - for one reason or another. But we already have to deal with that in our native TIFF coder... 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] CMYK Plugin [was: tentative GIMP 2.0release plans]
At 1:33 AM +0100 7/21/03, Alastair Robinson wrote: Sounds like a good start. If you want to investigate better RGB - CMYK conversion, then the littlecms library is a good choice to do the heavy lifting; it can do accurate conversions between colour spaces defined by ICC profiles. Yes, great library and easy to use. A default conversion from sRGB to SWOP-Coated seems to be the combination most houses use when no proper profiles are available, SWOP is fine for US, but Europe, Japan, etc. use different - so you give folks the choice... and will generally give considerably better results than a [c,m,y]=1-[r,g,b] type algorithm... MUCH better... There are also some better algorithms for conversion as well. 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] GIMP GBR format spec
At 5:35 PM +0200 7/16/03, Sven Neumann wrote: I don't think we should use a compressed archive. Instead the binary data in the archive should be compressed. I agree - and that's what ZIP/JAR allow for - some files/blobs are compressed, and some are not. You could either use the built-in methods to specify this, OR use the XML manifest. That allows to choose the best compression scheme for the data and to combine different compression techniques in the archive. Exactly! As I pointed out in an earlier mail, I am not sure if a hierarchical structure in the archive is a good idea. In my opinion the hierarchy should only be defined in the XML part that describes how the contents of the archive should be put together. If we apply the document hierarchy to the archive, it will become painful to keep the XML description and the archive hierarchy in sync. It's an interesting tradeoff. If you leave it flat, that means that it's not possible to establish relationships between objects WITHOUT parsing the XML - so that standard archiving tools wouldn't be helpful. On the other hand, you are right, that syncing the two could be a pain. LDR -- --- 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] A comment on CinePaint (was Re: new-xcf)
At 5:10 PM -0400 7/17/03, Christopher Curtis wrote: Just for the record ... I read the CinePaint file format, and it doesn't even resemble XML. Yeah, I've had that argument with Robin - and lost :(. They are going for simple and scriptable over good design - I think they will regret it ver soon... 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] GIMP GBR format spec
At 7:16 AM -0500 7/14/03, Stephen J Baker wrote: One issue we should at least think about with JAR is that since it *is* the JAVA library mechanism, there is perhaps a risk of allowing virus writers to attach bits of JAVA executable in what *appears* to be a GIMP image. If you don't open up the JAR file with a Java-based tool - you can't have Java executing. And even if you DO use Java to open up the JAR, nothing auto-executes - you'd have to manually kick it off. SO even if someone were to put Java bytecodes into a GIMP image file, it would never get executed... Leonard -- --- Leonard Rosentholmailto:[EMAIL PROTECTED] http://www.lazerware.com ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [CinePaint-dev] GIMP GBR format spec
At 12:04 PM +0200 7/11/03, Marc wrote: On Thu, Jul 10, 2003 at 04:08:21PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: in such an approach and I am sure that not many XML parsers will like CDATA blocks of several megabytes. _all_ xml parsers cope with cdata blocks of several megabytes. But the fact is that you're going to end up having to Base64 encode all the image data - which will blow the physical file size WAY out of proportion. And if don't do that (ie. attempt to leave in binary data), then you are violating the spirit of XML's design goals. Leonard -- --- Leonard Rosentholmailto:[EMAIL PROTECTED] http://www.lazerware.com ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP GBR format spec
At 02:34 PM 7/11/2003 +0200, Sven Neumann wrote: XML is very well suited to describe the structure of a multi-layered, multi-framed image/animation and it can be used perfectly to embed meta information as well as vector layers, paths and the like. XML namespaces make it easy to add application-specific extensions later. You bet! We discussed to bundle one XML file with a set of files that store the image data. These files would preferably be known image formats or perhaps even strict subsets of known image formats. Agreed. I would suggest that these files are then put together in an ar archive. Such an uncompressed archive has the advantage that the XML metadata can easily be extracted. You just described a JAR file, which is not unlike the OpenOffice file format ;). A JAR is a special type of ZIP archive, which contains one or more data files along with an XML manifest about the contents. I've worked on a number of projects (both commercial and open) that have used such a format - it works quite nicely and is compatible with existing tools and technologies. Always better than reinventing the wheel!! I think the approach of a JAR-like file for the future GIMP (and possibly CinePaint) file format is an excellent choice and allows for many avenues of expansion. Leonard ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [CinePaint-dev] GIMP GBR format spec
At 06:34 AM 7/11/2003 -0700, Nathan Carl Summers wrote: Oh wait, I take it back. I can think of a image format that retains the spirit of XML: gimpimage commentCreated by the GIMP!/commment layers colorspace=rgb bitdepth=8 layer width=6 height=6 row pixel r=127 g=127 b=127 / pixel r=127 g=127 b=127 / pixel r=127 g=127 b=127 / pixel r=127 g=127 b=127 / pixel r=127 g=127 b=127 / pixel r=127 g=127 b=127 / You know what is really scary about that... About 6 months ago, someone posted to the SVG mailing list a proposal for an XML-based raster image format that pretty much exactly that...And he was SERIOUS about it!!! Leonard ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] XCF file format
At 6:24 PM +0100 2/3/03, Tino Schwarze wrote: BTW: There was some effort to add XCF support to ImageMagick a while ago (probably Sven meant that thread). XCF reading support has been implemented and working in ImageMagick for a while now. It doesn't get 100% of all features, but it gets all the majors (including layers (and their attrs), etc. 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] What's the status of mng support?
At 8:50 AM -0500 11/18/02, David Weeks wrote: I want to work in the mng http://www.libpng.org/pub/mng/#history format, and don't recall gimp supporting it, ie -- it's not a save option. You can use ImageMagick in conjunction with the GIMP to do this. IM will read in .xcf files (as well as many others) and will happily then output .mng files for you. LDR -- --- 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] Re: Dreamworks, Shrek, and the need for 16 Bit
At 6:27 PM +0100 11/1/02, Guillermo S. Romero / Familia Romero wrote: PNG should be included in this family too, BTW. Any other format? TIFF and PSD also support 16bit data... Leonard -- --- Leonard Rosentholmailto:leonardr;lazerware.com http://www.lazerware.com ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: CMYK 16-bit print developer sought
At 06:47 PM 10/23/2002 -0700, Robin Rowe wrote: What I meant was print in the magazine/book publishing sense, not gimp-print. A developer knowledgable in the print side of the business would help in building the right 16-bit CMYK stuff. Another option would be enhance the GIMP/.xcf coder module that I wrote for ImageMagick so that it can import 16bit Film Gimp images. Since ImageMagick already knows how to deal with 16bit data AND CMYK data - it would be the least amount of work. Leonard ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Interoperability with ImageMagick
At 1:31 PM -0400 8/29/02, airbete full wrote: ImageMagick has several interesting algorithms (NoiseReduction, Despeckle (that one doesn't work well in the GIMP by the way), ...) that I would like to use through the GIMP. Does there exist a C-C++ interface that facilitates a GIMP plug-in programmer to use ImageMagick routines? Or maybe another kind of interface using Script-fu / Magick Scripting Language ? There isn't one currently, but it would certainly be possible to write a GIMP plugin that uses ImageMagick to do the work on the image data. Currently, when I'm in the GIMP and want to modify an image with IM, I do it the hard way: save it, launch IM on it and then reload it in the GIMP. That certainly works... Leonard Maintainer, ImageMagick -- --- 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] Photoshop's file formats specs pulled?
At 11:47 PM +0200 7/9/02, Branko Collin wrote: It looks like Adobe withdrew the PDF with the file format specifications for Photoshop 6.0. In order to get the Photoshop 7.0 SDK, one needs to be a member of the Adobe Solution Network. Just went online and saw that as well - VERY interesting... You also et a copy of the Photoshop SDK with every copy of Photoshop - it's on the CD (or at least used to be). The 6.0 specs seem to indicate that the file format changes slowly, so reverse engineering the formats should work in most cases. The changes between 6 7 were minor at best - nothing significant that should effect GIMP. There are still many things that the GIMP has to support in the 4 and 5 formats, let alone 6 and 7. 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] urgent help?
At 11:28 PM -0700 6/1/02, manjunath s wrote: 4. Last but not the least, is the image representation in GIMP and that of the libarary IMAGEMAGICK compatible. Is there any way i can get gimp's representation of the image from the other and vice versa. Are you talking about the representation on the screen, or disk, what? ImageMagick happily reads XCF files, as well as all of the other formats that GIMP supports, so I'm curious what the issue is. Leonard -- --- Leonard Rosentholmailto:[EMAIL PROTECTED] http://www.lazerware.com ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [Gimp-user] Opening Photoshop Files
At 12:41 PM 2/8/2002 +0100, Sven Neumann wrote: Leonard Rosenthol [EMAIL PROTECTED] writes: Will it still use FreeType for the actual rendering of the glyphs? And if not, then what? yes, it will use Freetype2 but somewhat hidden behind a Pango layer. Excellent!! The advantage of using Pango on top of Freetype2 is that it takes care of all the ugly details of glyph positioning and shaping. Yup, Pango is great stuff and definitely the way to go. That should make for some VERY NICE text support in future Gimps.Now you'll just have to support PSD Text Layers ;). LDR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [Gimp-user] Opening Photoshop Files
At 8:37 PM +0100 2/7/02, Sven Neumann wrote: I hope do be able to complete the new text tool anytime soon and it is supposed to give you even better rendering than gimp-freetype combined with the features of GDynText. Will it still use FreeType for the actual rendering of the glyphs? And if not, then what? Leonard -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: XCF-PSD [was (psd plug-in, adam's plug-ins)]
At 12:40 PM 1/18/2002 +, Adam D. Moss wrote: I'd like to help testing anything related to the psd plug-in, because my projectleads are breathing down my neck about 'incompatibility' with the rest of my designer collegues. I generally use the previous state/version of the plug-in that I patch with the 'write psd' patch, as I need to send layered files back to people using Photoshop. Let me know if/how you'd like me to go about testing the plug-in. Another option is to use ImageMagick. I recently checked in full support for layered writing of PSD files, and extended the XCF support so that you can now go direct from layered XCF-PSD with all layers and layer attributes (mode, opacity, name, etc.) intact!! I hope that GIMP users will find this useful, and please send any bug reports either directly to me (since I'm the XCF and PSD maintainer) or to the ImageMagick lists. Leonard ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Bugs in PSD Reader
Found a couple of bugs (or at least what I believe to be bugs) in the PSD plugin's read/load code. 1) It assumes that all PSD files with layers will have layer mask data, range data and name. it should verify that the extra data length is still valid on those items 2) It doesn't handle padded (or blank) layer names correctly. Names are padded to four bytes, but the plug will only include the actual data (or 1 for blank names) in the offset count. Though it skips them later, it still should handle it better. If I find anything else, I'll let you know... Leonard ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plugin Request/Hunt
At 03:08 PM 12/23/2001 +1000, Robert Starr wrote: I dloaded the ImageMagick I tried to use it.. but it seems it's command line only.. That is true - it is command line mostly. There are some basic GUI's for it, but nothing too fancy at this time. Is there a gui for the app (for the mogrify command) Not at this time. There are some GUI applications for Windows that will generate Contact Sheets. One that I have seen is called ImageWalker (http://www.imagewalker.com), but I know nothing about the quality. Leonard ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plugin Request/Hunt
At 08:16 AM 12/22/2001 +1000, Robert Starr wrote: Here's the lowdown: 1-Select Contact Sheet 2-Dialogue appears asking various options: a- directory/folder containing images to be placed on the contact sheet b- resolution of the contact sheet to be made c- dpi of the contact sheet to be made d- # of rows and columns in the contact sheet e- on/off for font option (this is whether or not you want the filename under the image, and if you do, the font choices) That's about it, you hit create and it grabs the files, one at a time from the chosen directory, shrinks them into thumbnails and places them on the contact sheet according to the number of rows and colums. You can do this using the mogrify command from ImageMagick - and now that IM supports XCF files - you can even use your native GIMP files... Leonard ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Current work
At 07:12 PM 12/5/2001 -0500, Robert L Krawitz wrote: Gimp-print generates the HTML (and .pdf, and .ps) manuals at packaging time. Do keep in mind that using Gnome-Print to generate the PDF files will give you flat documents (ie. no hyperlinks, bookmarks, etc.) which are VERY USEFUL for documentation... Leonard ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] XCF support added to ImageMagick
At 06:06 AM 12/4/2001 -0800, Seth Burgess wrote: I think if you make sure to check the version of the XCF, I am pretty sure that I do, but I'll hack up some files and try it out. It already deal with the differences between the old and new headers. Now, I don't expect it to be easy to implement (involving significant chunks of the core, as Sven mentioned), but if you've got that covered please do add it! It doesn't support all the different layer compositing modes, but it does fully support loading multi-layered RGB and grayscale images and respecting their layer opacity and visibility settings. Leonard ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] XCF support added to ImageMagick
At 12:16 PM 12/4/2001 -0600, Stephen J Baker wrote: (Although it *does* mean that ImageMagick had better not be using any GIMP code to help out it's decode/display of XCF's or it'll be in breach of GPL) No GIMP code - at least not verbatim. We don't use glib and we have our own imaging engines, so all that stuff got rewritten but I did keep the general structure of loading pretty much the same so that it would be easy to make changes in the future. If anyone from the Gimp team wants to review it for potential too much copying and GPL infractions, please feel free and I will make any changes! Leonard ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] XCF support added to ImageMagick
I just thought I'd let you folks know that I just checked support for reading (writing will come later) XCF files to the ImageMagick library (http://www.imagemagick.org). Right now you'd need to get it via CVS, BUT it will be part of the standard 5.4.1 distribution due on Friday. Leonard Member, ImageMagick Studio ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
