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] New option Use custom quality settings for JPEG files
On Mon, 13 Aug 2007 13:36:05 +0200, Raphaël Quinet [EMAIL PROTECTED] wrote: On Mon, 13 Aug 2007 07:10:30 -0400, Robert L Krawitz [EMAIL PROTECTED] wrote: Would Use existing image quality settings be a better name for this? I considered naming this option Use original quality settings, but one thing that I forgot to mention in my previous messages is that it is possible to write a script or plug-in that attaches different quantization tables to any image. [...] Although I was a bit reluctant to do this, we could try to change the name of this option to Use original quality settings or Use quality settings from original image or something like that. This would require several changes in behavior explained below. This new meaning may not be appropriate if other quantization tables than the original ones are attached to the image, but if we consider that usage to be an exception, then maybe we can optimize for the common case if this could make the option more understandable. Anyway, if we want to change that string, then we have to reach a consensus on that in the next few hours and make sure that it will not change again until GIMP 2.4 is out. We should be in string freeze now. If we change the label, this also changes the meaning of the option and this will require some changes to the code: - Currently, Use custom quality settings is only available when the quantization tables are non-standard ones. If the tables can be generated by the IJG JPEG library, then the option is grayed out because the user can get the same table with the existing quality slider (and that slider is already set to the right value if the quality of the original file is better than the user's default). If that option is changed to mean I want the same settings as the original image instead of I want to use some non-standard tables, then that option should always be available even if the original image used standard quantization tables. - Enabling that option should not only change the quality slider, but it should also change the choice of subsampling parameters, even if the chroma subsampling in the original image is not as good as the user's defaults (i.e., if the default is 1x1 and the original image used the lower quality 2x2 or 2x1). This would ensure that all significant parameters from the original image are re-used when saving. Note that it would be a one-way change: enabling the option Use original quality settings would change the subsampling parameters, but changing the subsampling parameters later would not disable the option (unlike what is done when the quality slider is moved). - Optionally, the usage (or not) of optimized Huffman tables could be detected in the original image and re-used when saving. I think that it would be better to leave it always enabled (always optimize) but if we want to be as close as possible to the original image, then we could disable the optimization if the original image was not optimized. Implementing these changes would be easy (except for the last one, maybe) and I know exactly what would have to be be changed so the code itself is not an issue here. But we should quickly decide what this option should mean. I like the current meaning (custom tables) but some of you think that it would be easier to understand something referring to the original quality settings. If we can reach a quick agreement on what is better (considering the differences explained above) and if it is not too late for 2.4rc1, then maybe I could change that option. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hue-Saturation tool with gradients
Hi Marius! I think there are people interested in this enhancement, but it depends on how it is prepared and presented. Currently all dev. stuff is working hardly on 2.4 release so they are a bit busy. ;-) It's usual to write a C patch and try to get it accepted by the dev. here. Ok currently I' cant provide a C patch but I'm interested in GIMP dev. - what to do? First I think we have to discuss UI questions with the UI guys at http://gui.gimp.org (hmm - how best to do this?) Second we have to completely work out the thing to motivate a dev. to implement the changes. I would like to further discuss your enhancement - please contact me via private mail so that we can start to work on this... [EMAIL PROTECTED] -- Some comments to your enhancement post: 01. Yes good idea (but never speak out the evil word pho***o* - dev. are a bit sensitive to it ;-) 02. We definitely have to extend the color editing tools because motion picture compositing software has far more powerful tools for color editing available. 03. a first quick and dirty proof from my side for everyone interested: http://www.dolchonline.net/prj/GIMP/chart_mokup_HSL_adjustment.png http://www.dolchonline.net/prj/GIMP/hsl-adjustment-dialog-mockup-small.png Best Regards Danko Marius B wrote: Hi, It seems that nobody is interested in this enhancement, but IMO it`s a nice feature that is worth discussing. I would like to hear your opinion about my mockup of this dialog http://bugzilla.gnome.org/attachment.cgi?id=92732 in bugreport http://bugzilla.gnome.org/show_bug.cgi?id=461658 I know it`s not perfect, but it`s obvious for me, that the current one needs some redesign. Yesterday I filled a bugreport 461658 about this, but I was advised, better to discus this matter here. There I have attached the patch and a mockup. Currently, hue-saturation tool dialog has master button surrounded with 6 color boxes, whitch changes its color while regulating hue/lightness/saturation values. Unfortunately it makes this dialog unnesasary big and akward to use. So my enhancement proposal would be to make this dialog look more like photoshop`s, but of course, not identical. In my opinion, those two hsl gradients can show quite alot information, even without looking at the modified picture itself. Most important, you can see seamless color transitions, and compare to the original gradient. As a start, I just added those two gradients, without radicaly changing this meniu. I should mention, that I encountered a problem with current svn version, that gimp_gradient_get_color_at function now requires gimpcontext, thou it is absolutely unnecessary in this case, so I dont know how to get it, and for now, I just made it optional in there. Looking forward to healthy discussion Marius ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New option Use custom quality settings for JPEG files
Date: Wed, 15 Aug 2007 10:25:54 +0200 From: =?UTF-8?B?UmFwaGHDq2w=?= Quinet [EMAIL PROTECTED] On Mon, 13 Aug 2007 13:36:05 +0200, Raphaël Quinet [EMAIL PROTECTED] wrote: On Mon, 13 Aug 2007 07:10:30 -0400, Robert L Krawitz [EMAIL PROTECTED] wrote: Would Use existing image quality settings be a better name for this? I considered naming this option Use original quality settings, but one thing that I forgot to mention in my previous messages is that it is possible to write a script or plug-in that attaches different quantization tables to any image. [...] Although I was a bit reluctant to do this, we could try to change the name of this option to Use original quality settings or Use quality settings from original image or something like that. This would require several changes in behavior explained below. This new meaning may not be appropriate if other quantization tables than the original ones are attached to the image, but if we consider that usage to be an exception, then maybe we can optimize for the common case if this could make the option more understandable. Anyway, if we want to change that string, then we have to reach a consensus on that in the next few hours and make sure that it will not change again until GIMP 2.4 is out. We should be in string freeze now. ... Implementing these changes would be easy (except for the last one, maybe) and I know exactly what would have to be be changed so the code itself is not an issue here. But we should quickly decide what this option should mean. I like the current meaning (custom tables) but some of you think that it would be easier to understand something referring to the original quality settings. If we can reach a quick agreement on what is better (considering the differences explained above) and if it is not too late for 2.4rc1, then maybe I could change that option. The problem is that custom tables seems very confusing -- it sounds like the user's going to be asked to input something she knows nothing about. One could argue that Use existing image quality settings means the same thing as Use quality settings currently attached to the image, and then nothing about the behavior would have to change. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] mentioning Photoshop on this list
On Wed, 15 Aug 2007 12:04:08 +0200, Danko Dolch [EMAIL PROTECTED] wrote: 01. Yes good idea (but never speak out the evil word pho***o* - dev. are a bit sensitive to it ;-) Just a little thing that I would like to clarify: mentioning Photoshop or other products on this list is perfectly OK. If anybody on this list feels offended of feels compelled to react strongly when someone mentions Photoshop, Paint Shop Pro, Windows, Adobe, Microsoft or some other proprietary products or companies, then they do not belong here. Feel free to have constructive discussions and to compare GIMP with other products here. Other programs also have great features, so describing these features and their pros and cons can be a nice way to make GIMP even better. However, there are some things that you should avoid: - Assuming that everybody knows what you mean when you talk about some specific feature of another program. I do not have a copy of Photoshop (*) and most GIMP developers do not have one either. I have not seen nor used any recent version of Photoshop. So if you mention some specific feature of another program, please be sure to describe it precisely instead of just saying that we should implement this or that like in Photoshop. - Assuming that we want to have the same features as another program. With the help of Peter, we have developed a vision for GIMP: http://developer.gimp.org/gimpcon/2006/index.html#vision Features that do not fit in the GIMP vision will probably not be implemented. Among other things, GIMP does not try to copy Photoshop or MS Paint. - Assuming that we will implement some useful feature in the same way as another program. There is often more than one way to implement something. Each solution has advantages and disadvantages. We should always try to implement the solution that fits best together with other GIMP features. So when you describe a feature, try to describe its purpose (what does it do? why is it useful? to whom?) before describing how it works. Most of the comments on the list that were complaining about a message mentioning Photoshop were due to one of the reasons given above. The complaints that were not due to one of these reasons can probably be ignored. So feel free to mention other products or programs here, as long as you provide useful information. By the way, there is no need to censor or change the name of a product or company when you mention it (Ph*t*sh*p, Windoze, ...) We can speak like grown-ups. Or try to. ;-) So these were just my 2 cents to avoid spreading misconceptions about what is OK and what is not OK on this list... -Raphaël (*) I might still have a CD with Photoshop 4.0 LE for Windows 95 that that came with my scanner. But my old Win95 PC has not been booted since a very long time. And a 10 years old copy of Photoshop is probably irrelevant for most comparisons. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] mentioning Photoshop on this list - ok just kidding... ; -)
Hi Raphaël! I wasn't really serious as I wrote about the evil pho ;-)) My intention was just to point that a lot of dev. don't like to hear photoshop can this and it does that - why is there still any difference between PS and GIMP but stop - let's concentrate on important things like 2.4... Best Regards Danko Raphaël Quinet wrote: On Wed, 15 Aug 2007 12:04:08 +0200, Danko Dolch [EMAIL PROTECTED] wrote: 01. Yes good idea (but never speak out the evil word pho***o* - dev. are a bit sensitive to it ;-) Just a little thing that I would like to clarify: mentioning Photoshop or other products on this list is perfectly OK. If anybody on this list feels offended of feels compelled to react strongly when someone mentions Photoshop, Paint Shop Pro, Windows, Adobe, Microsoft or some other proprietary products or companies, then they do not belong here. Feel free to have constructive discussions and to compare GIMP with other products here. Other programs also have great features, so describing these features and their pros and cons can be a nice way to make GIMP even better. However, there are some things that you should avoid: - Assuming that everybody knows what you mean when you talk about some specific feature of another program. I do not have a copy of Photoshop (*) and most GIMP developers do not have one either. I have not seen nor used any recent version of Photoshop. So if you mention some specific feature of another program, please be sure to describe it precisely instead of just saying that we should implement this or that like in Photoshop. - Assuming that we want to have the same features as another program. With the help of Peter, we have developed a vision for GIMP: http://developer.gimp.org/gimpcon/2006/index.html#vision Features that do not fit in the GIMP vision will probably not be implemented. Among other things, GIMP does not try to copy Photoshop or MS Paint. - Assuming that we will implement some useful feature in the same way as another program. There is often more than one way to implement something. Each solution has advantages and disadvantages. We should always try to implement the solution that fits best together with other GIMP features. So when you describe a feature, try to describe its purpose (what does it do? why is it useful? to whom?) before describing how it works. Most of the comments on the list that were complaining about a message mentioning Photoshop were due to one of the reasons given above. The complaints that were not due to one of these reasons can probably be ignored. So feel free to mention other products or programs here, as long as you provide useful information. By the way, there is no need to censor or change the name of a product or company when you mention it (Ph*t*sh*p, Windoze, ...) We can speak like grown-ups. Or try to. ;-) So these were just my 2 cents to avoid spreading misconceptions about what is OK and what is not OK on this list... -Raphaël (*) I might still have a CD with Photoshop 4.0 LE for Windows 95 that that came with my scanner. But my old Win95 PC has not been booted since a very long time. And a 10 years old copy of Photoshop is probably irrelevant for most comparisons. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New option Use custom quality settings for JPEG files
Quoting Robert L Krawitz [EMAIL PROTECTED]: The problem is that custom tables seems very confusing -- it sounds like the user's going to be asked to input something she knows nothing about. One could argue that Use existing image quality settings means the same thing as Use quality settings currently attached to the image, and then nothing about the behavior would have to change. My only comment on this issue is that the term image is consistently employed within the GIMP vocabulary to mean the in-memory copy of the picture being edited (when an image is duplicated, scaled, changed mode, etc., the file is not affected). It would be confusing to use the term image to describe a file attribute that is basically independent of the in-memory data. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Hue-Saturation tool with gradients
Marius B wrote: Hi, It seems that nobody is interested in this enhancement, but IMO it`s a nice feature that is worth discussing. I would like to hear your opinion about my mockup of this dialog http://bugzilla.gnome.org/attachment.cgi?id=92732 in bugreport http://bugzilla.gnome.org/show_bug.cgi?id=461658 I know it`s not perfect, but it`s obvious for me, that the current one needs some redesign. Please correct me if I'm wrong, but that mockup basically aims to change the aspect of the dialog without adding any enhancement. The tool does exactly the same but the dialog looks like Photoshop's one. The only improvement I see is the ability to see the actual influence of the overlap value on the color gradient, wich is cool, but I don't know if it's cool enough to change the whole dialog, that already works fine. Maybe it would be better for future versions to redesign the dialog adding some real enhancements to the tool, like arbitrary 3-point gradient selection and/or a curve for tweaking. In that case, the use of a wheel is better than a linear scale because it matches better with the well known color wheel scheme. Gez. p.s.: I support the idea that Campbell Barton suggested a couple of days ago. Maybe it would be better to create a new mailing list focused on functionality discussion. This would avoid the frequent conflict user requests vs. developers priorities and would bring some fresh ideas for the project. I don't want to bug any developer with functionality requests if this list is only focused on coding, but I'd really like to have a place for discussing features and useability issues that are also very important for the overall quality of Gimp. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hue-Saturation tool with gradients
Hi, On Wed, 2007-08-15 at 14:41 -0300, Guillermo Espertino wrote: Please correct me if I'm wrong, but that mockup basically aims to change the aspect of the dialog without adding any enhancement. The tool does exactly the same but the dialog looks like Photoshop's one. The only improvement I see is the ability to see the actual influence of the overlap value on the color gradient, wich is cool, but I don't know if it's cool enough to change the whole dialog, that already works fine. Maybe it would be better for future versions to redesign the dialog adding some real enhancements to the tool, like arbitrary 3-point gradient selection and/or a curve for tweaking. In that case, the use of a wheel is better than a linear scale because it matches better with the well known color wheel scheme. I agree with this. We should take our time to look at this tool and how it could be improved to become really useful. A first start would be to write down some usage scenarios where this tool could be useful. Then perhaps evalulate how well the current implementation and the PS tool deal with it. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hue-Saturation tool with gradients
Hi Sven! Sven Neumann wrote: Hi, On Wed, 2007-08-15 at 14:41 -0300, Guillermo Espertino wrote: Please correct me if I'm wrong, but that mockup basically aims to change the aspect of the dialog without adding any enhancement. The tool does exactly the same but the dialog looks like Photoshop's one. The only improvement I see is the ability to see the actual influence of the overlap value on the color gradient, wich is cool, but I don't know if it's cool enough to change the whole dialog, that already works fine. Maybe it would be better for future versions to redesign the dialog adding some real enhancements to the tool, like arbitrary 3-point gradient selection and/or a curve for tweaking. In that case, the use of a wheel is better than a linear scale because it matches better with the well known color wheel scheme. I agree with this. We should take our time to look at this tool and how it could be improved to become really useful. A first start would be to write down some usage scenarios where this tool could be useful. Ok - I would like to do so - I've tryed to create a user account at the GUI wiki but it seems that not all functions are working? I could not create an account. How could I start to help? Then perhaps evalulate how well the current implementation and the PS tool deal with it. Could get a PS user to support me with this - I could point how Corel Photopaint and Autodesk Combustion are working... -- Maybe it's not only useful to think about the HSL adjustment dialog - there are for sure a lot of other things to look at? -- It would be so helpful to get an prototyping env. for UI test's for example via scripting. I know there are a lot of limitations but what do You think is the best way not only to draw images? I support some coders in the company where I'm working with HTML/Java-Script/Ruby and we create really complex interface elements for WEB 2.0 apps. I would like to get some tips, how I as graphics designer with a scripting background could prototype and test some interface elements... Best Regards Danko Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hue-Saturation tool with gradients
Hi Guillermo! Guillermo Espertino wrote: Marius B wrote: Hi, It seems that nobody is interested in this enhancement, but IMO it`s a nice feature that is worth discussing. I would like to hear your opinion about my mockup of this dialog http://bugzilla.gnome.org/attachment.cgi?id=92732 in bugreport http://bugzilla.gnome.org/show_bug.cgi?id=461658 I know it`s not perfect, but it`s obvious for me, that the current one needs some redesign. Please correct me if I'm wrong, but that mockup basically aims to change the aspect of the dialog without adding any enhancement. The tool does exactly the same but the dialog looks like Photoshop's one. Does it? I havn't used PS since a long long time... if it looks like PS then I have to have a look at PS but I don't expect to find there highend visualisation functions like in motion picture color grading tools nor the cool discreet like preset banks... ;-) Yes exactly the same except for: - the more visual primary color selection with enhanced visualisation - powerful storage banks for test setups - a drop down preset lib - loading and saveing of settings - added compare tool - sliders with scale marks and middel point mark finally you can say it's exactly the same ;-) The only improvement I see is the ability to see the actual influence of the overlap value on the color gradient, wich is cool, but I don't know if it's cool enough to change the whole dialog, that already works fine. I only had an hour to made the mockup so I don't found the time to implement highlight/mid/shadow support or other needful extensions... you are right this had to be integrated for future mockups - and even I have to go step by step - next version will show a lot more maybe... ;-) Until today nobody has integrated this small cool things in a standard image editing application - not even that small things... (what sense made it to figure out complex things if even the simple ones are not realized? ;-) Maybe it would be better for future versions to redesign the dialog adding some real enhancements to the tool, like arbitrary 3-point gradient selection and/or a curve for tweaking. In that case, the use of a wheel is better than a linear scale because it matches better with the well known color wheel scheme. You are absolutely right - lets go and start with this - I really would enjoy to integrate all this things into a mockup and discuss pros and cons... Gez. p.s.: I support the idea that Campbell Barton suggested a couple of days ago. Maybe it would be better to create a new mailing list focused on functionality discussion. This would avoid the frequent conflict user requests vs. developers priorities and would bring some fresh ideas for the project. I don't want to bug any developer with functionality requests if this list is only focused on coding, but I'd really like to have a place for discussing features and useability issues that are also very important for the overall quality of Gimp. That would be really great! I'm a bit modest with posting here because of that... And where to find the people from the GUI wiki? Best Regards Danko ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
