Re: [Gimp-developer] Composition rendering time instance
that seems really powerful to me, and I hope to see some form of visual node representation beside the classic layer view some day... (yes the one in Blender is great ;-) Today a motion compositor is sometimes the better tool to do a complex non destructive still composit because of things like the node editor or external referenced image sources. Adobe After Effects for example is hardly criticized for its lack in true node editing. -- A question about the planned new Gimp layer chain: Will we have a chain of layers with different operators applied to them and the option of linking child layers to parent layers and building groups for esay tranformation? -- The input of such a layer is stored in native resolution and processed by the layers trasnformation settings to match the composition? Can the input be externaly referenced? Will there be a resampling option to be able to reduce file size if I loaded a 24MP image but only want do design a web banner and don't want to save all the 24MP input dat with my composition? greetings Danko yvind Kols wrote: On Wed, Jul 8, 2009 at 7:26 PM, Tobias Ellinghaush...@gmx.de wrote: Am Mittwoch, 8. Juli 2009 schrub Danko Dolch: I personally love the node editor of blender and would like to see something like that in GIMP. The only problem with these node setups (like the one in your screen shot) is that they are only graphs but no trees. And AFAIK GEGL uses trees of nodes. Thus the cool things like several sources or forward edges (think of a bumpmap on a layer which uses the same layer as source) are not possible. GEGLs XML serialization format is a tree, the data structure exposed in the API is a fully general directed acyclic graph. As long as you restrict the set of node types involved to: sources, sinks, filters and composers with two input pads and one output pad, any graph can be expressed as a tree with clones. In earlier incarnations (not in GEGL) of the same tree serialization I also allowed embedding free-form graphs as one of the nodes in the tree, thus more complex ops with multiple inputs and outputs could be inserted there. /yvind K. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] to render or not to render - Composition rendering time instance
age from an GEGL graph would be called "render" by some media industry folks. 3. If You create highend sophisticated GEGL graphs that take long long to render even on you brand new Intel Beckton 16 core workstation ;-) it would be handy to insert precalculated "proxy nodes" into the GEGL node graph to speed things up by caching the whole or a part of the graph. Alternatively an automatic caching of the inbetween calculations of all compositing nodes would be more comfortable but harder to implement into the first version and it would require much more disk space than a single proxy node. This disk cache could be stored into the main files as a parasite (some 3d rendering application's store global illumination photon maps inside of 3D scene files on request but it's good to have a choice if it's stored with the "workspce" file or externaly... best Regards to all GIMP devs out there - you do a great job!! Danko Dolch 3D artist compositor ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Composition rendering time instance
Hi Peter! yahvuu wrote: hi, Tobias Ellinghaus schrieb: Am Mittwoch, 8. Juli 2009 schrub yahvuu: [...] The user sends a JPEG to a colleague for review -- takes 2 hours to render. The image is OK, the user creates a TIFF for the print shop -- takes 2 hours again. I think in this case, the user would be better off if he had some control about when the rendering happens. What about caching the rendered image? As long as nothing is changed it can be reused. And when anything is altered in the image it has to be rerendered anyway. At least if it's not possible to cache intermediate results of the rendering or just rerender the changed parts. that gives a very nice solution! Some disk cache is needed by GEGL anyway, and if that cache is persistent across sessions, unnecessary recalculations can be mostly avoided. What about taking the cache with you? e.g. switch to another workstation - would be cool to have an option to store the cache external too... Personally, i wouldn't mind to assign some GBs to GIMP in order to make my life easier. Those who do mind, could set the 'persistent cache' size to zero in order to make shure GIMP cleans up when closing the session. That would be fine - question is: a) save only the final image b) save all the results of the GEGL graph nodes during a session so that not all nodes have to be calculated if only the last one is changed... c) create a dedicated "cache" or "proxy" node that can be assigned by the user In case someone really needs to save the rendered bitmap together with the composition, there's still the possibility to put that option into the finalize command. Or something like that. Use case? A) I have a comp. that takes 2h to render and I want to take the cache with me because I want do do some final color adjustments with my client. If I reopen the comp and change the color node settings the rendered bitmap beomes invalid and I need another 2h to recalculate all again... In this case I just hat to export a PNG or something like and start a new comp. to do the final color tweaks. But that would be bad for the workflow because now I have 2 comp. to work with... B) I've set a "GEGL "cache node" ontop of the GEGL nodes that took 2h to render and stored the "cache node" data into my Gimp comp. file. In my clients office I load the comp. into Gimp and add another GEGL color correction node ontop of the "cache node" - now I do some quick "realtime" adjustments to get the approval for the image from my client. 2h of rendering saved... A simple prerendered cache won't save the day i think... regards Danko Dolch 3D artist compositor ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Composition rendering time instance
Hi Peter! yahvuu wrote: hi, Danko Dolch schrieb: What about taking the cache with you? e.g. switch to another workstation - would be cool to have an option to store the cache external too... cool, yes. But even more "corner cased" than the case of very expensive compositions already is for GIMP. ok, corner cased sounds like a typical working scenario for me ;-) I've a screenshot for you - showing a layer tree and a node based view side by side. The node view is more pleasing to read if you try to understand whats going on. http://www.dolchonline.net/prj/gimp/combustion_scr01.jpg in short: I load a image of a bird - apply a blue screen key - correct the colors - and send it to the first layer. Second I load a background image - blur it - draw a mask on it - and send it too to layer. Third I load a image and place it on a layer behind the masked hole in the background of the second layer. then I composite the 3 layers - sharpen the result - and scale it with a layer to 720p highdefinition video res. - I send it to he final composite. To save me render time I added an "proxy operator" that caches the whole compositing and virtually switches the image input to the disk cache. That proxy gets color corrected in realtime without any hassle and saved to different output settings at once - cool feature to created all needed res. and file formats without needing a custom script to doing that ;-) Also I saved the keyed bird with the "key-out" render output without manually repeating this every time I adjust the key parameters. A node view is your friend and sould not be hidden from the user - just entry level users have a better understnding from a "physical pipeline based view" than a complex layer tree... But Rome wasn't build in a day either - I know - first things first ;-) Not to mention the wonderful way of correcting colors with the color warper system and high quality histogram + vector scope something I miss in still image editors... yahvuu wrote: Personally, i wouldn't mind to assign some GBs to GIMP in order to make my life easier. Those who do mind, could set the 'persistent cache' size to zero in order to make shure GIMP cleans up when closing the session. That would be fine - question is: a) save only the final image b) save all the results of the GEGL graph nodes during a session so that not all nodes have to be calculated if only the last one is changed... c) create a dedicated "cache" or "proxy" node that can be assigned by the user a) only the tree gets saved. The final image aka full resolution bitmap gets only created when exporting (e.g. to JPEG). This bitmap is then available from the disk cache in case subsequent actions need it. In the example, that was exporting again to a different file format. b) yep, that's what the disk cache should do (for expensive calculations) and ideally this data should persist across editing sessions. this would be the best solution - but memory requirements have to be considered carefully - think about someone editing a simple satelite image (eg. blue marble second generation) 86400x43200px - it takes about 14GB per 32bit RGBA layer - if you store 10 operator states you will have a lot of GB for only one still image ;-) hmm... 1. small projects don't need caching becuse they can be rendered in realtime 2. larger projects need a powerful caching on operator/node base to speedup things 3. extra large projects need some cache management to prevent one composition to kill all the cache of the other projects only by opening once ;-) c) This is a very interesting idea. Allow me to translate for GIMP, a better name would probably be something like a "render full resolution" operation. - "render", because GEGL cares for all necessary caching automatically during editing (please correct me if i'm wrong). So for GIMP, the real purpose is to save some intermediate results together with the composition, that is to render them. (During editing the full resoluton will almost never get rendered when the screen is smaller than the image size) - "operation", because GIMP will not expose the GEGL tree on the UI, but instead will have linear operation chains. in this case you could have a small "cache" checkbox for all operators of the layer chain... So indeed, that's a cool way to give the user fine-grained control about how much (redundant) rendered data should be saved with the composition. That's clearly an expert feature, so it won't hurt much if it has to be controlled by some 'scary' operation. ... i'm convinced now. fine... than we can try to convince some devs ;-) greetings, peter greetings, Danko ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] change layout of mode menus?
Hi! Thanks for discussing the layer mode menu. 1. As shown in Bills screen shot the widget rendering is a bit strange even if there is enough space on screen. 2. The separators are not bad thing. 3. If you know exactly what to do you simply click the mode and ready - but you should be able to select the mode with a single click from the list. 4. If you want to experiment with the layer modes you want to cycle them as long as you have found one to choose. Currently it's not possible to cycle through the list and look for the result. If you choose one mode you leave the menu :-( Thank you all for making Gimp step by step a usable workhorse ;-) Danko - After installing Gimp 2.4.4 win32 - I switched to fullscreen mode only to see if it fails on my dual screen machine - but now it works and goes fullscreen on the current display and not on the primary laptop display reserved for file windows and error messages - Wow!!! Thank You!!! ;-) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Preview Windows in Python-Fu - Do they exist?
Hi Jim! You can use Glade to create Python GUI's and as described it's also possible to create complete new Glade widgets in Python... Custom PyGTK Widgets in Glade3 http://unpythonic.blogspot.com/2007/03/custom-pygtk-widgets-in-glade3.html I havn't done this by myself but want to try it as soon as possible - please keep me up to date if it works for you or if there are more questions... - [EMAIL PROTECTED] best Regards Danko Jim Sabatke wrote: David Gowers wrote: Hi Jim, On Dec 8, 2007 10:22 AM, Jim Sabatke [EMAIL PROTECTED] wrote: I've been searching the net for a couple days to see if Python-Fu supports Preview Windows in plug-ins. Depending on the search strings I No, it doesn't. PyGimp does, though. This means that if you want a preview window, you need to construct the GUI yourself -- you cannot rely on PythonFu to construct it automatically for you. In the 'gimpui' module, look up the help -- see 'GimpPreview','GimpAspectPreview', and associates. Thank you David. Next question ... is there any GUI generator, like Glade that does a decent job of building interfaces like that? TIA, Jim ___ 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
[Gimp-developer] Python-Fu print messages on win32?
Hi! I have a problem printing status messages from Python-Fu scrips on win32. On Linux systems the print messages will show on the shell window but on Windows only plugin init error messages show with -c option. Is there a way to use the gimp build in python console to show print messages from scripts that are started from the menu? Or do I have to construct an new message window and redirect stdout? best regards Danko ___ 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: Danko Dolch escribió: 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... ;-) I attach a side by side comparision between your mockup and the Photoshop CS2 Hue/Saturation dialog. Ah jep - have to clarify that this first mockup was created by mario - see the first post from him ;-) 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 ;-) I wasn't talking about the PS Hue/Saturation tool. What I was trying to say is that this mockup looks like the PS dialog but with the same features of the current tool in Gimp. *http://bugzilla.gnome.org/attachment.cgi?id=92732* I don't see any of those features in that mockup. If you're referring to a different one, please let me know and point me the correct URL. PS Hue saturation tool? Mario had created the first mockup: http://bugzilla.gnome.org/attachment.cgi?id=92732 As response I thougt about how I would like use this tool and cerated this as an answer to marios first work: http://www.dolchonline.net/prj/GIMP/hsl-adjustment-dialog-mockup-small.png to explain my thought's I put it together to this overview: http://www.dolchonline.net/prj/GIMP/chart_mokup_HSL_adjustment.png 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... ;-) I'm looking forward to see that. I'm very interested! :) That's great! Let's create some interesting new UI conceptions! We should follow Seven's suggestions and crete more usage scenarios first... 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? ;-) If I learned something in the Gimp's developers list is that you have to convince developers of the value of your proposals. Most of the times it's a titanic task, but when you make it the results are great. Most of the times, also, they don't pay attention to small changes, but when a nice challenge pops up, they seem to be more interested. A couple of weeks ago I pointed an issue in the jpeg exporter. The first time I was treated like... ehm... an idiot. But after the big discussion, there are some news in that field and the exporter was greatly improved. As I told you, it was hard, but it worths. It's a hard thing to improve things ;-) But we have to do it... And yes - we have to create some real challenges for the coders ;-) 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... Ok! I love the idea. Let's start to analize the possibilities and brainstorm a couple of mockups so we can send them a complete use scenario and a nice mockup to see if they like the idea of implementing it. I'm working on a rough mockup with an idea with the wheel and something else. I'll send you a sample when it is more advanced. Keep in touch! ok - we will do! :-) Gez. P.s.: Sorry I called you Marius B in the list. I had misread the e-mail heading. no problem - hey mario let's start to work - we have a lot of things to do - and finaly figure out how we could support the GUI group... Best Regards Danko ___ 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! Hi Danko: Here is a very very early mockup. I have the idea but had no time to translate it to a better mockup. I know - t's the same for me too... ;-) I have to re-arrange some buttons, add others, and think lots of things (for example, I'm not sure if the current widgets allow a wheel selector like that) I suspect they don't but I see our current task not so much in creating designs for the current widget set but in showing how a modern and powerful dialog should look for future releases. Unfortunately I'm currently not enough involved in the practical interface work. So first I will concentrate on designing next gen. controls and discuss them. This will result in new ideas and can be helpful to further dev. the GIMP UI. -- But now some feedback to your mockup: I really like the color weel with the second ring - so you can visualize the different In/Out color parameters in one way - to use it we need radial sliders - great! I see the color picker - nice! And the Curve Tool for the color overlapping - yes... - The curve would be opened in a second window right? I have a problem with all this cluttered windows. I like a single dialog with all available parameters - but this will quickly get komplex. pro: no cluttered messing with different windows and clicking through assistants con: needs lot of display space and makes the dialog too complex for most users (even pros ;-) solution: INTERPLAY[in the beginning the UI design was static - and people needed more flexible configuration options - then programs got thousands of floating cluttered windows and people had to arrange them all the time instead of working with the app. - now we got this nice type of free configurable non overlapping UI - like in Blender or combustion or a lot of other great programms - this is flexible but powerful and in a long term we should think about the pros and cons of this...) We make the additional areas like adjustment curve dynamically extending the main dialog (open or close with a small arrow button) Anyways I'd like to discuss with you some ideas off-list to reach a more compelling design. Question: 1. Is http://gui.gimp.org still active developed? 2. How we get in touch with Peter, Kamila and Ellen to see on what they are currently working. 3. We urgently need a Forum and a Wiki where we can meet the other people working on the GIMP UI greetings Danko Regards, Gez. ___ 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 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] 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] 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
Re: [Gimp-developer] Gimp Ruby - there is huge interest!!
Hi Scott! Unfortunately I never found some Gimp Ruby news on a Ruby related site - and I've searched a lot. I'm a bit uncomfortable with Scheme - wrote some simple scripts but if it comes more complex I struggle with the Scheme syntax and get knots in my brain - outch ;-) Had a look to Python but never got it running with a Gimp 2.3 win version. (After what I read on the net I was a bit discouraged if I as graphics artist and linux newbie could mange to get it running on my windows notebook - without some advice) Same with Gimp Ruby - found the source code - but nobody working on it or using it... :-( I use the Gimp 2.3 dev. version on windows and have a linux version running in a virtual machine. I'm highly interested in testing the Gimp Ruby dev. version and would help you as much as I can with testing, documentation, sample script's and so on... Please help me to get the wonderful Ruby language running with Gimp - Please! hope I can motivate you a bit to contiune working on Gimp Ruby ;-) best regards Danko ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
