Re: [Gimp-developer] 2.4 showstoppers (update)
Moin, here's an update of the update. We have made good progress since last week and it is time to look at the list of showstoppers again: 78265 Add support for ICC color profiles This is now (IMO) sufficiently implemented for 2.4. Still some minor changes needed in the internals of the new profile chooser widget and at some point I should add the cache for color transformations. But this can be done without API and string changes, so it doesn't need to block the release. 156905 GimpAspectPreview doesn't respect the layer offset and ca... This is still open but as I said already, it should be possible to fix it using the available API. 349340 Alt behaves incorrectly for new rectangle/ellipse selecti... Still open and I didn't find time yet to check how important it is to get this fixed. 355545 fixing the aspect ratio for crop tool This is supposedly fixed. Haven't found much time yet to play with the tools after Martins changes but I suppose it works fine now. 356716 GimpZoomPreview is broken in some plug-ins Still two plug-ins that need to be fixed. 374854 possible optimizations in Script-Fu We have reverted the optimizations that were incomplete. Should have another look at doing them for 2.6. 387604 print plug-in needs more work After some more changes the Print plug-in is now ready for 2.4. It still has problems printing to remote printers but that is most likely not a bug in our code. 417166 Default ratio for crop tool is 1:1 instead of current la... As far as I understand, this one still needs to be looked at. It seems to be the major showstopper now. 438997 Output on stdout when using script-fu console Simon and Kevin are working on this one and I am confident that it will be fixed at some point. But we probably don't absolutely have to do this before the release. 459518 Channel preview becomes black when the channel is deselected I am tempted to ignore this for now and accept it as a trivial regression. All in all it looks as if we are done with API and string changes. So even though there are still some bugs on the milestone, none of them should block the 2.4.0-rc1 any longer. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 showstoppers
Hi, On Tue, 2007-08-07 at 10:05 +, Karl Günter Wünsch wrote: I just stumbled across a similar issue with the latest version (at most a few days old, I'll update to the head later tonight (GMT) : If I select the whole image (pressing CTRL-A) and then I select a rectangle area out of that image with the rect selection tool the area does not replace the previous selection as it did previously - so that cropping to selection doesn't work. I can not reproduce this. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] 2.4 showstoppers
Moin, there are still some bugs left on the 2.4 milestone and I would like to comment on them, perhaps raising some interest here: 78265 Add support for ICC color profiles I am currently finishing the remaining bits. Since last night the color-managed display actually does the right thing. There are still some things left to be done in the lcms plug-in though. 156905 GimpAspectPreview doesn't respect the layer offset and ca... I believe that this one can be fixed using the existing API. We should definitely try to fix it in 2.4 but it doesn't need to block the release. 349340 Alt behaves incorrectly for new rectangle/ellipse selecti... Should probably be looked at. We should get the interaction right for the 2.4 release and not change it later unless absolutely needed. 355545 fixing the aspect ratio for crop tool As fas as I know Martin is working on this and expects to have it ready soon. 356716 GimpZoomPreview is broken in some plug-ins There are two more plug-ins that need to be fixed. Probably some low hanging fruits... 360106 GimpPdbDialog appears behind plug-in dialogs I still don't know how to best address this one. Perhaps set the stay-on-top flag on the PDB dialogs. That would be ugly though. 374854 possible optimizations in Script-Fu This one can possibly be closed or moved from the milestone. Waiting for a comment from Kevin. 387604 print plug-in needs more work We have come a good deal further here and I think that the remaining issue is actually a GTK+ bug. 417166 Default ratio for crop tool is 1:1 instead of current la... This is part of the rectangle tool rewrite that Marting will hopefully bring to a releasable state soon. 434205 don't display color conversion dialog if compiled w/o lcm... I'll fix this while completing the color management functionality. 438997 Output on stdout when using script-fu console Looks like a low-hanging fruit. Some help from Kevin would be appreciated. 459518 Channel preview becomes black when the channel is deselected No idea how we can fix this one without reverting a lot of changes that I really would not want to revert. Perhaps we can keep it for 2.4 as a small regression and try to fix it later. If we can get at least the color management and the rectangle tools finished before the weekend, then we might even manage to roll out a release candidate from Camp (http://events.ccc.de/camp/2007). If we don't manage to make the release candidate this weekend, then 2.4 will probably have to wait a little longer. I will be completely off-line for three weeks starting from the 18th of August. This will be my honeymoon and you guys would make me the best of all wedding presents if we could get 2.4rc1 out before I leave. And perhaps 2.4.0 released before I return... Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 showstoppers
On Tuesday 07 August 2007 07:43, Sven Neumann wrote: 349340 Alt behaves incorrectly for new rectangle/ellipse selecti... Should probably be looked at. We should get the interaction right for the 2.4 release and not change it later unless absolutely needed. I just stumbled across a similar issue with the latest version (at most a few days old, I'll update to the head later tonight (GMT) : If I select the whole image (pressing CTRL-A) and then I select a rectangle area out of that image with the rect selection tool the area does not replace the previous selection as it did previously - so that cropping to selection doesn't work. Only after trying to crop to selection you see what has happned: the selection seems to be both the whole image and the selected rectangle! -- mfg Karl Günter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 showstoppers
Sven Neumann ([EMAIL PROTECTED]) wrote: 374854 possible optimizations in Script-Fu This one can possibly be closed or moved from the milestone. Waiting for a comment from Kevin. [...] 438997 Output on stdout when using script-fu console Looks like a low-hanging fruit. Some help from Kevin would be appreciated. I'll look into these when at the camp. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 showstoppers
Hi gimp developers, I am using 2.3.x for quite some time now and it was wonderful to see how things were getting better with each release. Thank you very much and keep on the good work. Laurenz Gamper ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 showstoppers
From: Sven Neumann [EMAIL PROTECTED] Date: Wed, 20 Dec 2006 08:35:35 +0100 On Tue, 2006-12-19 at 10:54 -0800, Akkana Peck wrote: And a few RFEs which would be needed to get the print dialog to functionality comparable to the existing gimp-print plug-in. I don't know whether these belong to gtkprint or gimp: - No way to adjust margins - Page Setup should be in the Layout tab, not a separate dialog - No live preview I don't think that comparable functionality is a goal of the new Print plug-in. People can always install the gutenprint plug-in if they need this functionality. Not saying that the new Print plug-in shouldn't be improved, but it should not be our goal to overload it until is has all the features that the gimp-print plug-in had. Whatever one thinks of all the color adjustments and the Gimp-Print/Gutenprint UI in general, the live preview and margin/page adjustments always attract comment if something breaks about them... -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 showstoppers
Sven Neumann writes: I don't think that comparable functionality is a goal of the new Print plug-in. People can always install the gutenprint plug-in if they need this functionality. Robert L Krawitz writes: Whatever one thinks of all the color adjustments and the Gimp-Print/Gutenprint UI in general, the live preview and margin/page adjustments always attract comment if something breaks about them... The live preview is essential for non-geeky people and visually oriented people (artist types), who aren't going to try to go from text like .8 inches, Reverse Landscape to visualizing what will actually be printed. I might be biased. Gimp-print, and particularly its live preview, was the key that enabled me to switch to Linux full-time back in the day. Before that I'd been fighting with Photoshop LE, which had an absolutely horrible print UI: you had to click a secret unlabelled area in the status bar to pop up a preview window, which consisted of a white rectangle with an X over the part that would be printed. Gimp-print's low-res preview showing the actual image may not have been perfect, but it was a huge improvement in usability over anything I'd found on Windows. Setting unequal margins is an intermediate case. That's really useful for one task a lot of non-geeky users might like to do: printing holiday cards. But maybe that one's less important since there's a workaround, even if it's more hassle (position the image on a white canvas 2.x times as large). -- ...Akkana Beginning GIMP: From Novice to Professional: http://gimpbook.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 showstoppers
Sven Neumann writes: thanks for looking at the plug-in. It would help a lot if we could split your list into problems of the Print plug-in and problems of the GtkPrint API. The latter would have to be reported against GTK+. I've filed a gimp bug (#387604) on the unit factor problems (I suspect the dialog disappearing on Print Preview is the same problem; at least it's not easily separable from it right now). I'm not sure which of the other problems is GtkPrint vs. GIMP, because I'm not familiar with what GtkPrint does. Two bugs that seem worth filing: - Not reading the system paper size (I'm guessing this is gtkprint) - Two different functions named Page Setup (I'm guessing this is GIMP) Do my guesses sound right? And a few RFEs which would be needed to get the print dialog to functionality comparable to the existing gimp-print plug-in. I don't know whether these belong to gtkprint or gimp: - No way to adjust margins - Page Setup should be in the Layout tab, not a separate dialog - No live preview -- ...Akkana Beginning GIMP: From Novice to Professional: http://gimpbook.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 showstoppers
Hi, On Tue, 2006-12-19 at 10:54 -0800, Akkana Peck wrote: And a few RFEs which would be needed to get the print dialog to functionality comparable to the existing gimp-print plug-in. I don't know whether these belong to gtkprint or gimp: - No way to adjust margins - Page Setup should be in the Layout tab, not a separate dialog - No live preview I don't think that comparable functionality is a goal of the new Print plug-in. People can always install the gutenprint plug-in if they need this functionality. Not saying that the new Print plug-in shouldn't be improved, but it should not be our goal to overload it until is has all the features that the gimp-print plug-in had. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 showstoppers
Hi, I am picking up on a mail that is more than a month old, but the issue is still unresolved. Let me bring it to your attention again. On Wed, 2006-11-15 at 21:59 +0100, Sven Neumann wrote: That brings up another showstopper for 2.4 that is missing from the list I posted earlier. We need to check if the new print plug-in is ready for release. Since I don't use GTK+ 2.10 yet, I didn't get a chance to have a look at it yet. What requirements should be met by this plug-in to consider it ready for release? It should at least do the basic things right. In other words, print a single image, allowing the user to specify the size and location on paper. Should probably default to the original size (determined by the image resolution) if that fits to the printable area. Otherwise it should scale the image down while preserving the aspect ratio. For this plug-in I think we should focus on keeping it simple. Enough to fulfill basic printing needs but still usable without reading a manual. People who need more control can always install the gutenprint plug-in. Has anyone done this evaluation? If not, can someone please volunteer to do it? We need to find out if we can we ship the plug-in as is or if there are issues that need to be addressed before 2.4. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 showstoppers
Sven Neumann writes: That brings up another showstopper for 2.4 that is missing from the list I posted earlier. We need to check if the new print plug-in is ready for release. Since I don't use GTK+ 2.10 yet, I didn't get a chance to have a look at it yet. [ ... ] It should at least do the basic things right. In other words, print a single image, allowing the user to specify the size and location on paper. Should probably default to the original size (determined by the image resolution) if that fits to the printable area. Otherwise it should scale the image down while preserving the aspect ratio. For this plug-in I think we should focus on keeping it simple. Enough to fulfill basic printing needs but still usable without reading a manual. People who need more control can always install the gutenprint plug-in. Has anyone done this evaluation? If not, can someone please volunteer to do it? We need to find out if we can we ship the plug-in as is or if there are issues that need to be addressed before 2.4. I just upgraded to a distro that has gtk 2.10, so I can do the evaluation -- though for my own use I'm fairly happy with gimp-print/gutenprint. I just tried the print plug-in in current CVS. This is the first time I've actually seen it, and I'm happy to see that there's a gnomeprint dialog now that lets me set printer parameters. But I found quite a few problems, and ultimately wasn't able to print anything with it: - Bug: the Layout tab comes up with a unit of Inches, but Width and Height which are the pixel dimensions of the image. I hate to think what it would do if I let it print at 1160 inches wide. - The Layout tab is really difficult to use compared to gimp-print, because it has no live preview. I have to click on the Page Setup button (why isn't that right in the Layout tab?) then try to guess what it means by Portrait, Reverse Landscape, etc. and what it will do for margins (does it always center, or what?) - Minor Bug: the Page Setup dialog came up with the wrong paper size (A4 vs. my system default of Letter). - UI issue: there's a Page Setup tab, plus a Page Setup button in the Layout tab which has a completely different function. Shouldn't one of these be renamed? (Moving the Page Setup button/ dialog options into the Layout tab and eliminating the dialog would solve this.) - There doesn't seem to be any way to position an image on the page, so this dialog doesn't replace gimp-print for functions like printing out my holiday cards, where I have to print to the lower half of a page which will then be folded over. - When I try to change the Width in inches to 4, as soon as I leave the Width field it reverts to the old value of pixel width. So I can't actually try printing anything to check the quality. - When I click Print Preview, the dialog disappears and I get a GIMP Message dialog with a nice clear error message: Procedure 'gimp-image-set-unit' has been called with value 'pixels' for argument 'unit' (#2, type GimpUnit). This value is out of range. -- ...Akkana Beginning GIMP: From Novice to Professional: http://gimpbook.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 showstoppers
Hi, thanks for looking at the plug-in. It would help a lot if we could split your list into problems of the Print plug-in and problems of the GtkPrint API. The latter would have to be reported against GTK+. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 showstoppers
On Sat, 18 Nov 2006 21:24:10 +0100, Mukund [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Ahh, I did not see what your previous comment meant. Caught out by this damn ML reply-to setting again. I'm subscribed to several lists which operate in a more logical way: I get a msg from the list , I hit reply in my email client and it replies to the list. Since the msg came from the ml not from your address the reply-to header is counter intuitive. It actually isn't. You may want to read this: http://www.unicom.com/pw/reply-to-harmful.html Kind regards, Mukund It isn't what? Counter intuitive, it is. I get an email for the list not from the individual, when I hit reply it replies to the individual I need to reply to the sender, ie the list. There may be arguements for and an against but pls let's not start swamping gimp-devel with that. I was simply offering my appologies for the confusion and explaining why. gg. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 showstoppers
[EMAIL PROTECTED] wrote: Ahh, I did not see what your previous comment meant. Caught out by this damn ML reply-to setting again. I'm subscribed to several lists which operate in a more logical way: I get a msg from the list , I hit reply in my email client and it replies to the list. Since the msg came from the ml not from your address the reply-to header is counter intuitive. It actually isn't. You may want to read this: http://www.unicom.com/pw/reply-to-harmful.html Kind regards, Mukund signature.asc Description: OpenPGP digital signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 showstoppers
On Saturday, November 18, 2006, 21:24:10, Mukund wrote: It actually isn't. You may want to read this: http://www.unicom.com/pw/reply-to-harmful.html Thankfully, some e-mail clients can work around this annoyance (sadly, it's not automatic, so I often misdirect my first message on such lists). -- Jernej Simonèiè http://deepthought.ena.si/ In matters of dispute, the bank's balance is always smaller than yours. -- Checkbook Balancer's Law ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 showstoppers
On Fri, 17 Nov 2006 08:26:14 +0100, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Wed, 2006-11-15 at 19:22 +0100, [EMAIL PROTECTED] wrote: when you said your list of stoppers was open for discussion I though you meant is was open for discussion. Open for discussion on the mailing list, yes. But if you send your mail to me alone (which is what the mail header indicated you did), then we can't have a discussion and the issue is likely going to be forgotten. Sven Ahh, I did not see what your previous comment meant. Caught out by this damn ML reply-to setting again. I'm subscribed to several lists which operate in a more logical way: I get a msg from the list , I hit reply in my email client and it replies to the list. Since the msg came from the ml not from your address the reply-to header is counter intuitive. Return-Path: [EMAIL PROTECTED] From: Sven Neumann [EMAIL PROTECTED] Plus I have to remember the reply policy is opposite to other MLs I use. I get it right most of the time. Appologies for the occasional lapse of concentration. regards, gg. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 showstoppers
On Wed, 15 Nov 2006 18:51:10 +0100, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Wed, 2006-11-15 at 11:14 +0100, [EMAIL PROTECTED] wrote: There is still drift on rotation tool using interpolation=NONE How pointless to tell me. Please make sure that there's a bug report about it and that it has the 2.4 milestone set. Sven I thought it was the responsability and privelege of those with cvs commit rights to determine development milestones for not just anyone. when you said your list of stoppers was open for discussion I though you meant is was open for discussion. If it is not then you are right my post was pointless. sorry. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 showstoppers
Hi, On Wed, 2006-11-15 at 19:22 +0100, [EMAIL PROTECTED] wrote: when you said your list of stoppers was open for discussion I though you meant is was open for discussion. Open for discussion on the mailing list, yes. But if you send your mail to me alone (which is what the mail header indicated you did), then we can't have a discussion and the issue is likely going to be forgotten. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] 2.4 showstoppers
Moin, slowly but steadily the state of GIMP 2.3 is reaching a point where it can be released as 2.4. I would like to point out some showstoppers in the hope that we can get some help with them. There is also the list of bugs on the 2.4 milestone in Bugzilla and this mail somewhat overlaps with that. But it also mentions a few things that are not in Bugzilla (but probably should be). Here's a small list of outstanding items for GIMP 2.4, from the top of my head, incomplete and subject to discussion: Finish rectangle tools The rewritten rectangle tools (rect and ellipse select as well as crop) are getting better, but there are still some regressions (mainly in the Crop tool, see Bugzilla) and the tool options still need an overhaul. Would be nice if we could come up with a decent tool options UI proposal, then implement it. Finish color management Main feature missing here is giving the display filters access to the image's color profile. As soon as that is implemented, we should have a prepress professional review the functionality. I would also like to further improve the color management preferences. In this case it seems like a good idea to try to get something that resembles the Photoshop color management configuration in terms of terminology and policies. Finish healing brush The healing brush is a really nice feature but it was never completed. Currently it somewhat works, but only if you use it as a stamp, not if you paint with it. That behaviour is so vastly different from all other painting tools, I don't think we want to ship this with 2.4 unless it gets changed. The change shouldn't be too difficult, I hope. Instead of processing the pixels directly, the tool should act like the Clone tool until you release the mouse button. Then it should process the painted area and do the healing magic. In order to get this implemented, it may be necessary to look into optimizing the healing algorithm. Would be nice to get a small benchmark for it. Even better if the benchmark also acted as a regression test. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 showstoppers
On 11/15/06, Sven Neumann wrote: I would also like to further improve the color management preferences. In this case it seems like a good idea to try to get something that resembles the Photoshop color management configuration in terms of terminology and policies. Sven, I would strongly recommend work out common terminology with developers of other open source projects instead. Having uniform terminology is one of the reasons the OpenIcc project [1] exists: commercial applications fail to provide uniform terminology, even within one product line. Same advice for policies. [1] http://www.freedesktop.org/wiki/OpenIcc Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 showstoppers
Hi, On Wed, 2006-11-15 at 11:51 +0300, Alexandre Prokoudine wrote: I would strongly recommend work out common terminology with developers of other open source projects instead. Having uniform terminology is one of the reasons the OpenIcc project [1] exists: commercial applications fail to provide uniform terminology, even within one product line. Same advice for policies. [1] http://www.freedesktop.org/wiki/OpenIcc I know about the OpenICC project and I am subscribed to the mailing-list. But I don't think they can provide me with a decent proposal for color management policies and what terms to use. Or did I just overlook something on the OpenICC website? Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 showstoppers
On 11/15/06, Sven Neumann wrote: I know about the OpenICC project and I am subscribed to the mailing-list. But I don't think they can provide me with a decent proposal for color management policies and what terms to use. If by them you are referring to developers of Scribus, ICC-Examin, LProf etc. and technical specialists of Lexmark, HP and Adobe, then, most likely, yes -- they can. If you are referring to somebody else from that list, then it could be both yes and no ;) Following pages are of interest: http://www.oyranos.org/wiki/index.php?title=What_the_users_want http://www.oyranos.org/wiki/index.php?title=Concepts Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 showstoppers
Hi, On Wed, 2006-11-15 at 21:05 +0300, Alexandre Prokoudine wrote: If by them you are referring to developers of Scribus, ICC-Examin, LProf etc. and technical specialists of Lexmark, HP and Adobe, then, most likely, yes -- they can. If you are referring to somebody else from that list, then it could be both yes and no ;) See it like this. Color management has been on the GIMP agenda for several years now. In all this time noone has cared about making a spec that defines what should be implemented. Now I am trying to get it done and I have done some research and believe that I can get something reasonably implemented which happens to vaguely resemble the PS color management workflow which is rather well documented online. I simply lack the time to start such a discussion on OpenICC now. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 showstoppers
On Wednesday 15 November 2006 10:05, Alexandre Prokoudine wrote: On 11/15/06, Sven Neumann wrote: I know about the OpenICC project and I am subscribed to the mailing-list. But I don't think they can provide me with a decent proposal for color management policies and what terms to use. If by them you are referring to developers of Scribus, ICC-Examin, LProf etc. and technical specialists of Lexmark, HP and Adobe, then, most likely, yes -- they can. If you are referring to somebody else from that list, then it could be both yes and no ;) Following pages are of interest: http://www.oyranos.org/wiki/index.php?title=What_the_users_want http://www.oyranos.org/wiki/index.php?title=Concepts Alexandre For the most part the existing OSS applications that are color management aware more or less use terminology and policy settings that are similar to Photoshop. Some only implement a subset and others have a much more complete implementation. So in a way Sven is correct and if this approach were followed (IE. model this after photoshop) that at the very least would be a good starting place and most CM savvy users would feel comfortable with the result. But I am also sure that if the OpenICC list were queried for some expertise to help with finalizing the design of the CM UI that you would in fact get someone (perhaps even a small group) who would provide the needed expertise. In addition to virtually every OSS project that has an interest in CM having someone from their development team subscribed to the OpenICC list there is a wide range of CM experts and professionals including authors of books on the subject and as Alexander points out representatives from various manufacturers and the ICC itself.Making the OpenICC list a valuable resource for any OSS project that is involved in implementing CM awareness. In addition you might find that these experts have places were they feel the photoshop way of doing things has problems and issues and that you might see some proposals that would result in the CM support actually being better than it is in photoshop. Also some time ago I put together a fairly detailed description of what was needed and where this should be located in the GIMP menu structure that I submitted to this list. There have been similar proposals from others as well. For the most part these are similar to photoshop's implementation. With the exception of printer CM support there is not that much work that needs to be done to GIMP to finish off the CM implementation. One area were many on the OpenICC list agree is that the photoshop/proprietary OS approach to CM could be substantially improved in the area of printing. My GIMP proposal did not deal with color managed printing since my vision for how this should be handled would require significant changes to the gimp-print/guten-print plugin that I think are beyond the scope of 2.3/2.4 and are in fact significantly different from how this is handled in photoshop. Besides at this time there is PhotoPrint which will fill this gap, at least for Linux users, until such time as guten-print can implement CM support. So I don't view CM printing support as necessary for the 2.3/2.4 release cycle. But I would be willing to help design this if someone though that this was in the scope of the current release cycle. My printer proposal is in the OpenICC archives and if anyone here is interested I am sure I can dig it out and clean it up. Hal Engel LProf Project ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 showstoppers
Hi, On Wed, 2006-11-15 at 11:02 -0800, Hal V. Engel wrote: Also some time ago I put together a fairly detailed description of what was needed and where this should be located in the GIMP menu structure that I submitted to this list. There have been similar proposals from others as well. For the most part these are similar to photoshop's implementation. Yes, I based quite some design decisions on these proposals. With the exception of printer CM support there is not that much work that needs to be done to GIMP to finish off the CM implementation. Printing is left to plug-ins, so we don't need to deal with it except for providing ways for the plug-in to access the color management settings and the color profile that is attached to the image. Both is implemented already. What's left for implementation is color managed display, but there's just a small step missing there. We should perhaps also try to add the separate plug-in to the GIMP tree or provide similar functionality. If we can get this implemented correctly and make sure that the defaults are well chosen and that basic color managed workflows are supported, we can IMO release 2.4 with this. After the release we will have time to improve things further. One area were many on the OpenICC list agree is that the photoshop/proprietary OS approach to CM could be substantially improved in the area of printing. My GIMP proposal did not deal with color managed printing since my vision for how this should be handled would require significant changes to the gimp-print/guten-print plugin that I think are beyond the scope of 2.3/2.4 and are in fact significantly different from how this is handled in photoshop. The gimp-print/guten-print plug-in is developed by different people and is not at all coupled to the GIMP release cycles. We should however consider to make the print plug-in that's being shipped with GIMP aware of the image's color profile. That brings up another showstopper for 2.4 that is missing from the list I posted earlier. We need to check if the new print plug-in is ready for release. Since I don't use GTK+ 2.10 yet, I didn't get a chance to have a look at it yet. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 showstoppers
On 11/15/06, Sven Neumann wrote: That brings up another showstopper for 2.4 that is missing from the list I posted earlier. We need to check if the new print plug-in is ready for release. Since I don't use GTK+ 2.10 yet, I didn't get a chance to have a look at it yet. What requirements should be met by this plug-in to consider it ready for release? Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 showstoppers
Hi, On Wed, 2006-11-15 at 23:07 +0300, Alexandre Prokoudine wrote: That brings up another showstopper for 2.4 that is missing from the list I posted earlier. We need to check if the new print plug-in is ready for release. Since I don't use GTK+ 2.10 yet, I didn't get a chance to have a look at it yet. What requirements should be met by this plug-in to consider it ready for release? It should at least do the basic things right. In other words, print a single image, allowing the user to specify the size and location on paper. Should probably default to the original size (determined by the image resolution) if that fits to the printable area. Otherwise it should scale the image down while preserving the aspect ratio. For this plug-in I think we should focus on keeping it simple. Enough to fulfill basic printing needs but still usable without reading a manual. People who need more control can always install the gutenprint plug-in. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 showstoppers
On Wednesday 15 November 2006 11:38, Sven Neumann wrote: snip With the exception of printer CM support there is not that much work that needs to be done to GIMP to finish off the CM implementation. Printing is left to plug-ins, so we don't need to deal with it except for providing ways for the plug-in to access the color management settings and the color profile that is attached to the image. Both is implemented already. I think that the minimal solution is to make sure that users can convert images between color profiles. If you are using something like my proposal then this feature will be available. So you could even get by without providing plugin access to the GIMP CM settings and still have a usable CM system for the short term. This amount of CM support is a little on the basic side but the printing work flow would look like this: 1. Prepare image in the images native color space (ie. either the device color space or the users normal working color space) with whatever things you do such sharpening and whatever. 2. Use the color space conversion utilities to convert the image from the images native color space to the printer color space. 3. Send the image to the printer. 4. Undo the color space conversion. The above can be used with printer drivers and plugins that know nothing about CM. But it does result in more work for the user than a more integrated approach. Providing ways for print plugins to access the various CM settings and image profiles will be needed in the long run so that CM features can be implemented in any print plugins in a way that is transparent to users and fully integrated with GIMP. Therefore I agree with your direction. I should add that the above printing work flow is not that much different from what happens in photoshop except some of the steps are hidden from the user by photoshop. Hal ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 showstoppers
From: Sven Neumann [EMAIL PROTECTED] Date: Wed, 15 Nov 2006 20:38:07 +0100 On Wed, 2006-11-15 at 11:02 -0800, Hal V. Engel wrote: One area were many on the OpenICC list agree is that the photoshop/proprietary OS approach to CM could be substantially improved in the area of printing. My GIMP proposal did not deal with color managed printing since my vision for how this should be handled would require significant changes to the gimp-print/guten-print plugin that I think are beyond the scope of 2.3/2.4 and are in fact significantly different from how this is handled in photoshop. The gimp-print/guten-print plug-in is developed by different people and is not at all coupled to the GIMP release cycles. We should however consider to make the print plug-in that's being shipped with GIMP aware of the image's color profile. I'd like to see the code that does this, so that the Gutenprint plugin can if possible do the same thing. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 showstoppers
Hi, On Wed, 2006-11-15 at 19:22 -0500, Robert L Krawitz wrote: The gimp-print/guten-print plug-in is developed by different people and is not at all coupled to the GIMP release cycles. We should however consider to make the print plug-in that's being shipped with GIMP aware of the image's color profile. I'd like to see the code that does this, so that the Gutenprint plugin can if possible do the same thing. Nothing fancy, just ask for the icc-profile parasite that is attached to the image. If no parasite is attached, you can assume sRGB. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
