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
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 ___ 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] Portable XFC
On Thu, 21 Aug 2003, Leonard Rosenthol wrote: 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... Not really, since that reasoning is based on an untruth. And even if it wasn't, it's a logical fallocy to assume that because no graph-capible proposal was made, that XML was the only possible way of representing a graph in a file format. 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). That is why I suggest both a lightweight library and gegl routines for it. Actually, gegl can use the lightweight library for the loading. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon RFC: Portable XCF
On Wed, Aug 20, 2003 at 08:54:55PM -0400, Leonard Rosenthol wrote: At 11:42 PM + 8/13/03, Phil Harper wrote: as for TIFF, you wouldn't be able to do it in a standard readable TIFF, This, however, is wrong! We can represent EVERYTHING in GIMP today, and EVERYTHING for GEGL (etc.) in the future with TIFF. And other programs simply will ignore them as they do with other features of TIFF they don't support. Does TIFF support, for example, float16 data, or a CIE XYZ colorspace? I'm somewhat concerned with going with an externally standardized format, then running into a wall with it at some later point, and not being able to add a feature without breaking standards compliance. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
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: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
[EMAIL PROTECTED] (2003-08-21 at 1016.13 -0400): 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. nVidia graphics hardware uses half-float - it's useful where bandwidth is a premium - such as downloading high dynamic range images into graphics hardware at realtime rates - and in a lot of cases, a half precision float is still very useful. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Compiling 1.3 or CVS
I've been trying now for three days to get 1.3 to work. When I compile the latest source it seems to work fine. But when I run the gimp-1.3 it just exits with the message: The program 'gimp-1.3' received an X Window System error. This probably reflects a bug in the program. The error was 'BadLength (poly request too large or internal Xlib length erro'. (Details: serial 46 error_code 16 request_code 154 minor_code 20) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) With a lot of tweeking I managed to compile the CVS version and got the same result. Can anybody help? Olle -- War does not determine who is right, war determine who is left. Registered Linux User 61169 http://counter.li.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon RFC: Portable XCF
Phil Harper wrote: From: Leonard Rosenthol [EMAIL PROTECTED] To: Nathan Carl Summers [EMAIL PROTECTED] CC: The Gimp Developers' list [EMAIL PROTECTED] Subject: Re: [Gimp-developer] GimpCon RFC: Portable XCF Date: Wed, 20 Aug 2003 10:40:51 -0400 At 8:45 AM -0700 8/12/03, Nathan Carl Summers wrote: A layered TIFF by that name wouldn't cut it, because most tiff readers don't support layered images. Sure they do! Well, at least for any program that supports multiple layers/pages to begin with. And this goes to the question above... can you post a multilayer TIFF somewhere for me to try out, i've never encountered one before, and it would be interesting to see how it's handled. If my application doesn't support a particular feature of XCF, am I not compliant? Should I not bother doing XCF? it'd be nice if your app could read and render a flat version of the image if you don't support layers i supose, this is an interesting one since all these different target apps will handle things like layermodes differently, and some wouldn't even be supported. Of course, we could always use TIFF internally but call it XCF. We could do that. Adobe does that with .ai, which is really .pdf... i thought it was a kind of encapsulated post script What about mng? It contains png and has layers and comments. Seems to be basically unmaintained. I suggested it at another not so important software project and the idea went over real big!! I would like to know the GAP authors idea about mng, actually. carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon RFC: Portable XCF
At 8:26 PM -0400 8/13/03, Carol Spears wrote: What about mng? It contains png and has layers and comments. Yes, but still has the limitations of no-CMYK (Lab, ICC, etc.) colorspaces (among other things) out of the box... Seems to be basically unmaintained. PNG/MNG/JNG is fully supported and maintained by the libpng group, which is headed by Glenn Randers-Pehrson who is also one of the maintainers (along with myself) of ImageMagick and GraphicsMagick. Leonard -- --- Leonard Rosentholmailto:[EMAIL PROTECTED] http://www.lazerware.com ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
On Thu, 14 Aug 2003, Øyvind Kolås wrote: * Adam D. Moss [EMAIL PROTECTED] [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. [SNIP] 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 It actually makes a lot of sense to have GEGL support loading XCFs. It would probably be a good idea to have a separate library as well, for those apps that already have their own compositors and don't want to have another one as well. Rockwalrus ___ 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
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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [FEATURE] Some plug-in settings should bepersistent accross sessions
On Fri, 25 Jul 2003 22:23:23 +0200, David Neary [EMAIL PROTECTED] wrote: http://bugzilla.gnome.org/show_bug.cgi?id=63610 [...] It would be nice if preferences for plug-ins survived session changes. The way to do this might be in saving them to an rc file without providing an interface to changing them in the normal preferences dialog (this might be handy enough although Sven might have something to say about it). I doubt that we can do this in the Right Way before the next release. Saving these preferences should be done by the core through a well- defined interface. That's why I added a dependency on bug #101604, which tracks the changes to the PDB and plug-in API. Basically some discussion is needed. Currently, the jpeg defaults suck. I would suggest following the advice in this bug and changing the default quality to 85%. Currently this is hard-coded in the plug-in. This is something that can be done easily. In fact, I have just done it. I have increased the default quality to 85%, which seems to be a better default for most (?) users. I have just committed this tiny change to CVS. This should take care of the most annoying part of this problem, while the bigger issues can be taken care of later. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Third big serious meeting from GIMPcon
On 9 Aug 2003 at 18:35, Leonard Rosenthol wrote: 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. Well, building GIMP/Windows so that GIMP can be run isn't that complicated - building it right so it can be make installed is. Building with Cygwin seems to be rather easy once you've got recent versions of all required libraries and tools. Building with MinGW is a bit more complicated - the packages of libiconv and libintl that are linked from http://www.gimp.org/~tml/gimp/win32/downloads.html don't include import libriaries to be used with libtool. All my tries to create them with pexports and dlltool didn't produce working libs. Maybe one of the GIMPGTK/Win32 gods can enlighten a mere mortal on the modifications that need to be done to build GIMP with MinGW? Michael ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon RFC: Portable XCF
Leonard Rosenthol wrote: At 11:42 PM -0700 8/13/03, Manish Singh wrote: GEGL uses XYZ as a native format. Why? Lab is a richer model esp. for handling chromanicity and is also a standard in the print world natively. Why limit to XYZ?? I am not sure what you mean by a richer model. Lab is a one-to-one mapping of XYZ. Every color in Lab is also in XYZ and visa versa. The transforms to/from XYZ from most other colorspaces is faster. Besides, Lab is _defined_ in terms of the XYZ colorspace. (well actually Lab is defined in terms of the xyY colorspace, which in turn is defined by the XYZ color space). And XYZ is not a limit. XYZ is, to the best of the worlds scientific ability, contains every other 3 components human perception colorspace. You can convert from any colorspace to XYZ without a loss of information. And as far as it being gegl's native format, what he really means is that XYZ is used precisly in this fation. As a connection space between different colorspaces (just like most generic ICC color profiles are designed to do). -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
Guillermo S. Romero / Familia Romero wrote: To some extent, it reminds me of the Blender format (with the add on that Blender files are 64 or 32 bit, little or big endian, and all the plataforms can load them fine... Adam will love it :] ). I wrote a Blender file reading C library as part of my 'day job'... I wouldn't use the word 'love' exactly. --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 I am NOT a nut! I am the keeper of the seven universal truths! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
* Leonard Rosenthol [EMAIL PROTECTED] [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. -- .^. /V\Øyvind Kolås, Gjøvik University College, Norway /(_)\ [EMAIL PROTECTED],[EMAIL PROTECTED] ^ ^ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [FEATURE] Some plug-in settings should bepersistent accross sessions
On Tue, Aug 05, 2003 at 09:45:46AM +0200, Raphal Quinet [EMAIL PROTECTED] wrote: It would be nice if preferences for plug-ins survived session changes. The way to do this might be in saving them to an rc file without providing an interface to changing them in the normal I doubt that we can do this in the Right Way before the next release. Saving these preferences should be done by the core through a well- defined interface. Maybe I misunderstand the problem, but all perl-plug-ins can do that (and do that by default) without any extra interfaces, using parasites, for ages. They do that by default, though, and there is no UI to decide when to save - every invocation will overwrite the per-image and global defaults for the next invocation. For the plug-in writer this is fully transparent (if she uses Gimp::Fu). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp 1.3.18 - Pink backgrounds on GIF's
Adam D. Moss wrote: Okay, in that case I think I must have made a mistake in the forward-port of the 1.2.x fix to 1.3.x, because I can't reproduce this in my 1.2.x tree with the equivilent GIF plugin 4.01.00 fix in it. I'll try to spot what the forward-port does differently. I can't see anything wrong with the forward-port, and still can't reproduce this with the same mod on the 1.2.x branch. Now I can't afford any more time to look into this in the near future. Maybe someone who can reproduce this in 1.3.18 can come up with some ideas. Here's the unpublished 1.2.x gif-save plugin with the same fix that went into 1.3.17 (which I'm ASSUMING is the fix that is at the root of this problem), for comparison: http://icculus.org/~aspirin/gif.c --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 I am NOT a nut! I am the keeper of the seven universal truths! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp 1.3.18 - Pink backgrounds on GIF's
Steven P. Ulrick wrote: How do I reproduce the problem -- would I be right in thinking that if I load the GIF above, then re-save it again and re-load the result then the resulting GIF will have a pink background? I answered this question in my response above, but to reiterate, the answer is yes, if you resave the image in Gimp 1.3.18 and reload it in any version of the Gimp, GQview, ImageMagick, whatever, it now has a pink background. Okay, in that case I think I must have made a mistake in the forward-port of the 1.2.x fix to 1.3.x, because I can't reproduce this in my 1.2.x tree with the equivilent GIF plugin 4.01.00 fix in it. I'll try to spot what the forward-port does differently. --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 I am NOT a nut! I am the keeper of the seven universal truths! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp 1.3.18 - Pink backgrounds on GIF's
It is probably this checkin: http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=contextwhitespace_mode=showfile=gifload.cbranch=root=/cvs/gnomesubdir=/gimp/plug-ins/commoncommand=DIFF_FRAMESETrev1=1.30rev2=1.31 The guchar - gchar change without correcting the code using the buf isn't probably good idea? Tom ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] printing with gimp-1.3
Hi ! I have some problems, to print with gimp-1.3 and gimp-print. Here is my setup: I need =gimp-print-4.3.18, because with my Epson Photo 950, this is the only driver, that gives very good printing results. (with CUPS/KDE...) gimp-print-4.3.18 with option --with-gimp needs gimp-1.2 to compile, and installs a print plugin only for gimp-1.2, which doesn't work with gimp-1.3. So I compiled gimp-print-4.3.18 with --without-gimp. Now, If I compile gimp-1.3.17 with --enable-print, the config script searches for gimpprint-config, which doesn't exists since gimp-print-4.3.5. If I fix the config script (use pkg-config instead), gimp-1.3.17 start compiling, and gives some errors about missing/wrong headers from gimp-print ! Is there a way to get gimp-1.3.17 working with gimp-print-4.3.18 ?? Or are there plans to support goth, gimp-print-4.2 and 4.3 ?? Thanks Silvio Boehme ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
Austin Donnelly wrote: How is the serialization done then, just a raw 32-bit IEEE float dump with a predefined endianness? 64-bit doubles just as easy? The real problem comes when your code is running on a system without IEEE float support, and you need to manually convert from IEEE float to your local weird-ass machine float. Not common, I grant you, but a real pain when it bites. So it's somehow preferable to come up with our own wierd-ass float format and make life equally hard for everyone? By far the vast proportion of modern machines have IEEE float - so let's make life easy for the majority. The minority need a conversion routine no matter what we do. The last machine I used that didn't have IEEE float (some wierd Hitachi microcontroller) had convenient library functions to interconvert between it's native format and IEEE. The only other alternative is to use a storage mechanism for which there is universal conversion support - but the only format that fits that bill is ASCII - surely we aren't contemplating that for bulk image data? Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon RFC: Portable XCF
Leonard Rosenthol wrote: At 8:26 PM -0400 8/13/03, Carol Spears wrote: What about mng? It contains png and has layers and comments. Yes, but still has the limitations of no-CMYK (Lab, ICC, etc.) colorspaces (among other things) out of the box... The last time I got the mng libraries, they came along with liblcms. Are you sure that liblcms does not do all of this? Seems to be basically unmaintained. PNG/MNG/JNG is fully supported and maintained by the libpng group, which is headed by Glenn Randers-Pehrson who is also one of the maintainers (along with myself) of ImageMagick and GraphicsMagick. Sorry, my confusion. It is the plugin at that other ill-maintained godforsaken software package that is having maintenance reviews or something. Rightly or wrongly, I consider ImageMagick to be the gimps command line until it gets too ugly and you need to start scripting. Probably this is wrong also? tiff is so old. it seems like many old ideas have a lousy way of handling some of the new ideas. Sort of like comparing oggs to mp3's, the way I understand it, the framing idea is sort of a miracle to work in mp3's the way it does while with oggs this idea was built in from the beginning. This explanation explains the sound quality differences to me. I am wondering if this same line of thinking can be applied to tiffs? carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon RFC: Portable XCF
Leonard Rosenthol wrote: At 6:51 PM -0700 8/13/03, Manish Singh wrote: Does TIFF support, for example, float16 data, or a CIE XYZ colorspace? Yes to both... I'm somewhat concerned with going with an externally standardized format, then running into a wall with it at some later point, and not being able to add a feature without breaking standards compliance. Worse case is that we add new tags (that we've registered with Adobe) and other readers don't support that information... Adobe needs to register with us first. carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
On Mon, 11 Aug 2003, Adam D. Moss wrote: Nathan Carl Summers wrote: On Mon, 11 Aug 2003, Adam D. Moss wrote: IIRC, the Loki guys. Some ramblings a few years ago on the problems of interoperability of game data between windows/mac/linuxx86/linuxalpha/etc over network and on disk. They made a special point of saying something like 'never, ever serialize floats' and it sounded like the voice of experience. Java doesn't seem to have a problem with it. Even poor fools like me who are working on VM's for machines with non-IEEE floats don't have too much of a problem. That's good to know, it helps me out with some of my own stuff... How is the serialization done then, just a raw 32-bit IEEE float dump with a predefined endianness? 64-bit doubles just as easy? Yup. Rockwalrus ___ 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] gimp 1.3.18 - Pink backgrounds on GIF's
Jeff Trefftzs wrote: On Mon, 2003-08-11 at 08:49, Adam D. Moss wrote: Hi. Jeff Trefftzs wrote: Without getting fancy, I just tried this image in gimp-1.3.18 (Linux, RedHat 9). It opened with the pink background Wait, it OPENED with the pink background? You didn't have to save it out again first? Yes indeedy! I downloaded the GIF from the URL you provided. (n.b. I didn't provide a URL, I didn't report the bug) When I opened it in gimp-1.3.17 (yes, 17, not 18, my bad) it showed the pink bg. Both in preview and when I opened it. This duplicates the reported behavior, btw. Okay, that's a pretty vital difference (and the reason I asked for clarification from the original reporter about whether it requires a save-then-reload, which he said it did in contradiction to what you've just reported, hence my general confusion). This means it's a gifload.c bug, not a gif.c bug (my last change to gifload.c was strictly a LZW bugfix so I can't see a potential problem there, but I'll try to look into it :( ). Thanks, --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 I am NOT a nut! I am the keeper of the seven universal truths! ___ 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
[Gimp-developer] A couple of weeks laying low...
Hi all, So, I made my plane (thanks to Roman drc), and am now kind of recovered. I had hoped to get some computer time after a few days to take care of some backlog stuff, and keep abreast of bugs for 1.3.19... unfortunately, it now looks like I'm going to have very limited time over the next couple of weeks (I will probably find to read my mail...), so this is just to let you know that I'm not going to be doing Release Managery type stuff for at least a couple of weeks. I will write a sumary of the technical gegl and gimp 1.3 presentations that Sven, mitch, Calvin, Daniel and pippin gave, and post those to the list when I get back. Thanks for the weekend, everyone, I had a whale of a time. And I hope to see ye all soon (next year for sure). Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: PS vs. PDF
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 ___ 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] Implementing dynamic brush features
Hello. Recently I posted the following enhancement proposal: http://bugzilla.gnome.org/show_bug.cgi?id=119240 Basically, it's about adding dynamic brush features. Right now, the only non-tablet controled dynamic brush feature is color, with the gradient brush, so I'm suggesting that something more advanced be added where other features: size, opacity, hardness and even orientation are concerned. In the event that such a feature cannot be easily programmed, I also suggested a "dynamic path stroke" feature as an alternative. There's also the suggestion that one gets greater control with graphics tablets as well. I know that Gimp 2.0 has been feature-freezed for now, but there is no reason to be in a hurry over this anyway. Now, as I pointed out in Bugzilla, I've since found out that Photoshop 7 has some new dynamic features (see screenshots included in Bugzilla thread), including "jitter" (randomness I think), etc. Initially I had thought out some possible designs for the Brush tool box, but in the light of these possible new features, I think I should rethink them. Whatever the case, I don't know enough about Brush algorithms, so I have no idea what features can be implemented and what can't. Can the rest of you discuss what can be implemented and what can't, and say what you would "like" to implement or leave out? On the very short term, can you just add a "reverse" option for each feature where tablet input is concerned? This is so one can easily make brush more opaque as they become smaller, or vice versa, simple things like that... By the way, a few things I didn't find in Bugzilla, and that I find useful (they might actually be there already, maybe I didn't look hard enough, but if they really aren't, I'll add them to Bugzilla):- layer folders, useful if you work with a lot of layers. Paths folders would also be nice.- "always on top" option for each tool box. This way you can maximise a picture you're working on, and just have the toolbox you access frequently on top. Well that's all I can think of for now. Comments?Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
Stephen J Baker wrote: Austin Donnelly wrote: How is the serialization done then, just a raw 32-bit IEEE float dump with a predefined endianness? 64-bit doubles just as easy? The real problem comes when your code is running on a system without IEEE float support, and you need to manually convert from IEEE float to your local weird-ass machine float. Not common, I grant you, but a real pain when it bites. So it's somehow preferable to come up with our own wierd-ass float format and make life equally hard for everyone? By far the vast proportion of modern machines have IEEE float - so let's make life easy for the majority. The minority need a conversion routine no matter what we do. The last machine I used that didn't have IEEE float (some wierd Hitachi microcontroller) had convenient library functions to interconvert between it's native format and IEEE. I am all for IEEE FP as well. Just as an ilustration, the code I am working on for custom layer modes uses fixed point - 32bit , being 16.16. There are reasons that lead me to choose it, I can comment if it they are of interest to anyone. If the internal image format is 32bit IEEE it will be easy for me to add the needed convertions, as the 8 bit unsigned integer and 16 bit unsigned integer conversions are in place already. The only other alternative is to use a storage mechanism for which there is universal conversion support - but the only format that fits that bill is ASCII - surely we aren't contemplating that for bulk image data? Steve Baker (817)619-2657 (Vox/Vox-Mail) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ANNOUNCE: GIMP 1.3.18 released
Quoting Henrik Brix Andersen [EMAIL PROTECTED]: On Mon, 2003-08-11 at 15:00, Raphaël Quinet wrote: Here is what was discussed, according to the minutes of the Second GIMPCon meeting written by Dave (and double-checked by comparing with my own notes, just in case): 1 or 2 developer releases(one now, more or less, and another one in another 2 weeks). I thought we agreed to wait for people to commit the stuff they produced during camp before doing the 1.3.18 release? Being honest, I wanted to do a release wile I had Sven beside me :) And there will still be another release in a couple of weeks when people commit what they were working on/started in camp. Dave. -- Dave Neary Lyon, France ___ 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
On Wed, 20 Aug 2003, Leonard Rosenthol wrote: At 11:42 PM + 8/13/03, Phil Harper wrote: well, it'd be interesting to see if Adobe added XCF to Photo$hop, after all, GIMP is the competition, it wouldn't be in their interests to support a multilayered image format that it controlled by someone else(although they might support PSP, i don't know haven't checked.) They support a number of formats that they don't control - because they are standard formats that their customers are requesting. But today XCF isn't one of them, and probably won't be for a while. AFAICT, there is nothing stopping Gimp developers from creating a potatoshop plugin that can read XCF. it'd be nice if your app could read and render a flat version of the image if you don't support layers i supose, this is an interesting one since all these different target apps will handle things like layermodes differently, and some wouldn't even be supported. EXACTLY my point! Whatever file format we end up with, we need to accept that not all consumers of that file format will be able to support 100% of the features (perhaps not even GIMP itself). no, that simply wouldn't be flexible enough, surely, i mean you could have extra data about how do use the layers in the TIFF but if those aren't recognised by other readers you just get a strange result and a confused decoder. You could get that just as easily with XCF when a given consumer/reader doesn't support 100% of the features of the format... With a PNG style format, this becomes much less of an issue. First, PNG requires all readers to be able to interpret a core subset -- anything that can't interpret it violates the standard. Second, all chunks are tagged optional (meaning that they can be safely ignored if not understood or mandatory (in which case the reader will give up if it doesn't understand the chunk.) This means that a baseline PNG can be read by any compliant program (hello, IE!) without problem, and any extensions will either degrade gracefully or cause an error, but in no case will the decoder become confused and return a strange and wrong result. In this way, for example, someone could create a PNG chunk that indicated that the data was in Lab space, and a decoder that didn't recognize that feature would just give up instead of returning some garbage where the red channel gets luminence, etc. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Portable XFC
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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp 1.3.18 - Pink backgrounds on GIF's
On Mon, 11 Aug 2003 12:30:10 +0100 Adam D. Moss [EMAIL PROTECTED] wrote: Steven P. Ulrick wrote: http://www.faith4miracle.org/FaithLogo-circle.gif ... the image always displays properly before I open it in Gimp 1.3.17 or 1.3.18. Whenever I have saved one of the images that was given a pink background instead of a transparent one, there has been absolutely no error messages whatsoever. At what point is an image 'given' a pink background? Hello, Adam :) The image is first given a pink background in the preview before it is even opened. Here is an experiment I just tried: 1. Open up Gimp 1.2.3 and Gimp 1.3.18 (Examples of Gimp versions that deal with this issure correctly and incorrectly) 2. In Gimp 1.2.3, click File | Open and choose the desired image. 3. In the preview box, before the image is even opened, the image displays correctly, with a transparent background. Remember, this is in the Preview, before it's even opened. 4. At this point, we have seen that the image itself has a transparent background. So let's move on to the next step. 5. In Gimp 1.3.18, click File | Open and choose the desired image, 6. In the preview box, before the image is opened, the background is already pink. 7. Just for fun, without resaving the image we just opened twice, reopen the image that you just saw with a pink background with Gimp 1.2.3. You will notice that the background is still transparent. Okay, now open up the orginal image: http://www.faith4miracle.org/FaithLogo-circle.gif in Gimp 1.3.18 and save it under a different name. (You could save it under the same name if you wanted, but of course if you wanted to investigate this further, you'd need to get a new copy :)) Now, since you saved the formerly background-less image in the Gimp version that attatches a pink background to transparent GIF's, the image has a pink background in every version of the Gimp. It has become a permanent part of the image. How do I reproduce the problem -- would I be right in thinking that if I load the GIF above, then re-save it again and re-load the result then the resulting GIF will have a pink background? I answered this question in my response above, but to reiterate, the answer is yes, if you resave the image in Gimp 1.3.18 and reload it in any version of the Gimp, GQview, ImageMagick, whatever, it now has a pink background. As an experiment, in a few hours, I'm going to take the original logo I cut the Circle image out of, and use the same program in Windows that I cropped the circle part out to begin with, and then save it as a transparent GIF and run the same tests with that. This is just in case something funny has happened to the image itself. Which of course only changes the problem slightly But at least it may eliminate some possibilities :) Steven P. Ulrick ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
On Mon, 11 Aug 2003, Guillermo S. Romero / Familia Romero wrote: [EMAIL PROTECTED] (2003-08-08 at 1801.54 -0700): 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. PNG 32 bit names are char... or at least all them can be read. :] And I think the purpose of this was, among other ideas: easy to parse (always four chars) and makes sense with some rules about chars (caps vs normal). Even the magic of PNG had a reasoning (part binary to avoid confusion with text and capable of detecting non 8 bit transmision or bad byte order). IOW, why not make it similar, but just bigger (four char for name space and 12 more for function)? Arbitrary size strings does not seem a good idea to me. This seems like a good proposal. Another thing, alignment (and thus padding), is worth the problems it could cause? If the format has to be fast, maybe this should be taken into account, and not only about small sizes in memory (ie 32 bit), but maybe disks (ie blocks) or bigger sizes in memory (ie pages) too. Would the format be used just as storage, or would it be used as source / destination when memory is scarce. Remember that some apps are capable of working in areas instead of the full image, to improve global troughput. Right. To be mmappable, the format should be aligned. I think with careful design, there won't be too much overhead from this. When I wrote that the example was just a rough sketch, part of what I meant was that I didn't pay too much attention to bit sizes and alignment, because that would have been premature optimization. One issue with alignment is which platform's alignement rules should be used. I think a good common-denominator format can be found. It won't get the wierd ones, of course. I work on a Cray, and nothing follows cray's alignment rules. :) image data chunks should use png-style adaptive predictive compression. They should also use adam-7. I would avoid compression inside the format. Files can be compressed as a whole It does complicate in-place image manipulation, true. OTOH, you can get much better lossless compression using image-specific techniques such as predictive compression than you can using general purpose techniques. and IIRC Adam7 is about interlacing, not compression, dunno why an editor should do progressive load. Load smaller res in case of problem? I would try to avoid that instead of try to fix it, with proper storage and transmission. Load with proxy images? Too rough, IMO, it is not a scaled down version. Well, working a scaled-down version of large files is an important optimization. It's true that not all image manipulation functions can credibly be approximated with working on a scaled-down version, but that's for the gegl people to worry about. My guess is that it will be easier to use interlaced data than true scaled-down images, and the savings in terms of computational time and pipeline flexablity will be worth it. PNG compression is the one provided by zlib PNG's use zlib compression on the overall file, but the entropy is first significanty reduced by using predictive encoding. It's not the same as just running gzip on raw data. and I can show you cases in which other compressors have done a better job with my XCF files (anybody can try bzip2), and if computers keep evolving the same way, the extra CPU load is better than the disk or network transfer. True. Letting other apps do it means those apps could be general, reducing work load. Of course, but we should not sacrifice functionality for convenience. :) Or better, custom, but once the look of the data is well known and there is plenty of test cases (like FLAC but for XCF2, compression targeted at some kind of patterns). Conformance testing is very important. That is a good idea. Realize too that this links to aligment things, if you know that a layer is always somewhere and requires X MB, you can overwrite and reread without problems. This will have to be worked out. CHUNK: chunk start, optional - 2 byte bitmask with some png-like flags xcf-comment total size of chunk and subchunks - 4 bytes size of chunk - 4 bytes For all these sizes... why not 64 and be avoid future problems? If someone likes it and uses it for really big things, segmentation is a negative point. Or maybe force a small max size for each chunk (forcing segmentation) which would give more CRCs. Options, options, options... Both have their plusses and minuses. This is the comment chunk end (flags) - 2 bytes xcf-comment 1 (subchunk depth) - 1 byte crc32 - 4bytes [...] I would add unique chunk ID to each, so then can make references. Good idea. So of your list of items, 1 (lossless), 2 (portable), 3 (extensible), 4 (graphs), 7
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
How is the serialization done then, just a raw 32-bit IEEE float dump with a predefined endianness? 64-bit doubles just as easy? Yup. The real problem comes when your code is running on a system without IEEE float support, and you need to manually convert from IEEE float to your local weird-ass machine float. Not common, I grant you, but a real pain when it bites. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GimpCon RFC: Portable XCF
Several XCF formats have already been proposed; why should I propose another? It seems to me like the existing proposals have all missed the main point. While they have nice properties for certain extreme cases, they miss the boat when it comes to the main point of a graphics format, which is to efficiently store (and load) graphical information. This has lead to proposals that are neither elegant nor simple; instead they are cumbersome, with redundant, and superficial information stored, along with potential for confict between different sections of the file. But rather than detail these problems, let me suggest my own solution. Let us start with an existing graphics format, for inspiration if nothing else. The format I chose is PNG, because it is arguably the best existing lossless portable graphics format available. Before we continue, though, allow me to ennumerate what charactoristics the Gimp native format should possess, in no particular order: 1 lossless 2 portable between architectures and programs 3 extensible 4 capable of representing trees and graphs 5 recoverable from corruption 6 fast random access of data 7 able to support many color depth and spaces 8 able to represent any state that gimp maintains 9 fast loads and saves 10 compact 11 good compression of graphical data PNG certainly supports 1,2,6,7,9,10, and 11. Let us examine the other issues in more detail. Extensablity: PNG supports some degree of extensiblity, but the namespace available is quite small, being only four letters. While we could use the same chunk type name for all of our additions, say 'GIMP', and then have the first field in the chunk contain which kind of chunk it really is. But this is an inelegant hack. Capablitity of representing trees and graphs: Obviously, png's minimal extension facilities could be used to implement chunks that envelope an entire tree of chunks, but this would be difficult to reconsile with PNG's current order-based approach to metadata association, and would be awkward for GIMP-aware and non-GIMP-aware PNG readers alike. Corruption Recovery: PNG has good corruption detection, but little to facilitate corruption recovery. Representation of GIMP state: see extensibility. While PNG's faults aren't serious, we can do better. A pure XML format, by way of comparison, would fulfill requirements 1,2,3,4,7, and 8. Requirement 5 in practice would be difficult to fulfill in a pure XML format without hand-hacking, which is beyound the skills of most users. A zlib-style compression step could make some progress towards 10. An archive with XML metadata and png graphical data, on the other hand, would satisfy requirements 1,2,3,4,7,8, and 11. Requirement 6 is fulfilled for simple images, but for more complex images XML does not scale well, since every bite from the begining of the XML file to the place in which the data you are interested in is. It seems like all we have to do is combine the strengths of PNG and the strengths of XML to create a format that satisfies our requirements. What we really need is not an extensible text markup language, but an extensible graphics markup format. Such a format would bear strong resemblence to both PNG and XML. Portable XCF would use a chunk system similar to PNG, with two major differences. First, chunk type would be a string instead of a 32-bit value. Second, chunks can contain an arbitrary number of subchunks, which of course can contain subchunks themselves. At the end of each chunk is a checksum, as well as a close-chunk marker. The purpose of the close-chunk marker is to help recover in case of corruption; if no corruption is detected, the close-chunk marker is ignored. One of the major advantages of this hybred technique is that if an implementation does not understand or is not interested in a particular chunk, it can seek to the next chunk without having to read or parse any of the data in-between. image data chunks should use png-style adaptive predictive compression. They should also use adam-7. An example is worth a thousand words. Here is a simple RGB image with two layers (one with a parasite) and a comment. This is just a rough sketch of what it would look like: (labels in all capitial letters are for illustrative purposes and do not take up any space in the file.) FILE HEADER: portable xcf file version major - 1 byte version minor - 1 byte CHUNK: chunk start, optional - 2 byte bitmask with some png-like flags xcf-comment total size of chunk and subchunks - 4 bytes size of chunk - 4 bytes This is the comment chunk end (flags) - 2 bytes xcf-comment 1 (subchunk depth) - 1 byte crc32 - 4bytes CHUNK: chunk start, manditory - 2 bytes xcf-layerstack total size - 4 bytes size - 4 bytes SUBCHUNK: chunk start, manditory - 2 bytes xcf-colorspace total size - 4 bytes size - 4 bytes xcf-sRGB chunk end (flags) - 2 bytes xcf-colorspace 2 (depth) - 1 byte crc32 - 4 bytes SUBCHUNK: chunk start, manditory - 2 bytes xcf-layer total
Re: [Gimp-developer] GimpCon RFC: Portable XCF
On Thu, Aug 21, 2003 at 01:33:50AM -0400, Leonard Rosenthol wrote: why would i want to save to a file format that would render my image that's built up of layer masks and vector text layers really badly if opened in a standard viewer Because at least you COULD open it up in a standard viewer. Is it better to be able to get at the data in SOME format, but not perfect, using a 3rd party tool - OR not get ANY of your data?!?! I see no point in being able to open a GIMP-file called .tif with CIE XYZ data in it - most of the viewer would simply say: this is broken. I suppose that most of the time, the GIMP-TIFFs are so special that they cannot be viewed with a standard TIFF viewer. As already noted, if your audience cannot read GIMP-files, you can always export the image. IMO we gain nothing by using TIFF (apart from (ab?)using an existing file format). I'm still for the archive+XML+image data as PNG (or TIF?) approach - it allows the image to be manipulated externally. A thumbnail could be embedded such that it's easy to extract, so viewers have a chance to display something. so why use a format that all consumers would expect to be able to utilise 100%, it would surely confuse the hell out of your average photo$hop users to use TIFF in this way, especially if we're looking at cross compatibility. Actually, many users already DO use Photoshop and TIFF this way! If you have a multi-layered PSD file, including text layers, layer effects, etc and you save as TIFF, Photoshop writes out all the information necessary for it to coime back into Photoshop with full fidelity. BUT if you open it up in some simple TIFF viewer - of course, you don't get the same effect. GIMP's use of TIFF would be EXACTLY the same... I don't see the point of being able to get a rough approximation (or total garbage) of the image when opening it in a simple viewer. in which case you'd have to do something about a workaround, like maybe have an optional pre-rendered version of the image stored in the XCF for viewers that don't support it properly, Which is what Photoshop does in PSD... For applications that support layers, you can read them. If you don't, there is an already rendered/flattend version available. I don't like the idea of having my A3/300dpi poster stored prerendered in the file. Of course, this could be an option. But I had to work with such beasts and even on kick-ass machines, you need some patience and the files tend to get huge. GIMP has this handy thing called export, if your target audience wont be able to read an XCF then don't give them one, give then a PNG instead. Sure, and lose all the extra information that might be useful to them in other authoring environments... And what about posting things online or to archives?? I think, this could be implemented as an extra: If you export an MNG, the XML description could be embedded into the file. Then you have the archive+XML+imagedata approach but a bit reversed. It would also work for TIFF. The biggest problem I see is that users will start using weird image formats if GEGL becomes available. Maybe, I want my images to be 16.8 fixed point in HLS colorspace? There are probably only a few readers out there which are able to display this... but I may overestimate this. Also, being able to get at the layer data does not mean that you can represent the image appropiately. You'd need to implement lots of layer blending modes etc. Of course, a feature-rich libxcf could solve part of that problem. Bye, Tino. -- * LINUX - Where do you want to be tomorrow? * http://www.tu-chemnitz.de/linux/tag/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Portable XFC
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 = 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... 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: GimpCon RFC: Portable XCF
[EMAIL PROTECTED] (2003-08-08 at 1801.54 -0700): 7 able to support many color depth and spaces PNG certainly supports 1,2,6,7,9,10, and 11. Let us examine the other IIRC (did I read the spec wrongly maybe?) the upper limit is RGBA with 16 bit per channel, no arbitrary color spaces or data formats. You would have to use gray PNGs to assemble other color spaces... and never want 32 int or floats, or use a similar trick than with colour spaces, split data. I think PNG does not fit 7 without tricks. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP HEAD Win32 binaries
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. -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon RFC: Portable XCF
On Sat, 9 Aug 2003, Leonard Rosenthol wrote: I see fast loads as an absolute requirement. Then we need to also look at the GIMP itself and what can be done there. Of course. Hopefully, GIMP's file handling will improve to the point where it will load thing on an as-needed basis. Therefore, fast random access is necessary. Having load on demand via random access is what will really get you the fast loads!! If you don't solve that, then any work on the file format will be a waste towards your goal. Exactly, it's a big priority. Being compact is nice as well, because not everyone has 3 terrabyte harddrives and a T3 line into their house. Agreed, but what does this really mean in real world terms. Are we willing to sacrifice functionality to get a couple of bytes here and there? The image data is the big hit in this format - the structure will end up as a small fraction of any XCF file. We certainly shouldn't sacrifice high-priority stuff for size, but size should still be a consideration. * incremental update just update a single layer w/o rewriting the whole file! This seems like an excellent goal. It seems like you are suggesting a database-like format. Not necessarily. You should be able to do it with any format with a good catalog system, but some will be easier than others. How would you handle resizes? Either we could do immediate compaction or garbage collection. Both have their disadvantages. I think sub-chunks is a bad idea. Although a common way to represent hierarchical relationship, they can also put overhead on random access and also slow down read/write under certain conditions. How about a TIFF-like directory chunk at the beginning (except hierarchical)? That would be one solution - sure. Can you think of a better one? I just think that doing a full reinvent of an image format seems like a waste of time. Let's look at Photoshop... Photoshop is able to do 100% round-tripping of ALL of its functionality in three formats - PSD, TIFF and PDF. PDF is done via throwing their private info into an undocumented blob - so it doesn't really count. So let's look at the other two. Both PSD and TIFF are rich image formats that already address most of your original list and are well defined and supported by many existing tools (including GIMP itself). Both are extensible (TIFF more so) and would allow for additional blocks to meet our needs. Is there a good reason not to use either PSD or TIFF as the native format? The only possible argument for either is that Adobe controls them both. However, I would state that TIFF has pretty much taken on a life of its own outside Adobe (via libtiff). I think the goal of the XCF redesign is to become the de-facto standard for interchange of layered images. Certainly one aspect of this is freedom from Adobe, but in addition to being an open standard, it needs to be a standard that people have confidence in. In other words, any XCF reader should be able to read any XCF writer's output. A layered TIFF by that name wouldn't cut it, because most tiff readers don't support layered images. Of course, we could always use TIFF internally but call it XCF. We might want to change the magic number as well. I have no problem with basing Portable XCF on TIFF. It seems to be well designed without really being too overdesigned. On the other hand, I think there are a few improvements that we could make to make it better for the purposes of GIMP. /me wonders if the CinePaint people have any thoughts... Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Implementing dynamic brush features
[EMAIL PROTECTED] (2003-08-12 at 1721.12 +0100): Right now, the only non-tablet controled dynamic brush feature is color, with the gradient brush, Direction works too. Now, as I pointed out in Bugzilla, I've since found out that Photoshop 7 has some new dynamic features (see screenshots included in Bugzilla thread), including jitter (randomness I think), etc. http://www.arraich.com/ps6_tips_7brushes1.htm gives a better view of PS7 brushes. Long time ago there were mails about this (brush architecture, natural media), search and you can get things like http://www.levien.com/gimp/wetdream.html. - layer folders, useful if you work with a lot of layers. Paths folders would also be nice. Layer groups are being considered, check past mails. Maybe if you search with that name, or layer trees or something (some people seems to dream with folders, I guess, all is a folder ;] ). - always on top option for each tool box. This way you can maximise a picture you're working on, and just have the toolbox you access frequently on top. Hehe, the never ending story of wm vs apps (for this, i prefer wm, i do not buy the story of wm having to be invisible and then change the apps, each one its own way). I would add one thing: collections. Create a dir and drop brushes inside, and you get them ordered and clearly differenced from the rest (selector, tree...), not mixed. It could be done for patterns, gradients and palettes too. This is partially done, gimp lets you define dirs at will, but just that. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
Nathan Carl Summers wrote: On Mon, 11 Aug 2003, Adam D. Moss wrote: IIRC, the Loki guys. Some ramblings a few years ago on the problems of interoperability of game data between windows/mac/linuxx86/linuxalpha/etc over network and on disk. They made a special point of saying something like 'never, ever serialize floats' and it sounded like the voice of experience. Java doesn't seem to have a problem with it. Even poor fools like me who are working on VM's for machines with non-IEEE floats don't have too much of a problem. That's good to know, it helps me out with some of my own stuff... How is the serialization done then, just a raw 32-bit IEEE float dump with a predefined endianness? 64-bit doubles just as easy? --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 I am NOT a nut! I am the keeper of the seven universal truths! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] Re: GimpCon RFC: Portable XCF
On Tue, 12 Aug 2003, Austin Donnelly wrote: How is the serialization done then, just a raw 32-bit IEEE float dump with a predefined endianness? 64-bit doubles just as easy? Yup. The real problem comes when your code is running on a system without IEEE float support, and you need to manually convert from IEEE float to your local weird-ass machine float. Not common, I grant you, but a real pain when it bites. Well, since my day job is working with a non-IEEE machine, I can tell you about that pain first hand. It probably took about three days to write conversion functions between the native format and IEEE float and double. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [FEATURE] Some plug-in settings should bepersistent accross sessions
On Tue, 5 Aug 2003 11:51:05 +0200, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: On Tue, Aug 05, 2003 at 09:45:46AM +0200, Raphaël Quinet [EMAIL PROTECTED] wrote: It would be nice if preferences for plug-ins survived session changes. The way to do this might be in saving them to an rc file without providing an interface to changing them in the normal I doubt that we can do this in the Right Way before the next release. Saving these preferences should be done by the core through a well- defined interface. Maybe I misunderstand the problem, but all perl-plug-ins can do that (and do that by default) without any extra interfaces, using parasites, for ages. Yes, parasites are one part of the solution. They do that by default, though, and there is no UI to decide when to save - every invocation will overwrite the per-image and global defaults for the next invocation. Look at the comment that I recently added in: http://bugzilla.gnome.org/show_bug.cgi?id=119032 IMHO, global parasites and immediate changes to the settings could make sense for the plug-ins that are used as filters, but not for the file plug-ins. For the file plug-ins, the settings should be a per-image property that is not affected by the changes made to the other images. Otherwise, it would not be possible to work on two images at the same time and to save them with their own settings without being afraid of having the settings of one image affecting the other one(s). It is unfortunate that the file plug-ins and the other filters are all called plug-ins, because they behave differently. What may make sense for the filters (global settings) may be counter-productive for the file plug-ins. For the filters, the settings can be considered to be a property of the filter itself: it is reasonable to expect that applying the same filter to a different image will use the same settings as last time. However, this is different for the file plug-ins: the quality settings, image comments and other meta-information is a property of the image itself, not a property of the filter. I expect these values to remain unchanged while I work on an image, even if I open and save other images in the meantime. This confusion between what is the right behavior for a filter and for a file plug-in has caused some problems before. See for example: http://bugzilla.gnome.org/show_bug.cgi?id=75398 Although I fixed that bug last year, I think that the origin of the confusion was related to the concept of current settings for the JPEG plug-in. If it was clear that the current settings for the file plug-ins are per-image and not a global, then these problems would be solved. Some settings such as the image comment and other meta-data should be available from a File-Properties dialog, not when the file is saved (http://bugzilla.gnome.org/show_bug.cgi?id=61499). This would make it more obvious that they are per-image. In fact, the other settings related to the file format could also be dynamically registered as additional tabs in the meta-data editor. This is a bigger change that should probably be discussed this week at GimpCon, but the save plug-ins would not need their own dialogs and the Export feature could also be simplified. This would reduce or even get rid of the dialogs displayed when a file is saved (there are several bugs related to that). In addition, each tab could contain the buttons Reset to defaults and Save as new defaults. The user would then understand easily when the changes are saved for later and when they are not. These buttons would only apply to the settings for the current tab, not to the whole properties. This would provide an easy way to replace the image comment of an existing file by whatever you have set as the default: you would go to the tab containing the image comment and click on Reset to defaults (currently, you have to copy and paste from the Preferences). If you want to set the JPEG quality to 95% for your image, you would go to the JPEG options tab, change the value and click on Save as new defaults. The metadata dialog could pop up automatically (showing the JPEG tab) when a JPEG file is saved. Or not, if the user does not want to be bothered by this extra dialog. But it would be nice if the same dialog used for File-Properties would be re-used when saving the file. Note that I am thinking aloud here and there are plenty of details that should be ironed out (e.g., what is done by the core, what is done by the save plug-ins, how to add tabs dynamically to the meta-data editor), but this could IMHO improve the way the file plug-ins work. For the plug-in writer this is fully transparent (if she uses Gimp::Fu). Yes, this is nice. However, I am not sure that modifying the defaults every time (without user confirmation) is a really good idea. I would prefer this to be a conscious decision from the user. This affects the gimp-perl plug-ins only, but currently two users following
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] Portable XFC
On Thu, 14 Aug 2003, Sven Neumann wrote: Hi, 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). PNG is something from the dark ages? 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. s/most/all, and many other good things besides. There was however nothing mentioned that it can do better. Or did I miss something? XML is a text markup language. If the designers thought of using it for raster graphics, it was an afterthought at best. XML is simply the wrong tool for the job. The XML/archive idea is the software equivalent of making a motorcycle by strapping a go-cart engine to the back of a bicycle. It will work, of course, but it's an inelegant hack that will never be as nice as something designed for the job. But to answer your question: 1. Putting metadata right next to the data it describes is a Good Thing. The XML solution arbitrarily separates human readable data from binary data. No one has yet considered what is to be done about non-human readable metadata, but I imagine it will be crammed into the archive file some way, or Base64ed or whatever. Either way is total lossage. 2. Imagine a very large image with a sizeable amount of metadata. If this seems unlikely, imagine you have some useful information stored in parasites. The user in our example only needs to manipulate a handfull of layers. A good way of handling this case is to not load everything into memory. Say that it just parses out the layer list at the start, and then once a layer is selected and the metadata is requested, it is read in. With the XML proposal, the parser would have to parse through every byte until it gets to the part it is interested in, which is inefficient. Frankly, this wouldn't be feasable. Only two crappy ways would be possible to get around this: store everything in memory (hope you have plenty of virtual memory!) or write out a temp file with the metadata in it, for later use, and in a random-accessable format. If you're going to do that, why not do it right the first time and save yourself the trouble? 3. None of the current suggestions for archive formats do a good job with in-place editing. AR can't even do random access. Zip can do an ok job with in-place editing, but it's messy and often no better than writing a whole new file from scratch. This means that a program that makes a small change to a file, such as adding a comment, needs to read in and write a ton of crap. 4. Implementing a reader for the XML/archive combo is unnecessarily complex. It involves writing a parser for the semantics and structure of XML, a parser for the semantics and structure of the archive format, and a parser for the semantics and structure of the combination. It is true that libraries might be found that are suitable for some of the work, but developers of small apps will shun the extra bloat, and such libraries might involve licensing fun. The semantics and structure of the combination is not a trivial aspect -- with a corrupt or buggy file, the XML may not reflect the contents of the archive. With an integrated approach, this is not a concern. 5. Either the individual layers will be stored as valid files in some format, or they will be stored as raw data. If they are stored as true files, they will be needlessly redundant and we will be limited to whatever limitations the data format we choose uses. If we just store raw data in the archive, then it's obvious that this is just a kludge around the crappiness of binary data in XML. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP HEAD Win32 binaries
On 13 Aug 2003, at 21:00, Pedro Gimeno wrote: Branko Collin [EMAIL PROTECTED] wrote: I got mine from http://gnuwin32.sourceforge.net/packages/libart.htm. 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. -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: GIMP, Win32 MinGW
On 11 Aug 2003 at 1:57, Tor Lillqvist wrote: Michael Schumacher writes: The result of make after creating the libintl.a libiconv.a files: Creating library file: .libs/libgimpui-1.3.dll.a .libs/gimpui.o(.text+0x159):gimpui.c: undefined reference to `gimp_min_colors' .libs/gimpui.o(.text+0x170):gimpui.c: undefined reference to `gimp_install_cmap' .libs/gimpui.o(.text+0x1a4):gimpui.c: undefined reference to `gimp_gamma' ... and many more undefined references to 'gimp_...'. Well, the above messages doesn't seem to have much to do with libintl and libiconv import libraries. It seems that you aren't for some reason linking with libgimp's import library. The Makefile.am does have $(libgimp) in libgimpui_1_3_la_LIBADD, so it should. What does your make output from the libtool --mode=link phase look like? /bin/sh ../libtool --mode=link gcc -Ic:/usr/src/include -Wall -mms-bitfields - Lc:/usr/src/lib -o libgimpui-1.3.la -rpath /c/temp/gimp1.3/lib -version-info 18:0:0 -no-undefined -export-symbols gimpui.def gimpui.lo gimpmenu.lo gimpmiscui.lo gimpbrushmenu.lo gimpfontmenu.lo gimpgradientmenu.lo gimppatternmenu.lo gimpexport.lo ./libgimp-1.3.la ../libgimpwidgets/libgimpwidgets-1.3.la ../libgimpcolor/libgimpcolor-1.3.la ../libgimpbase/libgimpbase-1.3.la -Lc:/usr/src/lib -lgtk-win32-2.0 -lgdk-win32- 2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangowin32-1.0 -lgdi32 -lpango-1.0 -lgobject- 2.0 -lgmodule-2.0 -lglib-2.0 -lintl -liconv gcc -shared .libs/gimpui.o .libs/gimpmenu.o .libs/gimpmiscui.o .libs/gimpbrushmenu.o .libs/gimpfontmenu.o .libs/gimpgradientmenu.o .libs/gimppatternmenu.o .libs/gimpexport.o - L/c/usr/compile/gimp/libgimpbase/.libs -L/c/usr/compile/gimp/libgimpcolor/.libs -Lc:/usr/src/lib ./.libs/libgimp-1.3.dll.a ../libgimpwidgets/.libs/libgimpwidgets-1.3.dll.a ../libgimpcolor/.libs/libgimpcolor-1.3.dll.a ../libgimpbase/.libs/libgimpbase- 1.3.dll.a -lgtk-win32-2.0 -lgdk-win32-2.0 -latk-1.0 -lgdk_pixbuf-2.0 - lpangowin32-1.0 -lgdi32 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 - lintl -liconv -mms-bitfields -o .libs/libgimpui-1.3-18.dll -Wl,-retain-symbols- file -Wl,gimpui.def -Wl,--out-implib,.libs/libgimpui-1.3.dll.a Creating library file: .libs/libgimpui-1.3.dll.a .libs/gimpui.o(.text+0x159):gimpui.c: undefined reference to `gimp_min_colors' ... I found a workaround - instead of libgimp-1.3.dll.a and libgimpui-1.3.dll.a, use libgimp-1.3.a and libgimpui-1.3.a. I modified the corresponsing .la files accordingly. This makes installing a bit painful - I had to disable the install target in the libgimp Makefile and copy the two libs manually - but now I've got a working GIMP 1.3 on Win32. You mentioned that libintl.h has to be modified - is this just a #define or something else? It's just a change at one line, line 102, which should be: # if __GNUC__ = 2 !defined __APPLE_CC__ !defined __MINGW32__ (defined # __STDC__ || defined __cplusplus) The !defined __MINGW32__ had to be added, otherwise it tries to use some odd __adm__ stuff that doesn't work correctly when import libraries are involved. Thanks, this works. Michael ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon RFC: Portable XCF
Leonard Rosenthol wrote: At 9:33 PM -0400 8/13/03, Carol Spears wrote: The last time I got the mng libraries, they came along with liblcms. Are you sure that liblcms does not do all of this? A quick reread of the PNG/MNG format reveals that you can use ICC profiles, but NOT CMYK, Lab or other color spaces. That's why lcms - to handle the embedded profiles that might exist. So this combination would answer your LAB CMYK issues and possibly my need to use a greater than 256 color palette then? Rightly or wrongly, I consider ImageMagick to be the gimps command line until it gets too ugly and you need to start scripting. Probably this is wrong also? That's as good a use for IM as any ;). tiff is so old. True, but that in and of itself isn't a bad thing... Well, there are a few well designed computer things that have made it fairly unscathed throughout computer history. It takes foresight and flexiblity and probably some luck and good drugs as well. Complaints I remember reading from more technically inclined people about tiff were mostly about the lwz compression. I guess while it was not free it was also not the best way to go about doing such a thing. However, I read recently about artifacts appearing in compressed pngs, so this might not be the miracle fix I had hoped for. I will always feel a little bitter about the lwz thing. it seems like many old ideas have a lousy way of handling some of the new ideas. Such as? Can you give a specific technical example of a problem/limitation of TIFF??? I tried to explain my thoughts on this earlier. I am very pleased that historically GIMP has only borrowed methods and ideas from Photoshop that were the best idea or approach to the problem. I hope that we continue to do this. Unfortunately, this is not always the *easiest* approach; but nothing says it needs to be the hardest way either. Technically, I really liked the mng animation that I made. It was a beautiful web graphic. Lush even. carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon RFC: Portable XCF
At 3:03 AM + 8/14/03, Phil Harper wrote: the last thing Adobe wants to do is support XCF, it's a competing format belonging to a competing(and competatively priced) app. Actually, the fact that it comes from GIMP has NOTHING to do with. The fact that few (if any) of theirs users are asking for that feature, is what is driving it (or not). why would i want to save to a file format that would render my image that's built up of layer masks and vector text layers really badly if opened in a standard viewer Because at least you COULD open it up in a standard viewer. Is it better to be able to get at the data in SOME format, but not perfect, using a 3rd party tool - OR not get ANY of your data?!?! rather than in a format engineered from the ground up for all of the requirements i could have, and that is distinctive as being a GIMP image format, rather than just a really ugly TIFF? Having a distinctive image format for the GIMP is also an option - one we discussed pre-camp...I was just putting forward other alternatives that have their own advantages and disadvantages. so why use a format that all consumers would expect to be able to utilise 100%, it would surely confuse the hell out of your average photo$hop users to use TIFF in this way, especially if we're looking at cross compatibility. Actually, many users already DO use Photoshop and TIFF this way! If you have a multi-layered PSD file, including text layers, layer effects, etc and you save as TIFF, Photoshop writes out all the information necessary for it to coime back into Photoshop with full fidelity. BUT if you open it up in some simple TIFF viewer - of course, you don't get the same effect. GIMP's use of TIFF would be EXACTLY the same... in which case you'd have to do something about a workaround, like maybe have an optional pre-rendered version of the image stored in the XCF for viewers that don't support it properly, Which is what Photoshop does in PSD... For applications that support layers, you can read them. If you don't, there is an already rendered/flattend version available. but, at that point it's questionable that you'd want to view an XCFin something other than GIMP, remember, Except in the case where the user does not HAVE the GIMP - either because they just don't have it, or perhaps it doesn't exist on that OS platform... GIMP has this handy thing called export, if your target audience wont be able to read an XCF then don't give them one, give then a PNG instead. Sure, and lose all the extra information that might be useful to them in other authoring environments... And what about posting things online or to archives?? Leonard -- --- Leonard Rosentholmailto:[EMAIL PROTECTED] http://www.lazerware.com ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Portable XFC
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: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon RFC: Portable XCF
On Wed, 13 Aug 2003 23:42:36 -0700, Manish Singh [EMAIL PROTECTED] wrote: On Thu, Aug 21, 2003 at 01:38:01AM -0400, Leonard Rosenthol wrote: At 8:12 PM -0700 8/13/03, Manish Singh wrote: What's the turnaround time for that? Taking weeks or months isn't really acceptable... It's there to make sure that people don't duplicate tags - so as long as we pick pretty unique tags related to the GIMP, it's not a problem. It's not just the tags, but extending value ranges for tags (needed for the two cases above). If I am not mistaken, one cannot extend the value range of tags that are already registered. So the only solution is to define a new tag based on the old one and extending its capabilities. This also means that most TIFF readers will just discard the new tags because they are not able to deal with them. One solution (kludge) would be to encode as much of the data as possible in the standard tags (i.e., for CIE LAB) and then encoding the differences in a new tag (whatever parts of XYZ do not fit in LAB). That would allow more software to read at least a part of the data, but do we really want to do that? Probably not. For GIMP, we're better off to have a native file format we have the last word on rather than trying to co-opt something else and twisting things to work. Certainly, there should be a libxcf for other programs to use, and include thumbnails and other convenience ancillary data for simpler programs to work with. From my point of view, this is the best solution. However, there is one thing that has not been mentioned in this discussion until now: we have to state very clearly that the new XCF is meant to be an open format (or not!). There has always been some confusion about whether the current XCF could be used by other applications (e.g. file managers, indexing programs or other image editing software). I think that we have to choose one of the following two solution and not something in between: - XCF is an open format that can be used by other applications and can be used as an interchange format. In this case, every single feature of the file format has to be documented very clearly. The documentation should not lag behind the implementation (even during development). Also, the file format should use version numbers or tag names for each part of the file and there should be a way for other applications to know if understanding a given part of the file is mandatory or if it is optional (like PNG does with the naming of its tags). Ideally, the code for loading and/or saving XCF files should be available as one or two libaries distributed under the LGPL or maybe a BSD license. If XCF files can be produced by other applications than the GIMP (and other libraries than the XCF library included in the GIMP), then we should be prepared to handle files that are broken in various ways and fail gracefully. - XCF is mostly a GIMP internal file format and XCF files are not intended to be distributed widely and read or written by other applications. In this case, we can have some documentation but we make no promises to other applications. The file format can change at any time (as the GIMP developers add new features or fix some bugs in the file format) and the others have to deal with it. This also means that the file format is not a standard so nothing would prevents another application from extending XCF in some incompatible way: if XCF files are not intended for distribution, any application can do whatever it wants to do with its private version of XCF. Although I think it could have been done in a better way (more communication and more care about XCF version numbers), there is nothing really wrong in creating an incompatible version of XCF for FilmGimp/CinePaint as long as XCF files are intended to be private files for the application that created them. We are leaning towards the first solution for the new XCF file format. Previously, XCF was usually defined as belonging to the second category. If we want XCF to be an open standard that can also be used for distribution of images and exchange of files between several applications, we have to do it in the right way. We also have to be prepared to deal with the consequences: one of them will be that we cannot make any assumptions about the correctness of the files that we try to read. From now on, the GIMP will have to be (more) careful when reading the XCF files and implement some (more) error detection and recovery. Also, if we define a new version of the XCF file format to be used in GIMP 2.2 or 3.0, this means that the old versions used in GIMP 1.x and 2.0 and the versions used in FilmGimp/CinePaint will become frozen. This may not be true for the CinePaint version if the CinePaint developers do not want to adopt the new XCF file format, but I hope that we can define a new format that will suit everybody. If the old versions are
Re: [Gimp-developer] 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] ANNOUNCE: GIMP 1.3.18 released
On Tue, 2003-08-12 at 20:02, Dave Neary wrote: Being honest, I wanted to do a release wile I had Sven beside me :) And there will still be another release in a couple of weeks when people commit what they were working on/started in camp. Ahh, good - that makes sense. I initially thought our brand new road map had already been set aside ;) Sincerely, ./Brix -- Henrik Brix Andersen [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon RFC: Portable XCF
At 6:51 PM -0700 8/13/03, Manish Singh wrote: Does TIFF support, for example, float16 data, or a CIE XYZ colorspace? Yes to both... I'm somewhat concerned with going with an externally standardized format, then running into a wall with it at some later point, and not being able to add a feature without breaking standards compliance. Worse case is that we add new tags (that we've registered with Adobe) and other readers don't support that information... Leonard -- --- Leonard Rosentholmailto:[EMAIL PROTECTED] http://www.lazerware.com ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon RFC: Portable XCF
Carol Spears wrote: However, I read recently about artifacts appearing in compressed pngs, so this might not be the miracle fix I had hoped for. !!! Where did you see that? PNG uses a lossless compression scheme - if there are 'artifacts' in the image that were not there when the image was given to the PNG library then that is an extremely serious bug!! I find this very hard to believe. However, there are people who take an image (eg from a digital camera) in JPEG (which is lossy and has artifacts) and CONVERTING them to PNG and then seeing artifacts. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Second try
hmm...Agreeded. I'd suggest 10 days instead of 5 (if I, for an example, am on a heavy workload week, 5 days could not be enough to make my points, if they need soem expermenting on the codebase), But since the decision was taken, so mote it be - it's not gonna hurt. later it was agreed that 7 would be more reasonable since some people only work on it part of the week. 10 could be made for the same reason. I'll make sure it it brought up. Also, nothing has been set in stone. We are very informal around here, as always. As for the foundation., I'd be happy if it was in Europe. USA is getting more and more of those stuppid laws, including states passing super-DMCAs¨ , that if enforced would stop the Internet alltogether. It could be in both. I still need to talk to a lawyer. As was brought up at the meeting, FSF has two seperate and associated groups. FSF America and FSF Europe. Both with different monies and slightly different goals. The foundation has to care off one other thing I did not see on the summary: most, or all of the codebase must be owned by it. It would legally allow small adjusts in the license, like the recently one that clarified that there could be proprietary plug-ins for the GIMP. (Strictly in terms of the GPL, as currently the copyright holder is each individual author, there would be the need to have express permission from each author for this change). Also, there is the GNU motive - if the need arises to defend GIMP's IP in court, it is easier if the foundation is the owner, and not a lot of people spread over the world. This is a very good point. Off course there must be foolproof safeguards to keep the foundation from doing non-wanted things to the codebase. So, that GIMP should be free software should be specified in the reason of beingof such a foundation. yes, well, in america, when you incorporate as a public-benefit NPO, you can include that concept in the reason of being. Thus any move away from free software would require a dissolving of the corporation. Even if that happened, public-benefit NPO assests must be sold to another public-benefit NPO, so a hostile takeover of an NPO isn't really possible. -- Daniel Rogers ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP HEAD Win32 binaries
Branko Collin [EMAIL PROTECTED] wrote: I got mine from http://gnuwin32.sourceforge.net/packages/libart.htm. 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ANNOUNCE: GIMP 1.3.18 released
On Mon, 11 Aug 2003 14:57:00 +0200, Branko Collin [EMAIL PROTECTED] wrote: On 11 Aug 2003, at 2:45, Dave Neary wrote: This is the latest in the development series of the GIMP. This will very soon be a pre-release version for the GIMP 2.0, so all testing efforts are appreciated to help us pin down some bugs. Wasn't there going to be a 1.3.19 before going to 2.0-pre-1? When's Feature Freeze again? Here is what was discussed, according to the minutes of the Second GIMPCon meeting written by Dave (and double-checked by comparing with my own notes, just in case): 1 or 2 developer releases(one now, more or less, and another one in another 2 weeks). So yes, there will most probably be a 1.3.19 two weeks from now. Note that Dave wrote in his annoucement message that there is a new 1.3.18 release now and there would soon be a pre-release of 2.0, but he did not exclude other 1.3.x releases in the meantime. One has to read carefully... ;-) -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon RFC: Portable XCF
Leonard Rosenthol wrote: At 8:26 PM -0400 8/13/03, Carol Spears wrote: What about mng? It contains png and has layers and comments. Yes, but still has the limitations of no-CMYK (Lab, ICC, etc.) colorspaces (among other things) out of the box... Has anyone considered going to the PNG maintainers and asking for these things to be included? The GIMP project is not without influence in the OpenSource world. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 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
[Gimp-developer] Re: GimpCon RFC: Portable XCF
[EMAIL PROTECTED] (2003-08-08 at 1801.54 -0700): 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. PNG 32 bit names are char... or at least all them can be read. :] And I think the purpose of this was, among other ideas: easy to parse (always four chars) and makes sense with some rules about chars (caps vs normal). Even the magic of PNG had a reasoning (part binary to avoid confusion with text and capable of detecting non 8 bit transmision or bad byte order). IOW, why not make it similar, but just bigger (four char for name space and 12 more for function)? Arbitrary size strings does not seem a good idea to me. Another thing, alignment (and thus padding), is worth the problems it could cause? If the format has to be fast, maybe this should be taken into account, and not only about small sizes in memory (ie 32 bit), but maybe disks (ie blocks) or bigger sizes in memory (ie pages) too. Would the format be used just as storage, or would it be used as source / destination when memory is scarce. Remember that some apps are capable of working in areas instead of the full image, to improve global troughput. At the end of each chunk is a checksum, as well as a close-chunk marker. The purpose of the close-chunk marker is to help recover in case of corruption; if no corruption is detected, the close-chunk marker is ignored. One of the major advantages of this hybred technique is that if an implementation does not understand or is not interested in a particular chunk, it can seek to the next chunk without having to read or parse any of the data in-between. image data chunks should use png-style adaptive predictive compression. They should also use adam-7. I would avoid compression inside the format. Files can be compressed as a whole, and IIRC Adam7 is about interlacing, not compression, dunno why an editor should do progressive load. Load smaller res in case of problem? I would try to avoid that instead of try to fix it, with proper storage and transmission. Load with proxy images? Too rough, IMO, it is not a scaled down version. PNG compression is the one provided by zlib, and I can show you cases in which other compressors have done a better job with my XCF files (anybody can try bzip2), and if computers keep evolving the same way, the extra CPU load is better than the disk or network transfer. Letting other apps do it means those apps could be general, reducing work load. Or better, custom, but once the look of the data is well known and there is plenty of test cases (like FLAC but for XCF2, compression targeted at some kind of patterns). Realize too that this links to aligment things, if you know that a layer is always somewhere and requires X MB, you can overwrite and reread without problems. An example is worth a thousand words. Here is a simple RGB image with two layers (one with a parasite) and a comment. This is just a rough sketch of what it would look like: (labels in all capitial letters are for illustrative purposes and do not take up any space in the file.) FILE HEADER: portable xcf file Note what I said about PNG file header above. version major - 1 byte version minor - 1 byte CHUNK: chunk start, optional - 2 byte bitmask with some png-like flags xcf-comment total size of chunk and subchunks - 4 bytes size of chunk - 4 bytes For all these sizes... why not 64 and be avoid future problems? If someone likes it and uses it for really big things, segmentation is a negative point. Or maybe force a small max size for each chunk (forcing segmentation) which would give more CRCs. Options, options, options... This is the comment chunk end (flags) - 2 bytes xcf-comment 1 (subchunk depth) - 1 byte crc32 - 4bytes [...] I would add unique chunk ID to each, so then can make references. So of your list of items, 1 (lossless), 2 (portable), 3 (extensible), 4 (graphs), 7 (depth and spaces), 8 (gimp states) are a must. 5 (recoverable) will be nice, a lot, but if you want it to work, it sounds like some escaping and reserved flags will be needed (like line code in transmissions). I would forget 11 (compression), and put 10 (compact) as a secondary to 9 (fast load/save) and 6 (fast access). I would add tile based as 12. To some extent, it reminds me of the Blender format (with the add on that Blender files are 64 or 32 bit, little or big endian, and all the plataforms can load them fine... Adam will love it :] ). GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon RFC: Portable XCF
On Thu, Aug 21, 2003 at 10:16:13AM -0400, Leonard Rosenthol wrote: At 11:42 PM -0700 8/13/03, Manish Singh wrote: Supports IEEE floats, but not float16 (a 32-bit float cut in half). RH added this to filmgimp since they had established this format in their workflow with other tools already. Why would you only use half of a 32bit float?? That reduces your accuracy/precision and makes you incompatible with the rest of the world doing floating point imaging. But if your other tools already use it (for whatever reason, technical or historical) easier have GIMP support it rather than change the rest. This is precisely the reason RH decided to go with an open source solution like GIMP (they could hack float16 support in) instead of Photoshop or some other closed paint program. And admittedly, it's not a big deal to convert... And makes the file size twice as big... One of the goals of GEGL is to allow GIMP to be adapted to wacky formats like these easily. I would argue that using wacky formats is a bad thing. The more wacky you make things, the less change you have for interoperability with other tools. If you make it easier to accept wacky things, you interoperate better. Suppose someone wants to use GIMP to manipulate what their neurological imaging scanner spits out at full precision; GEGL is supposed to make that possible. Yes, there should be efforts to make the common case easily interoperable, but uncommon things should be possible with the minimum amount of hoops. It's not just the tags, but extending value ranges for tags (needed for the two cases above). And a lag time means either waiting for an updated spec, which is a holdup, or going ahead and running the risk it not being granted because someone else tried to get their conflicting values in first. The spec is only updated every 18-24 months when Adobe releases a new version of Photoshop - so you definitely don't wait for that! As for the other, yes, that is true you could wait, but nobody does... And Foo organization adds a tag with the the same value as Bar organization, for different purposes, since neither cares to wait. Part of the reason why there is a lot of bad tiff processors out there I think. With the XML+AR idea, there's a little work needed to make a DTD, and then just putting some building blocks together, like an xml library and some ar processing code (multiple implementations exist) and some convenience wrappers. Never implemented a file format, have you ;). What widely used formats have you implemented? :) Reading/Writing the 'ar' archive, and reading/writing the XML is the easy part - because you can leverage existing libraries to some extent. The toughest part is putting it all together in a library of its own that allows for full random access. Most archiving libraries are all at once solutions, they aren't designed for single file extraction. We, of course, need that. We also, as ar supports random access and single file extraction just fine. Take a look at the manpage for it sometime. :) part of the DTD/Schema work need to define how you go from a GIMP image in memory to a disk representation and then back and work out the details. And for TIFF we need to define how you go from a GIMP image in memory to TIFF tags and values. Remember GIMP has to carry around a fair amount of metadata, like layer settings, paths, parasites, etc. Worth the work, sure! Trivial - no way! It doesn't seem to me that using libtiff saves us a significant amount of work. Also, suppose customizing libtiff is needed (and it sounds like it would be), that'd mean forking libtiff and the maintainence problem of tracking the original for bugfixes and enhancements. There is no need to touch libtiff - and if there is, you don't work, you modify and then submit your changes back. libtiff is an active library, and the maintainers would happily accept changes... Yeah, but there are people out there still running outdated installed, it's harder to get them to upgrade a system library. If we add and extend tags, their definitions should go in the library, no? So what to do in the time before those changes are accepted... Also, one has to wonder why Adobe is keeping PSD around if TIFF does everything. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
* Leonard Rosenthol [EMAIL PROTECTED] [030814 16:33]: 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... 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.) GEGL will by nature be extensible, and able to do more than GIMP initially will use, this is the reason I proposed having different levels of complexity for the graph layout, and restrictions on which kinds of operations should be allowed in the baseline format. If you're calling GEGL EXTREMELY heavyweight, you should be aware that XCF with effect layers is also an EXTEREMLY heavyweight by your standards. -- .^. /V\Øyvind Kolås, Gjøvik University College, Norway /(_)\ [EMAIL PROTECTED],[EMAIL PROTECTED] ^ ^ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Portable XFC
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 ___ 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] Re: GimpCon RFC: Portable XCF
* Adam D. Moss [EMAIL PROTECTED] [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 -- .^. /V\Øyvind Kolås, Gjøvik University College, Norway /(_)\ [EMAIL PROTECTED],[EMAIL PROTECTED] ^ ^ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP HEAD Win32 binaries
Tor Lillqvist [EMAIL PROTECTED] 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon RFC: Portable XCF
On Thu, Aug 21, 2003 at 01:38:01AM -0400, Leonard Rosenthol wrote: At 8:12 PM -0700 8/13/03, Manish Singh wrote: On Wed, Aug 20, 2003 at 10:53:14PM -0400, Leonard Rosenthol wrote: At 6:51 PM -0700 8/13/03, Manish Singh wrote: Does TIFF support, for example, float16 data, or a CIE XYZ colorspace? Yes to both... Hmm, got a reference to that? It wasn't immediately apparent in my reading of the spec. See Section 19 for Floating point support in data. Supports IEEE floats, but not float16 (a 32-bit float cut in half). RH added this to filmgimp since they had established this format in their workflow with other tools already. One of the goals of GEGL is to allow GIMP to be adapted to wacky formats like these easily. TIFF only specs unsigned integer, signed integer, and IEEE floats. I forget the section, but a simple search of the TIFF6 spec led to a number of references on CIE XYZ support. Only CIE LAB is given an official type. It's a derivative of CIE XYZ, hence the references to it, but they aren't completely the same thing. GEGL uses XYZ as a native format. What's the turnaround time for that? Taking weeks or months isn't really acceptable... It's there to make sure that people don't duplicate tags - so as long as we pick pretty unique tags related to the GIMP, it's not a problem. It's not just the tags, but extending value ranges for tags (needed for the two cases above). And a lag time means either waiting for an updated spec, which is a holdup, or going ahead and running the risk it not being granted because someone else tried to get their conflicting values in first. Also nonstandard implementations that may use previously unallocated values or tags which we are trying to use. Another thing I'm worried about is simply adding to the confusion of what is a tiff file. There are few tiff readers/writers that support the entire feature set of tiff, and many broken implementations out there. True - but that's the case with EVERY SINGLE file format (graphic, wp, etc.). Only the original application for which the format was created will usually support all features. Not every feature of PNG is supported by all tools. GIMP doesn't support all features of PSD files. The fact is, WHATEVER format we end up, it needs to be understood that there will be other consumers of that format that will not (or can not) implement a full 100% of it. Yes, but TIFF has got this situation much much worse than other formats. It'd be adding more confusion to an already bad situation. There's an advantage of starting from a clean slate, and not having to worry about existing baggage. There is indeed...and there are disadvantages as well (including a LOT more time to design and then code). Not really. Nailing down a featureset has to be done regardless of the format. With the XML+AR idea, there's a little work needed to make a DTD, and then just putting some building blocks together, like an xml library and some ar processing code (multiple implementations exist) and some convenience wrappers. Also, suppose customizing libtiff is needed (and it sounds like it would be), that'd mean forking libtiff and the maintainence problem of tracking the original for bugfixes and enhancements. For GIMP, we're better off to have a native file format we have the last word on rather than trying to co-opt something else and twisting things to work. Certainly, there should be a libxcf for other programs to use, and include thumbnails and other convenience ancillary data for simpler programs to work with. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
* Nathan Carl Summers [EMAIL PROTECTED] [030813 15:39]: dunno why an editor should do progressive load. Load smaller res in case of problem? I would try to avoid that instead of try to fix it, with proper storage and transmission. Load with proxy images? Too rough, IMO, it is not a scaled down version. Well, working a scaled-down version of large files is an important optimization. It's true that not all image manipulation functions can credibly be approximated with working on a scaled-down version, but that's for the gegl people to worry about. My guess is that it will be easier to use interlaced data than true scaled-down images, and the savings in terms of computational time and pipeline flexablity will be worth it. Ideally GEGL will collapse all affine transformations, thus doing resampling only once,. that resample should ideally be from the original data, possible being stored in a tile cache for following calculations of the compositing graph. If the ability to directly from file use a scaled-down version of the image one should rather use a specialiced image format storing a image pyramid (sizes 50%, 25%, 12.5%, 6.25%, etc) that allows the gegl faucet node providing the image to use scale factor as a parameter when loading. For general operation this will not be of great importance, and thus a format providing a linear buffer be better. For 8 and 16bit integer data uncompressed png would provide random access if within a container file format. A compressed png file would be a little harder, but by making an intelligent png loader, one could get a row of tiles without much overhead, (uncompressing the preceeding tiles without actually storing the data) /pippin -- .^. /V\Øyvind Kolås, Gjøvik University College, Norway /(_)\ [EMAIL PROTECTED],[EMAIL PROTECTED] ^ ^ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Portable XFC
At 1:58 PM -0700 8/14/03, Nathan Carl Summers wrote: XML is a text markup language. If the designers thought of using it for raster graphics, it was an afterthought at best. Completely agreed. Putting image data into the XML would be bad... The XML/archive idea is the software equivalent of making a motorcycle by strapping a go-cart engine to the back of a bicycle. Not at all! It's actually an elegant solution to the problem that XML was designed around teh idea of links and NOT around a single file container model. That's why many folks including OpenOffice, Adobe, etc. are using archive formats + XML as future data storage systems - best of both worlds. 1. Putting metadata right next to the data it describes is a Good Thing. right next to is an interesting choice of terms. What does that really mean in a single file. It's in the same file - does it really need to proceed or follow it IMMEDIATELY in byte order? As long as they are in the same physical file, so that one doesn't go w/o ther other - I don't see an issue. But yes, separate physical files woudl be bad! The XML solution arbitrarily separates human readable data from binary data. As it should be. The binary data is for computers, the human readable is for both humans and computers. No one has yet considered what is to be done about non-human readable metadata, but I imagine it will be crammed into the archive file some way, or Base64ed or whatever. I would think it might be based on size - over a certain threshold it goes into the archive, otherwise it's in the XML. Either way is total lossage. Why??? 2. Imagine a very large image with a sizeable amount of metadata. OK. The user in our example only needs to manipulate a handfull of layers. A good way of handling this case is to not load everything into memory. Say that it just parses out the layer list at the start, and then once a layer is selected and the metadata is requested, it is read in. OK. With the XML proposal, the parser would have to parse through every byte until it gets to the part it is interested in, which is inefficient. Parse through the XML, sure - but NOT the archive. But the fact is that you would load the ENTIRE XML into memory (a DOM tree) at document load time - because that's your catalog of information as well as (though not necessary) your metadata store. Perhaps, and this may be where you are going, there shoudl be two XML files - one which is the master catalog and hierarchical organization system and the other which is the metadata itself. 3. None of the current suggestions for archive formats do a good job with in-place editing. AR can't even do random access. Zip can do an ok job with in-place editing, but it's messy and often no better than writing a whole new file from scratch. This means that a program that makes a small change to a file, such as adding a comment, needs to read in and write a ton of crap. Zip does just fine with in place editing and can also be used for incremental update with on-demand garbage collection. (I know, I've used it that way before). 4. Implementing a reader for the XML/archive combo is unnecessarily complex. It involves writing a parser for the semantics and structure of XML, a parser for the semantics and structure of the archive format, and a parser for the semantics and structure of the combination. Well, the XML would be parsed by libxml (most likely) and read into a DOM tree which would then be used in combination with some archive format library to read each piece on demand as necessary. It has also been suggested that libgsf (the library that OpenOffice, AbiWord and Gnumeric all use to handle XML/archive file formats) might be the solution here to handle all of this. It is true that libraries might be found that are suitable for some of the work, but developers of small apps will shun the extra bloat, and such libraries might involve licensing fun. I am pretty sure that GNOME has all of the necessary pieces we'd need - of if not, something could be found. I am pretty sure that if we decide on the archive/XML format, the real work would be in the integration. The semantics and structure of the combination is not a trivial aspect -- with a corrupt or buggy file, the XML may not reflect the contents of the archive. With an integrated approach, this is not a concern. If the XML is the catalog, then inconsistant catalogs are a problem for ANY file format that uses them. This is one of those areas where improved error handling and recovery needs to be utilized. 5. Either the individual layers will be stored as valid files in some format, or they will be stored as raw data. If they are stored as true files, they will be needlessly redundant and we will be limited to whatever limitations the data format we choose uses. If we just store raw data in the archive, then it's obvious that this is just a kludge around the crappiness of binary
Re: [Gimp-developer] Re: PS vs. PDF
Leonard Rosenthol [EMAIL PROTECTED] 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. -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon RFC: Portable XCF
From: Leonard Rosenthol [EMAIL PROTECTED] To: Nathan Carl Summers [EMAIL PROTECTED] CC: The Gimp Developers' list [EMAIL PROTECTED] Subject: Re: [Gimp-developer] GimpCon RFC: Portable XCF Date: Wed, 20 Aug 2003 10:40:51 -0400 At 8:45 AM -0700 8/12/03, Nathan Carl Summers wrote: Not necessarily. You should be able to do it with any format with a good catalog system, but some will be easier than others. How would you handle resizes? Either we could do immediate compaction or garbage collection. Both have their disadvantages. Correct. How about a TIFF-like directory chunk at the beginning (except hierarchical)? That would be one solution - sure. Can you think of a better one? Well, it needs to be a directory of some sort - whether it is TIFF-like, XML-based, ZIP-like, whatever.. I think the goal of the XCF redesign is to become the de-facto standard for interchange of layered images. Unless you get Adobe to adopt support for it in their applications - that simply won't happen! Whether you like it or not, Adobe is the standards bearer in this regard, followed by the other major commercial players - Corel, Jasc, etc. well, it'd be interesting to see if Adobe added XCF to Photo$hop, after all, GIMP is the competition, it wouldn't be in their interests to support a multilayered image format that it controlled by someone else(although they might support PSP, i don't know haven't checked.) it would be good if Jasc and Corel were to pick it up as a standard interchange format, that would put Adobe under some pressure at least. And that is also part of my suggestion for using a pre-existing format like TIFF or PSD. There is always wide support for them... but that means you'd have to leave out any new improvements to GIMP layer handling that are made, otherwise you'd be breaking compatibility with the standard(yes, that is a joke), PSD is only fully supported really by adobe, if we're going to have a standard file format that's simply a broken version of PSD5 i don't see much point. as for TIFF, you wouldn't be able to do it in a standard readable TIFF, you'd need to update the format entirely, or simply break it, which, again, defeats the object. In other words, any XCF reader should be able to read any XCF writer's output. A reasonable requirement, to an extent. Do we expect that every XCF reader support ALL features of XCF? i wouldn't expect them to, some would only want to produce a thumbnail, as with Nautilus, but i guess the standard decoder could provide a way of doing that anyway. A layered TIFF by that name wouldn't cut it, because most tiff readers don't support layered images. Sure they do! Well, at least for any program that supports multiple layers/pages to begin with. And this goes to the question above... can you post a multilayer TIFF somewhere for me to try out, i've never encountered one before, and it would be interesting to see how it's handled. If my application doesn't support a particular feature of XCF, am I not compliant? Should I not bother doing XCF? it'd be nice if your app could read and render a flat version of the image if you don't support layers i supose, this is an interesting one since all these different target apps will handle things like layermodes differently, and some wouldn't even be supported. Of course, we could always use TIFF internally but call it XCF. We could do that. Adobe does that with .ai, which is really .pdf... i thought it was a kind of encapsulated post script We might want to change the magic number as well. Wouldn't do that, since the whole idea is to maintain compatibility... no, that simply wouldn't be flexible enough, surely, i mean you could have extra data about how do use the layers in the TIFF but if those aren't recognised by other readers you just get a strange result and a confused decoder. I have no problem with basing Portable XCF on TIFF. It seems to be well designed without really being too overdesigned. On the other hand, I think there are a few improvements that we could make to make it better for the purposes of GIMP. I agree, though I think we can add all of these through additional tags and not having to redesign... i'm sure it's fine for a basis, but not to keep compatible with the existing TIFF format. /me wonders if the CinePaint people have any thoughts... Definitely! hmmm, yes, would be interesting, but they're sticking with their current tree aren't they, they wont make the eventual move to GEGL, and i thought this discussion was about the XCF version designed for it. Phil. Leonard -- --- Leonard Rosenthol mailto:[EMAIL PROTECTED] http://www.lazerware.com ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: GimpCon RFC: Portable XCF
[EMAIL PROTECTED] (2003-08-14 at 1440.34 -0400): 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. They seem to be very friendly and open about it: From http://partners.adobe.com/asn/photoshop/index.jsp Q: Why is Adobe changing the policy on how the Photoshop SDK is distributed? A: The Photoshop SDK contains Adobe-owned intellectual property and for that reason, Adobe needs to capture and verify contact information for every party that desires to use this developer kit for business or personal use. By bundling TIFF into it they are doing a nice service to spread the format and make everyone have compatible readers and writers. At least it seems clear, it is about lawyers not about technology. GSR PS: Sorry, I forgot, quotation from a document Copyright © 2003 Adobe Systems Incorporated. All rights reserved. Cos copyright laws still allow quotation, no? :] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP HEAD Win32 binaries
On 13 Aug 2003, at 19:30, Pedro Gimeno wrote: Tor Lillqvist [EMAIL PROTECTED] 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 http://gnuwin32.sourceforge.net/packages/libart.htm. 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 [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
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.) --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 I am NOT a nut! I am the keeper of the seven universal truths! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp 1.3.18 - Pink backgrounds on GIF's
Adam D. Moss wrote: Tom Mraz wrote: The guchar - gchar change without correcting the code using the buf isn't probably good idea? I think you're right. That bogus change totally sneaked under my radar... (heads will roll! :D :D :D ) If someone who sees the problem can test this fix: http://icculus.org/~aspirin/gifload.c that'd be good. I've tested it and it fixes the bug. Tom Mraz ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp 1.3.18 - Pink backgrounds on GIF's
On Mon, 2003-08-11 at 07:33, Adam D. Moss wrote: Adam D. Moss wrote: Okay, in that case I think I must have made a mistake in the forward-port of the 1.2.x fix to 1.3.x, because I can't reproduce this in my 1.2.x tree with the equivilent GIF plugin 4.01.00 fix in it. I'll try to spot what the forward-port does differently. I can't see anything wrong with the forward-port, and still can't reproduce this with the same mod on the 1.2.x branch. Now I can't afford any more time to look into this in the near future. Maybe someone who can reproduce this in 1.3.18 can come up with some ideas. Here's the unpublished 1.2.x gif-save plugin with the same fix that went into 1.3.17 (which I'm ASSUMING is the fix that is at the root of this problem), for comparison: http://icculus.org/~aspirin/gif.c --Adam Without getting fancy, I just tried this image in gimp-1.3.18 (Linux, RedHat 9). It opened with the pink background, but I could repair the transparency by (a) adding an alpha channel in the Layers and Channels Dialog and (b) select by color/clear selection. Is the problem as simple as losing the alpha channel from the GIF in the later versions? -- --Jeff Jeff Trefftzs [EMAIL PROTECTED] http://www.tcsn.net/trefftzsHome Page http://gug.sunsite.dk/gallery.php?artist=68 Gimp Gallery http://trefftzs.topcities.com/ Photo Gallery ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP HEAD Win32 binaries
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. Plase don't tell end-users yet, until I have had a chance to do some more testing myself, to avoid having lots of duplicated bug reports for trivially fixable (once found) things. (And there is also the issue that one really shouldn't make available binaries without making available also exactly the corresponding sources. The above stuff is built from CVS yesterday.) The other stuff you will (GTK 2.2.2, etc) need is at www.gimp.org/win32/downloads.html . (Note that there lately has been many Win32 fixes in GLib and GTK, and I really cannot say how well GIMP runs with the pure 2.2.2 binaries publicly availablle. Wait for GLib 2.2.3 and GTK 2.2.3, presumably this week.) --tml ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp 1.3.18 - Pink backgrounds on GIF's
Tom Mraz wrote: If someone who sees the problem can test this fix: http://icculus.org/~aspirin/gifload.c that'd be good. I've tested it and it fixes the bug. Thanks all, the fix is in. --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 I am NOT a nut! I am the keeper of the seven universal truths! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp 1.3.18 - Pink backgrounds on GIF's
On 11 Aug 2003, at 4:26, Steven P. Ulrick wrote: I've had this problem for the last two development versions of the Gimp: 1.3.17 and 1.3.18 Hopefully, to maximize the clarity of the information that I have to give you, and minimize the size of this e-mail, I will proceed with a series of links to screen shots and brief, appropriate comments. 1.For the sake of accuracy, I first include a screen-shot of GIF that has this problem, as viewed in a non-Gimp application: Gqview 1.3.2 http://www.faith4miracle.org/01-GimpSS-GQVIEW.jpg You will notice that the background is transparent, as represented by the grey/light gray checks. No problem here. [...] 5.Gimp 1.3.17: http://www.faith4miracle.org/05-GimpSS-gimp-1.3.17.jpg As you can clearly see, the background is now pink. Starting 1.3.17, the GIF plug-in has been changed in the following way (from plug-ins/common/gif.c, spacing edited to accommodate wrapping): * REVISION HISTORY * * 2003-06-16 * 4.01.00 - Attempt to use the palette colour closest to * that of the GIMP's current brush background * colour for the GIF file's background index * hint for non-transparency-aware image * viewers. NOTE that this is merely a hint * and may be ignored by this plugin for * various (rare) reasons that would usually * entail writing a somewhat larger image * file. This may be related. -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
Nick Lamb wrote: On Sun, Aug 10, 2003 at 03:02:41AM +0100, Adam D. Moss wrote: Another data point is that floats are just a bastard to serialise in a portable, precise manner. Personally I'd represent a 32-bit float with a 32-bit integer and 32-bit fixed-point fractional part. Redundant but complete-ish. (Practical better ideas welcomed.) IEEE floats are portable except for the endian issue. 32-bit floating point PCM audio is just IEEE floats prescribed as little (iirc) endian. Where did you get the idea that this was problematic? IIRC, the Loki guys. Some ramblings a few years ago on the problems of interoperability of game data between windows/mac/linuxx86/linuxalpha/etc over network and on disk. They made a special point of saying something like 'never, ever serialize floats' and it sounded like the voice of experience. --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 I am NOT a nut! I am the keeper of the seven universal truths! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp 1.3.18 - Pink backgrounds on GIF's
On Mon, 11 Aug 2003 10:58:10 +0100 Adam D. Moss [EMAIL PROTECTED] wrote: Can you provide a copy of the GIF in question? To be clear, this only happens to the GIF when when you SAVE it out from .17 or .18? If so, do you see any warnings on the console when you save from these versions? --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 I am NOT a nut! I am the keeper of the seven universal truths! Hello, Adam :) You should have already received an e-mail that I sent with a link to the original image, but I sent it to myself instead of the list :) Here is the link, though, to the image in question: http://www.faith4miracle.org/FaithLogo-circle.gif Since my original e-mail, I discovered that I didn't even have gtk+ on my system. But I since have installed gtk+-2.2.2 and recompiled and installed Gimp 1.3.18, but I still have the same problem. In reference to the following question: To be clear, this only happens to the GIF when when you SAVE it out from .17 or .18? If so, do you see any warnings on the console when you save from these versions? the image always displays properly before I open it in Gimp 1.3.17 or 1.3.18. Whenever I have saved one of the images that was given a pink background instead of a transparent one, there has been absolutely no error messages whatsoever. Thanks for your speedy response :), and when I get some time, I'll send a message telling you everyting I love about the Gimp :) Steven P. Ulrick ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ANNOUNCE: GIMP 1.3.18 released
On Mon, 2003-08-11 at 15:00, Raphaël Quinet wrote: Here is what was discussed, according to the minutes of the Second GIMPCon meeting written by Dave (and double-checked by comparing with my own notes, just in case): 1 or 2 developer releases(one now, more or less, and another one in another 2 weeks). I thought we agreed to wait for people to commit the stuff they produced during camp before doing the 1.3.18 release? ./Brix -- Henrik Brix Andersen [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
GIMP, Win32 MinGW (was: Re: [Gimp-developer] Third big seriousmeeting from GIMPcon)
Michael Schumacher writes: The result of make after creating the libintl.a libiconv.a files: Creating library file: .libs/libgimpui-1.3.dll.a .libs/gimpui.o(.text+0x159):gimpui.c: undefined reference to `gimp_min_colors' .libs/gimpui.o(.text+0x170):gimpui.c: undefined reference to `gimp_install_cmap' .libs/gimpui.o(.text+0x1a4):gimpui.c: undefined reference to `gimp_gamma' ... and many more undefined references to 'gimp_...'. Well, the above messages doesn't seem to have much to do with libintl and libiconv import libraries. It seems that you aren't for some reason linking with libgimp's import library. The Makefile.am does have $(libgimp) in libgimpui_1_3_la_LIBADD, so it should. What does your make output from the libtool --mode=link phase look like? For me it is as follows: /bin/bash ../libtool --mode=link gcc -mcpu=pentium3 -g -O2 -Wall -mms-bitfields -L/target/lib -o libgimpui-1.3.la -rpath /target/head/lib -version-info 17:0:0 -no-undefined -export-symbols gimpui.def gimpui.lo gimpmenu.lo gimpmiscui.lo gimpbrushmenu.lo gimpfontmenu.lo gimpgradientmenu.lo gimppatternmenu.lo gimpexport.lo ./libgimp-1.3.la ../libgimpwidgets/libgimpwidgets-1.3.la ../libgimpcolor/libgimpcolor-1.3.la ../libgimpbase/libgimpbase-1.3.la -Li:/target/lib -lgtk-win32-2.0 -lgdk-win32-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangowin32-1.0 -lgdi32 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -liconv rm -fr .libs/libgimpui-1.3.dll.a .libs/libgimpui-1.3.dll.aT .libs/libgimpui-1.3.la .libs/libgimpui-1.3.lai if test x`/usr/bin/sed 1q gimpui.def` = xEXPORTS; then cp gimpui.def .libs/libgimpui-1.3-17.dll.def; else echo EXPORTS .libs/libgimpui-1.3-17.dll.def; cat gimpui.def .libs/libgimpui-1.3-17.dll.def; fi gcc -mcpu=pentium3 -shared .libs/libgimpui-1.3-17.dll.def .libs/gimpui.o .libs/gimpmenu.o .libs/gimpmiscui.o .libs/gimpbrushmenu.o .libs/gimpfontmenu.o .libs/gimpgradientmenu.o .libs/gimppatternmenu.o .libs/gimpexport.o -L/src/gimp-current/libgimpbase/.libs -Li:/target/lib -L/src/gimp-current/libgimpcolor/.libs -L/target/lib ./.libs/libgimp-1.3.dll.a ../libgimpwidgets/.libs/libgimpwidgets-1.3.dll.a ../libgimpcolor/.libs/libgimpcolor-1.3.dll.a ../libgimpbase/.libs/libgimpbase-1.3.dll.a /target/lib/libgtk-win32-2.0.dll.a /target/lib/libgdk-win32-2.0.dll.a /target/lib/libatk-1.0-0.dll /target/lib/libgdk_pixbuf-2.0.dll.a /target/lib/libpangowin32-1.0.dll.a -lgdi32 /target/lib/libpango-1.0.dll.a /target/lib/libgobject-2.0.dll.a /target/lib/libgmodule-2.0.dll.a /target/lib/libglib-2.0.dll.a -lintl -liconv -mcpu=pentium3 -mms-bitfields -o .libs/libgimpui-1.3-17.dll -Wl,--image-base=0x1000 -Wl,--out-implib,.libs/libgimpui-1.3.dll.a Creating library file: .libs/libgimpui-1.3.dll.a creating libgimpui-1.3.la (cd .libs rm -f libgimpui-1.3.la ln -s ../libgimpui-1.3.la libgimpui-1.3.l a) Would you mind sharing your libiconv.a and libintl.a - and the corresponding .def files? (Sent in private reply.) You mentioned that libintl.h has to be modified - is this just a #define or something else? It's just a change at one line, line 102, which should be: # if __GNUC__ = 2 !defined __APPLE_CC__ !defined __MINGW32__ (defined __STDC__ || defined __cplusplus) The !defined __MINGW32__ had to be added, otherwise it tries to use some odd __adm__ stuff that doesn't work correctly when import libraries are involved. --tml ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Ideas for Gimp/GEGL file format.
On Fri, 8 Aug 2003, [iso-8859-1] Øyvind Kolås wrote: Date: Fri, 8 Aug 2003 21:36:05 +0200 From: [iso-8859-1] Øyvind Kolås [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Ideas for Gimp/GEGL file format. Sven could you forward this to the list, my mailing possiblities from the camp is kind of braindead. What follows is a proposal for a format to save a GEGL processing graph and it's associated data. It is not completly thought through, but it could serve as a starting point. Since a GEGL processing graph is basically somethings that ties different kinds of data together and describes how they relate to each other, separate files seems like a good idea, the files should be bundled together either in an archive, or directory. As a baseline directory access should be supported, and some other archive format like tar or ar should be chosen. sounds good. it makes sense, a GIMP file is more like a project file than a merely final image format. Being able to use popular file formats directly as layers would probably be very useful to help prevent unnecessary decoding and reencoding of files. Gimp will eventually use GEGL for compositing images, it almost makes sense to define the format used as a GEGL format instead of a gimp format, by doing this applications using GEGL, will have an easy time importing and exporting processing graphs. Eventually, that worries me deeply however the idea of doing this through GEGL and having a clearly documented standardised file format that third parties can use, and more importantly would want to use sounds fantastic. some random ramblings follow,.. my favourite kind of ramblings :) a text layer?,.. (thats kind of easy with a text filter, font parameter, and text parameter).. seems wise. a vector layer?,.. could be just a vector filter,. taking a long list of coordinates,.. vectors in text files aren't very human readable anyways,.. seems very wise. ideally would use SVG for the XML backend to allow for better interoperability with other tools, ideally GIMP and Sodipodi will eventually play together even better than Adobe Photoshop and Illustrator. For expediency you might allow legacy gfig files to be embedded (and include the associated brush information for rending the line). i have been playing with gfig quite a lot and since noticing that you can tell gfig to render as a new layer instead of on top of the current layer I have not gone back (and i seriously think it would be a much better default). Given the limited undo stack in the GIMP, having it as a seperate layer makes it so much easier to remove the whole layer rather than to try and undo each and every stroke (although again because of the limited undo stack I have tried try to make my gfig stencils using as few continuous lines as possible). I wonder why gfig even has render to current layer, users could merge layers if they really wanted. Rendering each line to a seperate layer seems like overkill for simple drawings but for much more complicated drawings or if anyone was trying to turn a gfig drawing into an animation I see how it could be useful. Later Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [FEATURE] Add optional motion constraints tothe Move Tool
On Sun, 27 Jul 2003 14:23:03 +0200, David Neary [EMAIL PROTECTED] wrote: Jakub Steiner wrote: On Fri, 2003-07-25 at 22:27, David Neary wrote: http://bugzilla.gnome.org/show_bug.cgi?id=78730 It would be nice if the Ctrl modifier did for the move tool what it did for other tools and constrained movement to 22.5 degree directions. The feature needs doing. Who wants it? The thing changed in 1.3 and now the Ctrl modifier is used to toggle the behaviour of the tool from pick to move current. So this may only mean using Shift for the constraint. However this is a little inconsistent. I would suggest we go back to how 1.2 was in this particular tool and try to use Shift where Ctrl is being used in 1.3 (I have absolutely no idea how much work this is): [...] How difficult would this be to do? If it's not that difficult, what exactly needs to be done, and are people in agreement that this is a good idea? It is not that difficult to do. The modifiers used for each tool are only referenced in a few places in the code: in the part of the tool code (for each tool) that uses the modifier, plus in the strings for the tool options dialogs. The main problem seems to agree on what should be done. Personally, I like Jimmac's proposal. His comment about the Alt modifier is also interesting. GimpCon2003 seems to be a good place and time to discuss this, agree on a consistent set of modifiers and key bindings, and implement the changes. If we agree on something, I think that the last part (implementation) could be done in about one hour. I volunteer for doing it, if I have CVS access there. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Third big serious meeting from GIMPcon
Alan Horkan wrote: I feel that way too, unfortunately it is so hard not to react in the same way and get off the downward spiral. I only very grudginly subscribed to the developer list at all. I feel that the active lead developer(s) need to admit this is not a democracy and be the bad guy, be the benevolent dictator, be the leader and take decisions that move the GIMP forward. I like the 'benevolent dictator' model for OpenSource management - it works well in so many projects - ranging from tiny three man projects right up to the Linux kernel itself. It's really hard to come to a firm decision in a timely manner in an environment where everyone's voice counts equally...doubly so if things get ugly. The art is to find a dictator who actually *is* benevolent. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 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
[Gimp-developer] The Second GIMPCon meeting
Hi again, Sorry I forgot to send the mail from yesterday to the users list - I will correct that in a moment. So here is my notes from the second big meeting we had last night, which covers the upcoming release schedule, things which are considered blockers to 2.0 pre-releases, and how we plan to get 2.0 out the door. As usual, feedback is welcome. Happy GIMPing, Dave. The Second Big Serious Meeting - 8 Aug 03, around 8pm Discussion was led by Daniel Rogers (dsrogers) but stuff said is for the most part anonymous. Partly because there shouldn't be any ad hominem attacks that way, and partly because I didn't take down any names. Present: Dan Rogers, Raphael Quinet, Dave Neary (bolsh), Sven Neumann, Mitch Natterer, Hans Brix Anderssen (brix), Jakub Steiner (jimmac), Simon Budig (nomis), Marc Lehmann, Ville Patsi (drc), Oyvind Kolas (pippin), Calvin Williamson, Roman Joss (romanofski), Maurits Rijk, Branko Collins (bbc). Topic discussion, in approximate chronological order: - - Features required for 2.0 - Documentation and web - Roadmap - Near-term release schedule - Bugs - GIMP Foundation - Release manager - Features required for 2.0 --- There was quite a lot of talk on what was required for a 2.0 release. It was agreed that a pre-release should have feature complete versions of everything going into 2.0, for obvious reasons. These can be somewhat buggy, but they should at least support what is supported in the 1.2 equivalents. The major features or API changes which it was agreed are necessary are: 1) Complete path tool (nomis) 2) Remove libgck (Sven mitch) 3) Finish the text tool (Sven) 4) Documentation (more on this later) 5) Web-site (again, more on this later) 6) Some libgimp changes which need to be made now so that we can have binary compatibility across a 2.2 release - Documentation --- We felt that with pre-releases, the documentation will become more complete. There should, however, be an effort to actively get people writing docs. The main requirement, then, for 2.0 pre-releases will be to have a working help framework, so that when people hit F1 for help, they at least get a message saying This help item does not exist yet. If you would like to help write it, contact [EMAIL PROTECTED] or some such. If documentation is going to be released as a separate package, as now seems likely, then we will need to define the interface between the core and the help pages reasonably quickly. The general idea is to more or less hard-code tagnames for a particular help topic, and get the core and help using the same tags, and agreeing on how they be communicated. This will presumably require a considerable amount of communication with the help team. We also need to have the docs browsable online so that if people want to browse them they can. - Web-site -- The new site should switch over to www.gimp.org soon. There will obviously be quite a bit of pain involved as content gets added and we get lots of your website sucks type feedback, but this will only be for the short term. We should switch to mmaybe as the main site before 2.0pre1. It was suggested to do it even earlier than that, in the region of 2 to 3 weeks time. It was also discussed whether it was a good idea to have a separate coordinator for the website. - Roadmap - As an approximate set of ideals, it was
