Re: [Gimp-developer] A way to do 16 bits?
Sven wrote: Let's see. We have GIMP 2.2 done and are preparing to switch to GEGL. At this point you are trying to propose a kludge? Sorry, but I am not going to read any further... Well, the most recent ChangeLog entry for gegl is dated 3-25-04, and if it is nearly ready to use, then the CVS archive and the gegl web page are very misleading. Am I missing something? Best, -- Bill __ __ __ __ Sent via the KillerWebMail system at primate.ucdavis.edu ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A way to do 16 bits?
William Skaggs wrote: Sven wrote: Let's see. We have GIMP 2.2 done and are preparing to switch to GEGL. At this point you are trying to propose a kludge? Sorry, but I am not going to read any further... Well, the most recent ChangeLog entry for gegl is dated 3-25-04, and if it is nearly ready to use, then the CVS archive and the gegl web page are very misleading. Am I missing something? You're missing all the brainpower Øyvind Kolås has put into gggl and oxide while evaluating concepts that will get into GEGL and XCF2. See http://pippin.gimp.org for more information. Michael -- The GIMP http://www.gimp.org | IRC: irc://irc.gimp.org/gimp Wiki http://wiki.gimp.org | .de: http://gimpforum.de Plug-ins http://registry.gimp.org | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A way to do 16 bits?
Hi, William Skaggs wrote: Well, the most recent ChangeLog entry for gegl is dated 3-25-04, and if it is nearly ready to use, then the CVS archive and the gegl web page are very misleading. Am I missing something? No. Step 1 to using gegl is working on gegl. The needs for gegl before we can start using it are: 1) at least one concrete implementation of all of the abstract interfaces 2) An application that uses gegl. Something that just does a file load and file save (something like convert) would be enough - it just needs to work :) Once we have both of those, the GIMP can start migrating to those interfaces (even if they change regularly), and we can get more people working on alternative back-ends for the abstract stuff. For example, there were several people interested in optimising images in memory - that's a research project for gegl, but it's not a requirement for us before we start using it (nor, honestly, is a tile-based model - a flat big block of memory would do to start off with). Nor do we need a CMYK data model to start with - RGB8 is fine. We just need something behind those interfaces we're going to migrate to. It would be great to let people loose on gegl and that was the plan 6 months ago - get 2.2 out the door, and then put the GIMP into maintenance mode (feature chill or whetever you want to call it) until gegl had reached a stage where it could be used. That means all the people currently putting code into the GIMP would be putting code into GEGL. It may not work like that - there were a couple of features I would really have liked to see in 2.2 that didn't get in there, things like text boxes and text on a path, color management. So perhaps there will be a GIMP 2.4 after all. But we should get as many as people as possible working on gegl as soon as possible. And we need an updated design doc to do that. The unit tests and the template code that's there is a good start, but what we could do with is someone writing an update to the 1998 design docs. I've CCed gegl-developer, since that's where this belongs. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A way to do 16 bits?
Hi, William Skaggs [EMAIL PROTECTED] writes: Sven wrote: Let's see. We have GIMP 2.2 done and are preparing to switch to GEGL. At this point you are trying to propose a kludge? Sorry, but I am not going to read any further... Well, the most recent ChangeLog entry for gegl is dated 3-25-04, and if it is nearly ready to use, then the CVS archive and the gegl web page are very misleading. Am I missing something? The point you are missing is that we can't expect GEGL to mature into anything useable if we continue to not using it. The only way to make things happen is to do them. I am certainly not going to accept any such kludges in GIMP since we should finally get around to do the right thing (TM). We've been waiting for this too long already. That said, perhaps it's about time that we try to come up with a roadmap for the time after the 2.2 release... Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A way to do 16 bits?
I would be the first to applaud when 16bit is integrated, yet this does not feel right long term, because any code written for 2 layers mode will have to change when the data is correctly layout as a true 16bit number. -Joseph William Skaggs wrote: I've been thinking about three things that are highly desired but have been waiting for the migration to gegl: support for 16 bits, layer groups, and procedural layers. It seems to me that all of them can be achieved in GIMP 2 without major infrastructure changes, not perhaps in the most ideal way, but not in a kludgy way either. Given that the switch to gegl will probably entail a long development cycle, it may be worth considering what can be done in the meantime with GIMP 2. In this email I will discuss the 16-bit-depth issue, and leave the others for later. The basic idea for supporting 16 bits is to treat a 16-bit layer as two 8-bit layers, a main layer for the high byte and an auxiliary layer for the low byte. The auxiliary layer would never be visible, would not appear in the Layers dialog, and would always move together with the main layer. The thing that makes this approach feasible is that for most purposes the low byte of a 16-bit layer is invisible to the user. As a starting point, then, it can simply be ignored in computing the projection. (Some composition modes, particularly divide, may ultimately want to make use of it, though.) The program would then be to build 16-bit support gradually into tools and filters. It needn't be done all at once, because a lack of 16 bit support simply means ignoring the low byte of the input, which is not a disaster in the great majority of cases. There are really only two things, as far as I can see, that would need to be done right at the start: change the Layers dialog so that auxiliary layers don't appear, and change the layer-moving commands so that main and auxiliary layers move together. Everything else could be added over time, and nothing in GIMP would be seriously broken during the process. I look forward to feedback :-). Best, -- Bill __ __ __ __ Sent via the KillerWebMail system at primate.ucdavis.edu ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A way to do 16 bits?
Hi, William Skaggs [EMAIL PROTECTED] writes: I've been thinking about three things that are highly desired but have been waiting for the migration to gegl: support for 16 bits, layer groups, and procedural layers. It seems to me that all of them can be achieved in GIMP 2 without major infrastructure changes, not perhaps in the most ideal way, but not in a kludgy way either. Given that the switch to gegl will probably entail a long development cycle, it may be worth considering what can be done in the meantime with GIMP 2. In this email I will discuss the 16-bit-depth issue, and leave the others for later. Let's see. We have GIMP 2.2 done and are preparing to switch to GEGL. At this point you are trying to propose a kludge? Sorry, but I am not going to read any further... Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
