Re: [Gimp-developer] New Image/Color Management option
El dom, 05-06-2016 a las 09:26 +0200, Øyvind Kolås escribió: > > > Practical, applied color management is not that complicated. > > Neither is > > understanding the basics of radiometrically correct editing. > > Most people - including people doing photography and graphic design > work for a living - prefer not to. I used to teach people becoming > such professionals at a university level. It should also be possible > to use GIMP for color scientists and color science geeks that care > more about color accuracy control than image composition. That should come endorsed by a professional photographer or designer saying she doesn't care about color management. We can assume that the silence is because nobody cares. But there is also a fat chance that there aren't many of those professionals around here. It's also possible that many future professionals at university level truly don't care, because they weren't taught about the importance and influence of color management in their work. I know that was the case with me. The quality of my work improved substantially after I understood the basics of color management. "just works" for most of the people means "I don't have to care about that" and that's a huge mistake. I do graphic design work for a living, and for ideological reasons I chose to do it with free software. I do care about proper color management because I know how doing it wrong degrades and limits the quality of my work. > > I know exactly when I want to use linear RGB and exactly when I > > want to use > > perceptually uniform RGB, as do other high end/professional users. > > Maybe not, professional photographers might not know that they want > pre-multiplied alpha, linear light data for doing resampling, nor > what > goes wrong if the pixel data for some reason isn't pre-multiplied or > linearized, providing constraints that makes such misconfiguration > hard is a service to novice and professional user alike. snip > There is also flipping to/from formats with alpha. Pre-multiplied and > non-premultiplied alpha. As well as flips to/from higher and lower > bit-depths as well as to/from CIE Lab. By necessity of the operations > involved, working on linear data is another one of these constraints > that should be fulfilled. Whenever possible the developer/designer of > image processing algorithms should be burdened with reducing the > number of parameters, as well as sticking with good defaults - making > efficient work-flows possible. If you continue calling it "babl > flips" > I will start calling your non-flipping-babl a lobotomized babl - you > could also collapse "RaGaBaA float" into "RGBA float" along with > "R'G'B'A float" to make babl even less capable of providing internal > color / pixel-representation management for GEGL and thus GIMP and > other applications using GEGL. Before scaling or blurring an image a > user would then have to run a pre-multiply filter and after-wards > un-premultiply filter. The fully automatic choice of alpha association is not always the best way to go. Sure, there are many documented cases where you know exactly what's the most adequate association, but then there are also cases (which are not corner cases at all) that completely fall apart with an automatic selection. For instance, take an EXR file with luminescent transparent pixels. That's a perfectly valid case that is used extensively in VFX to composite fire, light effects and any kind of emissive phenomena that produce light but don't occlude light from the background. It's important to note that what I mention is not a hack used by artists at all. It's a valid alpha compositing situation described both in the original porter-duff paper and the EXR specs. If you feed that data to a program that decides a strategy of alpha association, the most probable outcome is that the information in pixels with zero alpha is discarded. There is an infamous thread at Adobe Forums that had the most renowned imagers ranting about how Photoshop was screwing image data because programmers decided for users and made assumptions. That's why it's important to know what artists will do with your software before making such assumptions. I'm not saying that every single option in a graphics program should come with a toggle, but you can't choose for users if you don't know what they need. G. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] New Image/Color Management option
El sáb, 04-06-2016 a las 18:26 +0300, Alexandre Prokoudine escribió: > > Personally, I'm fine with a rant that has helpful bits of information > in it that could be extracted. All I can extract from your rant is > that you are annoyed so much that you post knowingly false > information. What "knowingly flase information"? > How does it help us make GIMP better? Hopefully making people involved take one step back and re-evaluate how they are addressing the target audience's needs. > > Why is it the goal of GIMP 2.10 to produce a GEGL-based version > > with > > feature parity with the current stable? > > Where did you even read this? Oh, come on! You say you never heard that? That the linear mode was a side effect from switching to GEGL, that some features like that weren't supposed to be in 2.10 as the minimum goal was producing a GEGL version of the 2.8 features, and anything else would be a plus? Iirc it was in the context of the first discussion about color management (supporting other colorspaces than just sRGB). And iirc it sounded as a pretext for kicking it to the future roadmap. I don't have a link to a ml thread or an IRC log, so you'll have to take my word. G. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] New Image/Color Management option
El vie, 20-05-2016 a las 14:37 -0400, Jason van Gumster escribió: > Elle Stone <ellest...@ninedegreesbelow.com> wrote: > > > I can't think of a single use case for trying to edit a non-color- > > manged > > image in an ICC profile color-managed editing application such as > > GIMP. > > I think I can think of one: creating displacement/bump maps (often > used as > textures in 3D graphics). Often in that case, pixel values aren't > treated as > color, but a numeric non-color data (i.e. it's an instruction to > displace > geometry---or other pixels---by this numeric mapping value). > > But perhaps the artists that create these maps are not covered in the > audience > specified in GIMP's vision statement. > > -Jason If pixel values aren't supposed to be treated as color, then they shouldn't go through any color operation. I mean, no operation should turn your RGB data to XYZ, LCH or whatever. In GIMP, GEGL operations decide when that happens, so your pixels are likely to be treated like color anyway and the no-color management option in this case wouldn't make any difference. As Alex mentioned, the artists who create those maps are not necessarily excluded from the target audience, but GIMP doesn't provide the tools for editing such maps, and it will always treat them as sRGB (which means that CM on or off won't make any difference). Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] New Image/Color Management option
El sáb, 04-06-2016 a las 14:22 +0300, Alexandre Prokoudine escribió: > On Sat, Jun 4, 2016 at 5:25 AM, Gez wrote: > > > I'm one of the few guys around using GIMP professionally in the > > field > > of graphic design, and with each decision like this one, pointing > > to > > the wrong audience (not the audience defined in the "product > > vision") > > I'm becoming less and less convinced that it is a good idea to keep > > using it. > > Would you like to talk about the issue in hand rather than go around > bashing developers without providing useful insights? Do you think that my e-mail didn't provide any useful insights? Read again. I think that, despite the apparent angry tone, it says a couple of things about taking care of your audience and making decisions for them, not for the wrong people. We can tal about that anytime. > People who work on themes and icons are not the same people who work > on e.g. color management. C'mon, Gez, you've been around for long > enough to know that. Sure, but that's not the point. I'm not charging against the guys who made the themes. I'm questioning that the development community seems to pay more attention to those secondary things rather than focusing on the real shit. G. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] New Image/Color Management option
El sáb, 04-06-2016 a las 11:04 +0200, Simon Budig escribió: > I don't understand your line of reasoning. Did you realize, that > Mitch > has literally spent months to make color management actually work in > Gimp - i.e. cut'n'paste between images with different color profiles > attached, color managed color selectors etc. pp. > > And now all this work is jeopardized, because he made a preferences > option to disable this stuff a little bit more visible? And we seem > to > have troubles in finding a correct way to describe what this toggle > button does? > > If this is your line of reasoning, then, sir, your priorities are > messed up. I couldn't care less about what the toogle does. It's secondary. The problem here is the motivation for including such toggle. No serious imager would think about turning CM off. Introducing that toggle is producing a feature that is not needed by the supposed audience of the tool. And it's not only that. What resulted from this discussion is even more concerning. Like this claim for instance: "And then we have this "even without a profile, pixels have some meaning. And in GIMP, the default meaning is sRGB." That's absolutely wrong. Without a colorspace definition, pixels ARE meaningless. RGB is just 3 colored lights. The value of an RGB pixel is only light intensity (from no intensity to max) and has no information whatsoever about the color of each primary. In GIMP the default meaning is sRGB because it was decided that RGB means sRGB. So when CM is off you're not treating those pixels as pixels, you're treating them as sRGB. Because of GEGL, GIMP expect them to be sRGB. So CM converts them to sRGB anyway, no CM treats them as sRGB anyway. That's what Elle has been fighting against for a long time, and that's still the problem. The CM or no-CM discussion only uncovers this issue once again. GIMP 2.9 is still a sRGB editor, assuming sRGB everywhere. Again, GIMP provides something that is enough for the wrong audience, but clearly inadequate and insufficient for the supposedly intended audience. G. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] New Image/Color Management option
El sáb, 04-06-2016 a las 10:07 +0200, Michael Schumacher escribió: > > On 06/04/2016 04:25 AM, Gez wrote: > > > The most pressing issues (like performance and quality) are > > constantly > > postponed. But hey, we have a new dark theme and new icons. > > We have these because there are people interested in them and > contributing to GIMP. > > I'm not going to tell them to stop doing this. You? Of course not, but take a quick look at the GIMP mailing lists archives and see how much attention got that minor subject and how much attention other important subjects receive. That speaks volumes about the priorities of the project. Why is it the goal of GIMP 2.10 to produce a GEGL-based version with feature parity with the current stable? Why is legacy support so important? where are the users saying that their work will suffer if you move from sRGB compositing to linear compositing? So no, I'm not going to tell anybody to stop doing what they are doing. I'm not the one who has to set your priorities, it's you. Is it your priority to produce a great image manipulation software? Then give imagers the tools they need. Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] New Image/Color Management option
El vie, 13-05-2016 a las 00:15 +0200, Simone Karin Lehmann escribió: > > > > The prefs option is for display color management, and will soon > > only be a default for a per-display switch. > > > > The option in Image -> New allows to disable color management > > and whatever color management transforms on a per-image base. > > > > Woooh, I can’t believe it! You’re saying that > > > This is mainly because almost nobody understands what this > > whole color stuff is about at all. > > Is this how you think about all the people who use GIMP? That almost > none of them understands color management? Although I share your shock, I think Michael is right. Almost nobody using GIMP understands color management, because there is virtually nobody using GIMP seriously, and probably nobody will because of this kind of design decisions. I'm one of the few guys around using GIMP professionally in the field of graphic design, and with each decision like this one, pointing to the wrong audience (not the audience defined in the "product vision") I'm becoming less and less convinced that it is a good idea to keep using it. The most pressing issues (like performance and quality) are constantly postponed. But hey, we have a new dark theme and new icons. This is ridiculous. And this is what is keeping serious users from being interested in the application. And if things keep going in this direction, GIMP will end up losing the handful of people actually using it seriously and caring about it. Instead of focusing on imagers devs seem to be focusing on eventual users who only use the tool once a month for scaling some photos and remove red eyes or making banners for online forums. If that's the audience you care about, please amend the product vision so people like me can move on, since there is no future for us with GIMP. Eventual users and clueless people can learn. It only takes education. Aiming low with features like this only makes us, the real audience, want to run in the opposite direction. Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] A better way to close a path where an end nodeis on top of a start node
El lun, 01-02-2016 a las 00:04 +0100, Ofnuts escribió: > On 31/01/16 09:08, Joseph Bupe wrote: > > Hi, > > > > Is there a reason why the path can close by just clicking the last > > node > > onto the first node? Why do we have to CTRL or Command + Click ? > > Because clicking on a node is selecting it, and this i something > you'll > want to do if you want to extend the path from the other end. In > other > words, you create a path with M, N, O, P, Q and then you want to add > points L, K, J, so after adding Q you'll click on M, and you don't > want > this to close the stroke. Double clicking on the first node could work too. But that in that case selecting the first node with a single click should revert the behavior, allowing to close the path double clicking the final node of the other end of the path. G. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Bug found: Unified transform and perspective tool fail silently when layer is hidden.
El mar, 08-12-2015 a las 17:28 +, C R escribió: > In 2.8 it was possible to hide the layer you are transforming (with > perspective tool) to get the original out of the way during > transform. > > Proposed solutions: > A. Make the original hide automatically, making it unnecessary to > hide > the layer during transform. > B. Make sure the transformation is applied, regardless of the hidden > state of the layer. I raised this subject in the UI mailing list a few days ago. In my opinion, A should be the solution. B, applying a transform on a hidden layer, could be problematic. It's not a good idea to touch layers that are hidden, so preventing any tool from working on hidden layers is probably a good thing and all tools should be consistent doing so. We need to discuss the usefulness of having the original layer during transforms. In my experience, most of the times it's a hurdle, blocking the context for the transform. But I'm aware that in some cases users would need to compare the transformed layer vs. the original. I don't think it's a good idea to rule out that situation, but I'm convinced that it's an exception, and more frequently users want the original layer hidden. Does anyone have a different opinion on this one? I'm interested to know alternative workflows where that option is more useful than hiding the original layer. Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Help to write plugin
El lun, 05-10-2015 a las 13:06 +0300, Alexandre Prokoudine escribió: > On Fri, Oct 2, 2015 at 6:35 AM, Andrea Bortesi wrote: > > Hi to all, I'm searching for someone to write an gimp plugin for > > me. > > I'm unable to do it. > > I don't know how to do in this case. > > I'm sorry if this is not the correct place to call help. > > If someone have time to spend for me please contact me. > > The plugin should visualize the live webcam image into a layer. > > I need it to overlay other image with transparent portion to see > > through it > > the webcam video. > > Is intended only to see the result in real time, not to generate a > > static > > image. > > Hi Andrea, > > GIMP is not the right tool for that. > > Perhaps you would have more luck with some VJ app that would take > your live video input, overlay some image on top of it, and display > the composite image on a display. On Linux that would be FreeJay, > Lives, VeeJay, or Qeve. Hi Andrea, if you were willing to write a plugin, then you can also try Processing. (www.processing.org) Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Portable development environment for GIMP
El mié, 30-09-2015 a las 23:49 +0200, Michael Natterer escribió: > I hope that nobody uses debian testing, the most unstable of > all debians :) Testing is simply a rule we use to figure what we > can depend on, nothing more. We needed some rule and made one. Sore feelings after the gcc-5 migration? :-) G. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Reg:Usuage of the Gimp for my Organization
El vie, 18-09-2015 a las 20:15 +0200, Nikola M escribió: > On 09/18/15 07:10 PM, Gez wrote: > > I wonder if saying that the only license pertains to the source > > code. > > I'd say that the binaries are also covered by the license, since > > you > > are obligued to make the source code available when you distribute > > the > > binaries. > > Source code is covered and source changes, if binaries are > distributed. > But binaries itself can have whatever licence one wants, if source > and > source changes are available. > That is exactly what this thread is about - there is the difference. No, you're wrong. You're misinterpreting one the GPL terms that says that you're not obligued to publish your changes if you're not going to redistribute the modified program. That means: If you change the code, you may use the software without publishing the modifications *IF* you're going to keep the program for yourself and nobody else. But if you're going to give the modified program to someone else, you have to give them the modified sources as well. It has NOTHING to do with the license. The license for GPL licensed work is and will be always GPL unless you're the only person who wrote the original code and therefor you keep the right of re-licensing it to whatever license you want. But you can't relicense somebody else's code which is under the GPL. Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Reg:Usuage of the Gimp for my Organization
El vie, 18-09-2015 a las 21:23 -0300, Gez escribió: > It has NOTHING to do with the license. The license for GPL licensed > work is and will be always GPL unless you're the only person who > wrote > the original code and therefor you keep the right of re-licensing it > to > whatever license you want. I stand myself corrected. In the above paragraph I made a mistake: If you're the rights holder of the original code you're free to distribute it with a different license. That's not the same than saying that you're free to re-license the GPL code. Once you freed it under the GPL terms, others are free to use it and you can't forbid them to do what the GPL allows. You can, however, use the same code in a program distributed with a different license, but that's because you hold the original rights, the GPL-licensed code stays GPL. Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Crash with Print simulation
El vie, 18-09-2015 a las 13:56 -0400, Elle Stone escribió: > Hmm, hopefully it was implied by the post topic, but in > "Edit/Preferences/Color Management" pick "Print simulation" as the > "Mode > of operation". Yes, it was clear. But now that you mention it, does the "color proof" display filter produce the same crash? ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Reg:Usuage of the Gimp for my Organization
El vie, 18-09-2015 a las 14:10 -0300, Gez escribió: > "The program itself is governed by the terms of the GNU General > Public > License (GPL) which ensures that users have freedom to use the > program > with any purpose, study and modify its source code and share > modifications to the community. You are allowed and encouraged to > share > the program with your friends and colleagues, install it in your > school > or organization and use it for any purpose. > If you're planning to modify the program and re-distribute it with > your > modifications, make sure that you make the source code available too. > That's the only obligation required by the license. > Follow [this link] if you need more information abut the GNU General > Public License." I missed the "no warranty" bit. Is it really necessary? If yes, why? Is it some required legal waiver or just a kind way of saying "don't blame us if something went wrong and you lose your work"? Personally I find that kind of stuff really unnecessary. It's like making an excuse in advance: "look, it may fail, don't blame us". If someone wants to sue you I don't think the "no warranty" claim will make any difference. But seriously, who would do that? I've been working with software for 20 years, I've lost count of the times I've lost work because software failed, crashed or froze. I may or may not cursed the software and its makers when that happened, but never thought about suing the makers for the half hour of work I lost because I forgot to hit CTRL+S (or CTRL+E :-p) That being said, GIMP is probably the most stable software I use, which makes that remark even more unnecessary. Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Reg:Usuage of the Gimp for my Organization
El vie, 18-09-2015 a las 16:03 +0100, C R escribió: > I have added a hyperlink to "Free and Open Source Software", that > links to > https://www.gnu.org/philosophy/free-sw.html > > My thought is the gnu.org page explains the freedoms of all open > source > software well enough. I've only filled in the direct implications of > the > four freedoms for GIMP software users in regards to the questions we > keep > getting regarding licensing, and usage of GIMP for professional > purposes/companies. > > Changes welcome as always. The license information block has a typo in the title, and GIMP is mentioned as "the GIMP" a couple of times. Also the GPL link is listed twice, in a couple of paragraphs that are a bit redundand and probably can be merged into one. I wonder if saying that the only license pertains to the source code. I'd say that the binaries are also covered by the license, since you are obligued to make the source code available when you distribute the binaries. I think the first paragraph is ok (once you remove "the" from GIMP), but the second one needs work for more clarity. I'm not a native english speaker, so maybe this isn't 100% correct, but I'd go for something like this, replacing the second paragraph: "The program itself is governed by the terms of the GNU General Public License (GPL) which ensures that users have freedom to use the program with any purpose, study and modify its source code and share modifications to the community. You are allowed and encouraged to share the program with your friends and colleagues, install it in your school or organization and use it for any purpose. If you're planning to modify the program and re-distribute it with your modifications, make sure that you make the source code available too. That's the only obligation required by the license. Follow [this link] if you need more information abut the GNU General Public License." Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Asking for a Miracle !?
El jue, 30-07-2015 a las 11:52 +0100, C R escribió: It seems to me, the real problem is not that it doesn't have the same UI as Photoshop, but rather that people forget how long it took them to learn Photoshop in the first place. I've found that showing people the power of the software, more often than not, rekindles that essential flame of curiosity, which is essential to learning anything new. The rest is patience, and realising that the time investment pays off tremendously in the end. Even if you can not replace Photoshop entirely in your working environment, you have one more standards-compliant tool to produce graphics, and this tool is usable by everyone in the world at no charge. That's an enormous advantage over Photoshop, and well worth the time it takes to learn the software. I concur. I have similar stories about people complaining about how bad, incomplete, uncapable and clunky GIMP is, until they actually see it working for real. Most of the complaints come from a brief look at the UI and trying to do something the same way they'd do with the other application. When they fail then the tool sucks. When you switch to a new tool you have to spend some time with it learning how to use it. It's curious that so many people who moved from Corel Draw to Illustrator forced themselves to learn the new tool despite its differences with the latter, but they tear their clothes when somebody suggests that they have to learn something when they move from PS to GIMP. I think it's a status thing. Moving from one software to another which is some sort of industry de-facto standard, costs money, regarded as better, etc. that's perceived as an improvement, so the effort needed to learn the new thing seems justified. However, moving from THE de-facto industry standad to a free application made by a group of volunteers is perceived as a downgrade, so people puts the burden on the application. It's not fair at all, but it is what it is. The only way to fight that is with education, showing people what can be done with the tool. Results matter and the process matters too. Your gif is a nice example because it show that complex things can be done. Maybe it would be a good idea to post some breakdowns and timelapses of complex work done in GIMP as an example of what can be done with the tool. Not tutorials, real world examples of good work made with GIMP, so new users get to know what results to expect once they master the tool. Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Due diligence: Permission for usage of GIMP
El dom, 21-06-2015 a las 16:29 -0500, Apollo D. Sharpe, Sr. escribió: Gez, Thank you for your reply. My question isn't really about using the actual program itself or anything dealing with the code. My question really is about permission to use screenshots from the program, linking back to your homepage, linking back to your help page assets. I'm asking for permission to reference your web assets from our website. I don't think that requires permission. Using application screenshots is a fair use (as long as they don't depict anything objectionable or illegal, I think). Linking back to the official site gimp.org is a good thing too, you're sending your users to the place where the actual project lives and where its official docs can be found. As C R just said, I'm also curious about the details of your project. Just out of curiosity :-) Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Due diligence: Permission for usage of GIMP
El dom, 21-06-2015 a las 14:08 -0500, Apollo D. Sharpe, Sr. escribió: Hello, I'm not sure who to exactly send this to, but I represent Iron Rook Computing, LLC. In the coming months, we will be releasing a product that utilizes some of your software. As due diligence, I must officially ask for permission to mention the usage of your software, link to your websites, and use images that show your software in action. We would use these permissions in the following ways: * In our promotional material (written, digital, or otherwise) * In our customer support troubleshooting systems * In any instance which such usage would be required to help users accomplish their task * In any instance which such usage would be required for our employees to their task It's unfortunate that these things have to be done, sometimes, to cover our tails. I'm not sure who's actually in charge, so I'd appreciate you're help in getting over this hurdle. Apollo: The license of GIMP (GPL) allows you to use GIMP for any purpose, so if your question is regarding usage of GIMP, you have absolutely no restrictions about how to use it and you don't have to ask permission to use it. The only restriction that applies is regarding code: as you have the source code of GIMP available and you're free to study it and even modify it, if your make your own modifications and plan to redistribute them you're obligued to distribute the modified code along with the executable. If you're not planning to make any modifications to the code, you don't have to worry or ask for permission. Gez ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] wtf with the download?
El lun, 01-06-2015 a las 01:04 +0100, C R escribió: Thanks for the comments. For reference, the font styling is the same that is already deployed throughout the site, the rounded corners mimic the download button on the front page with the added requirement that our not contain bitmap graphics, and the color scheme is designed to fit on with what's there. As much as possible, I wanted to keep the interface consistent with the rest of the site. This avoids the new buttons looking out of place as discussed much earlier in this thread. If you have a cleaner approach that achieves the same effect, feel free to submit a patch. I'm not precious about the code. Hi, A few days ago after your design was implemented I provided a patch that cleans up the markup a bit and makes some minor tweaks to the appearance of the buttons. The patch wasn't reviewed yet, so I'm leaving this message in case somebody wants to take a look and give their opinion. http://www.ohweb.com.ar/test/GIMP-download.html The main difference is that it doesn't use tables and the links themselves are styled instead of wrapping them with divs. I showed this to a couple of guys in the IRC channel, and they gave me some useful feedback about the size of the fonts. It's true that the via HTTP and via BitTorrent labels are a bit small, specially if you use a high resolution display, but I tried to keep the appearance of your buttons as much as possible. Also I kept the over color the rest of the links of the site use. It looks ok on the teal background, but it doesn't look so good on the orange one. Maybe that has to be changed too. Thoughts? Gez ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Cropping border color
El jue, 04-06-2015 a las 07:47 +, Saul Goode escribió:
On Jun 1, 2015, at 11:07 PM, Brad Gibson bradgibson...@yahoo.com wrote:
It would be great if I could choose to see pure black around whatever I'm
cropping, because I make very meticulous crops of photos for artistic
purposes, and I often have to crop and go back multiple times because it
looks different in the final version with solid white/gray/black compared
to transparent while I'm cropping. Or else, if it's easier, make it so that
I can undo the finalization of the crop but go back to where I left the
crop at. Thanks.Brad G.
Are you willing to re-compile?
If you change the passe_partout color in app/display/gimpdisplayshell-style.c
[1] to be { 0.0, 0.0, 0.0, 1.0}, you should achieve the result you seek
(though I have not tested this).
Making the color and opacity of the passepartout an option of the crop
tool would be a nice feature. The quick mask already has that and it's
really useful.
G.
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] sRGB was second worst performer against spectral reference
El mié, 13-05-2015 a las 10:36 +0200, Simon Budig escribió: Simone Karin Lehmann (sim...@lisanet.de) wrote: No, the conclusion is quiet easy. And it’s what Elle says for, AFAIK, more than a year. ...and what the GIMP developers have accepted for more than a year. Just for the records. (not arguing or trying to bring back the neverending thread, just asking for the records) What's the immediate plan for 2.10? It's still using unbounded sRGB for the working RGB pixel formats? As it was already discussed, that would be enough for keeping things more or less consistent with earlier versions of GIMP (i.e. getting sRGB right) and fast, but potentially problematic when dealing chromaticity dependent operations and wider gamut colorspaces. I've been told that the goal is to release 2.10 with GEGL providing the same functionalities and keeping the legacy appearance of legacy files as soon as possible and then take care of specific color management in future versions. That seems a reasonable plan, of course, but I'm curious about how the program will deal with non-sRGB images if editing them in the source colorspace won't be possible and some operations are likely to fail with unbounded sRGB. Forcing a bounded conversion to sRGB for the time being could be a solution, although quite unpopular for anyone using anything but sRGB. Or is there still chances of an anyRGB pixelformat allowing working on the artist's colorspace of choice for 2.10? Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] wtf with the download?
El jue, 07-05-2015 a las 20:39 +0100, C R escribió: Yes, and to also force Bittorrent knowledge upon users. If I were a new user, I'd Google torrent and immediately get links for Pirate Bay and other dodgy stuff... nothing having to do with GIMP. Thought we were trying to prevent people from going to 3rd party websites and downloading viruses accidentally. Having to install a 3rd party downloader just to install GIMP is a pretty big hurdle for a lot of people, and they are likely to encounter lots of dangerous DOWNLOAD NOW buttons. ;) It takes trust in two different software packages just to install one program. [snip] I guess I'd ask: Is it more important to enlighten people (and are we really doing that, or just scaring them off, or needlessly endangering them?) about torrents, or is it more important to make the installation of GIMP as easy and enjoyable as possible? [snip] Maybe a link to torrent tutorials /help files if the user wants to enlighten themselves, and we should say right away why torrents help us, so the user can make an informed choice. TLDR: I think we could at least make the experience more pleasant, and we don't even have to change the options. You've already answered your own questions yourself :) Choosing torrents as the primary choice is not a bad choice, and if a Google search is likely to return things related with the fabricated bad reputation torrents have, the answer is not removing torrents but communicating better why bittorrent is the right choice for software distribution. Enlightening people AND making the experience pleasant shouldn't be two mutually exclusive options. So yes, keeping the right options and teaking a little how the options are communicated to users should be enough to avoid misunderstandings. People who do not read beyond the first line on our downloads page might not be happy with using GIMP, we might be doing them a favor with the current setup. I got scolded for expressing that opinion. Yea, was worded slightly different, but... lol Well, I've been an ass, been diplomatic... now I'm thinking of being lazy. Anyone wants graphics, let me know. I'm glad to help. I'm a graphic designer like you, but I think this can be solved just by tweaking the page contents alone. Text styling hierarchy should be enough. Let's try to come up with a better wording for the options, adding some short and easy information about the options, and that's it. If some of those ideas can be communicated better with graphics than with text, then let's try some graphics. The download button solution has some drawbacks as Michael pointed out, we should only use it if nothing better comes up. Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB
El dom, 03-05-2015 a las 13:32 -0400, Robert Krawitz escribió: On Sun, 03 May 2015 02:34:26 -0300, Gez wrote: El sáb, 02-05-2015 a las 12:40 -0400, Elle Stone escribió: Well, you might be able to answer that question. I'm not qualified. Personally I don't use alpha channels except in the extremely rare instance when I'm exporting a png with a transparent background for use on a website. See, this is exactly what I intended to discuss. You know a lot about linear and perceptual gamma, so in your opinion everything has to be tailored to allow you to play as you wish with gamma. For you it is essential. Now, you think you don't use alpha channels, so you don't care much about the options provided. But you actually use alpha channels a lot: every time you create a layer mask you're creating an alpha channel for that layer, and if that alpha is associated or unassociated makes a big difference. I agree, but draw a very different conclusion (my conclusion is in line with Elle's). Then what? Every single operation and the layer stack in GIMP should have an extra checkbox for selecting how alpha will be treated? We can go on forever with examples like this, adding checkboxes for every possibility. Are you saying that this is a good way to design a user interface? AFAIK, most of the time alpha channel is unassociated in GIMP, but when you have to apply any convolution you have to pre-multiply it. And what about alpha channels being linear or perceptual? Why don't you care? In that case, developers chose for you, and you don't seem to feel too bad about it. Right. The problem is when you're one of the people who *do* care about it. I took this example because I do care about alpha channels. There are some conventions about how to use alpha channels properly and I think it's reasonable to expect that the program I use adheres to those conventions. And believe me, when it comes to alpha channel THERE IS right and wrong, no matter what the artist says. Perhaps, but someone may have a reason to want a particular workflow, even if that reason is nothing more than demonstrating what's wrong with it. If I have to show the nasty effects of a wrong manipulation of the alpha channel, GIMP already gives me the tools to do that. If I have to show the nasty effects of doing an alpha over composite in gamma space, well, I don't have to do anything currently, but I could do it as well with a tool that offers only linear compositing and a gamma/curves/levels tool. I'm just arguing against adding checkboxes arbitrarily just in case the user wants to do anything. That's bad UI design. I'm trying to discuss the costs and benefits of adding that complexity. Isn't this achievable with different tools and methods? Is it needed so frequently that is reasonable to add an extra checkbox to every single operation? Nobody answers that. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB
El sáb, 02-05-2015 a las 11:18 -0400, Robert Krawitz escribió: On Sat, 02 May 2015 11:21:37 -0300, Gez wrote: El sáb, 02-05-2015 a las 06:09 -0400, Elle Stone escribió: I'd like to see this discussion heading towards a real world list of examples of real needs for such options that can't be satisfied with anything else than these toggles. You are presupposing that the devs can foresee every possible use to which a user might put a given editing operation. No, I'm saying that users like us should describe real world situations where certain options are needed in order to convince developers of the necessity of such options. Let me do whatever I want is not a good argument. Yes it is, because we don't know every possible use to which someone will put something. We've had the same issue come up in Gutenprint. Gutenprint exposes just about every internal control option to users, if they want to play with them. It allows things that could actually cause _physical_ damage to printers, in particular specifying ink limits so high that they would completely soak through non-coated paper and would form large puddles on coated papers that could gum up the print head. But then it turned out that people wanted to do things with printers that we had never envisioned: printing T-shirts, and doing chemical deposition (in one case, literally printing circuits onto paper using electroconductive inks). It turned out to be very fortunate for those users that we had never imposed limits of that kind because that isn't something anybody should be doing. The one concession that we did make was to group options into different levels of interface complexity, and add an option to the PPD file generator to generate simplified PPD files with only the basic options. But the default is to use the full-featured interface. Obviously there are resource constraints here; developers can only do so much, and have to make decisions about what to do that are mutually exclusive on time constraints alone. But deliberately leaving something out of this kind of project because there isn't an obvious real world use case is not, in my view, a good thing. Let me clarify that I'm not against flexibility or giving users control on the processes. It's not about choosing between no control and full control. Is finding a balance where a UI provides the necessary tools for the regular job without hindering the possibility of experimentation. It's extremely difficult to create a UI that both exposes every possible user and provides a fast and comfortable workflow. Adding checkboxes and buttons for every need doesn't solve the issue. Pretending that you can separate the basic and the advanced users in two simple groups by providing insufficient tools for basic users and the cluttered UI for advanced ones is not going to result in a good tool. Nodal UIs aren't perfect, but provide a good balance because every tool is an individual node, and power and flexibility come from combining those nodes. In this case of linear vs. perceptual, a gamma node would allow to turn every operation in a linear workflow into perceptual. Notice how different is the paradigm: a single tool that changes how other tools act instead of adding an extra option to every single tool. And a tool that is added on demand, only people who want to use it will be exposed to it, and the rest wouldn't be disturbed by a cluttered interface. Unfortunately, the UI paradigm in GIMP and similar applications makes this really difficult, because it's inherited from a time where all the operations were sequential and destructive. Again legacy stopping progress. Part of this is a UI problem, and adding buttons or checkboxes for every possible alternative isn't a good way to design UIs. https://twitter.com/cowbs/status/516045565847535616 ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB
El sáb, 02-05-2015 a las 06:09 -0400, Elle Stone escribió: But you're not proposing to add a toggle to gradients alone, you're proposing to put them*everywhere*. Yes. And your reason is that users have to decide how operations are performed, no matter the result, no matter if it makes any sense or it doesn't. So what about other aspects like alpha association then? Should toggles be added everywhere for that too so the users can decide if alpha will be associated or unassociated? I'd like to see this discussion heading towards a real world list of examples of real needs for such options that can't be satisfied with anything else than these toggles. You are presupposing that the devs can foresee every possible use to which a user might put a given editing operation. No, I'm saying that users like us should describe real world situations where certain options are needed in order to convince developers of the necessity of such options. Let me do whatever I want is not a good argument. The need of linear and perceptually uniform gradients is a real need. You can easily document when you need one or the other and create simple examples. Now, give me a good example why scaling should be better done in perceptual gamma (other than preserving legacy appearance, which is the ugly situation that took us here in the first place). You'll find soon that aside from keeping legacy appearance, the situations where you need operations to actually work in perceptual gamma are rare. So in practice, combining linear and perceptual back and forth during your work is not something you need all the time. Tell me for instance why in your UI proposal you merged a layer using the screen blending mode in perceptual gamma. What's the need there, what's the effect achieved? Each case is different and should be designed according the needs. That's what design is about. Addressing needs and crafting solutions. Again: I want to do whatever I want with the tool is not a good starting point. You can use your laptop as a hammer if you want, but it's not designed for that use and you can't expect designers to contemplate that use when they plan the thing. Currently the user does already have linear vs perceptual choices through the GIMP UI for most editing operations (scaling is always linear, drawing a gradient is always perceptual). Currently the user can use or not use the gamma hack. And the user can use linear or gamma precision. That's two time two equals four possibilities for the user to try for each and every editing operation. Again: developers have already said that the gamma hack and even the precision modes are a temporary situation and they are not final. You're exposing your case based on the wrong assumption that those things are going to stay as they are. Now tell me without taking the time to try all four possibilities: How does the user get a linear gradient? (sorry, you can't) That's a reasonable question. It's easy to show why true linear gradients are necessary. How does the user get linear gamma channel mixer? How does the user get perceptually uniform Filter/Noise/Add RGB noise? I think you're asking the wrong questions. The real question is: Why and when operations should be performed in perceptual gamma? The answer seems to be (at this point at least) legacy appearance. Most of the times. So, if the goal is to release a GEGLized GIMP that provides the same results as 2.8.x, tools have to work like that. I don't like it and I'd prefer that a true linear workflow is implemented where nothing has to be flipped to perceptual unless there's a good reason. And I bet that those good reasons would be rare, real exceptions that could be treated as such. Why don't we use the energy and time we're using for these discussions for documenting an artist workflow based on linear RGBA (as most of the modern digital compositing packages use)? ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB
El sáb, 02-05-2015 a las 12:40 -0400, Elle Stone escribió: Well, you might be able to answer that question. I'm not qualified. Personally I don't use alpha channels except in the extremely rare instance when I'm exporting a png with a transparent background for use on a website. See, this is exactly what I intended to discuss. You know a lot about linear and perceptual gamma, so in your opinion everything has to be tailored to allow you to play as you wish with gamma. For you it is essential. Now, you think you don't use alpha channels, so you don't care much about the options provided. But you actually use alpha channels a lot: every time you create a layer mask you're creating an alpha channel for that layer, and if that alpha is associated or unassociated makes a big difference. AFAIK, most of the time alpha channel is unassociated in GIMP, but when you have to apply any convolution you have to pre-multiply it. And what about alpha channels being linear or perceptual? Why don't you care? In that case, developers chose for you, and you don't seem to feel too bad about it. And believe me, when it comes to alpha channel THERE IS right and wrong, no matter what the artist says. Blending modes and other operations have been designed to work in certain way. They have an intended result. Unfortunately limitations in the available technology in the past forced programs to do things as alpha compositing in 8 bit gamma. It looks like shit but users got used to that appearance. That doesn't mean that alpha compositing in gamma space is ok and it is a valid option so programs SHOULD allow it. It's an infortunate legacy that could be corrected by making the tool work as it should work, as it is intended to work. Some people may want having the uglyness back, so a special (optional) tool to override the proper behavior with that crap could be used. Personally, I'd love to see all the operations work on linear data only. If a mechanism for overrides is in place, getting legacy support would be probably just matter of setting a global override making everything work in gamma. In both cases an extra tool could allow flipping stuff to the other mode temporarily. In the case of gamma we've been discussing it is something that seems to be just one gamma node away. Actually, you don't even need that. with enough bit depth the levels tool alone is good for making gamma stuff more or less linear and linear more or less perceptually uniform, for artistic purposes. And since you don't seem to worry about right or wrong results, that should suffice. Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB
El vie, 01-05-2015 a las 18:03 -0400, Elle Stone escribió: On 05/01/2015 04:47 PM, Gez wrote: El vie, 01-05-2015 a las 05:40 -0400, Elle Stone escribió: This is a color managment issue. It's fundamentally important. GIMP shouldn't make decisions like use linear here and perceptual there, other than to offer the user good defaults. A color management issue? You're proposing to let users do whatever they want with the trc, Yes. I don't understand why this bothers you so much. Because I'd expect better answers than just because. The tool should provide a reasonable range of tools and possibilities to allow people do things. And let me do whatever I want with X is not reasonable. If you don't provide solid reasons backing why you would need some behavior, don't expect the developers to implement it. It's like asking the makers of a word processor to allow editing the page upside down or mirrored and replying because the program should let me do whatever I want when they ask you why. no matter if it's right or wrong. There is no right or wrong with respect to whether any given editing operation is done using linear or perceptually uniform RGB. Right or wrong depend on what the user wants to accomplish. For example: If the user wants to draw a gradient that drops off like real light drops off, the user should use linear RGB. Using perceptually uniform RGB would be a mistake. If the user really wants a gradient drawn using perceptually uniform RGB because she needs the tonality to not drop so quickly from white to black, that's the user's call to make. The developers aren't sitting in the right place to make that kind of decision for the user. Why do you want to put roadblocks in the user's way? There are certainly rights and wrongs when using a tool. If the tool is designed to work some way and you don't respect that, you're doing it wrong. Try taking a hammer upside-down and hammer nails with the handle. That's wrong. You chose one of the few cases where both linear and perceptually uniform could be valid options and none of them are right or wrong. Of course I'm not against allowing two valid instances of the same thing, like in this case. But you're not proposing to add a toggle to gradients alone, you're proposing to put them *everywhere*. I'd like to see this discussion heading towards a real world list of examples of real needs for such options that can't be satisfied with anything else than these toggles. That's a color management issue! Yes, it really is a color management issue. In PhotoShop, if the user wants to perform operation X on linear RGB, the user must do an ICC profile conversion and convert the entire layer stack to a linear version of the RGB working space. And when the user wants to perform operation Y on perceptually uniform RGB, the user must convert the layer stack back to the perceptually uniform version of the RGB working space. The babl flips *could* make it possible for the user to easily choose linear vs perceptually uniform RGB without having to use an ICC profile conversion to convert the entire layer stack back and forth between linear and perceptually uniform RGB. With GIMP right now, the user has no choice in whether linear or perceptually uniform RGB is used. Or rather choice is via the gamma hacks and precision changes, which leaves the user to play a guessing game about what's happening to the data. With GIMP as currently programmed, the user can't even resort to the PhotoShop option of converting the layer stack, because the babl flips presume the sRGB TRC. I was with you when we both discussed these issues with the GEGL and GIMP developers a few months ago. They stated clearly that the immediate plan is to make GIMP 2.9 work exactly as the current stable version with the new GEGL core. Everything else is just a bonus. The minimum goal seems to be having a GEGLized version of the current GIMP, which is still 8bpc sRGB. If that's the goal and they are working towards that goal, why keep insisting on what's wrong with high bit depth editing? How do you ensure correct results when the user can change that at will on every single operation performed? It's the user's job to make the right decisions regarding how to edit the user's image. It really isn't a developer responsibility. It's a shared responsability. Developers have to design tools in order to facilitate users making the right decisions. A good tool makes it easy to do the job properly and allows extra control. It's not the users job to dictate how a tool has to be designed, and it's certainly not the designer's choice what users will do with the tool. The designers have to address the users needs and give them capable tools. This should be a collaboration and not a struggle. Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list
Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB
El vie, 01-05-2015 a las 05:40 -0400, Elle Stone escribió: This is a color managment issue. It's fundamentally important. GIMP shouldn't make decisions like use linear here and perceptual there, other than to offer the user good defaults. A color management issue? You're proposing to let users do whatever they want with the trc, no matter if it's right or wrong. That's a color management issue! How do you ensure correct results when the user can change that at will on every single operation performed? And how do you plan to let users keep track of the flips they intentionally added with a UI that is sequential and doesn't expose the pixel format resulting from each operation? I mean, instead of putting toggles on EVERYTHING, why not adding a tool that says from this point, the following operation/s will be performed in linear/perceptual gamma? Because there is no from this point in RGB image editing. It is not the case that until point X use linear RGB and after point Y use perceptual RGB makes any sense. Yes there is. Most of the tasks performed by a user on an image are sequential, specially with a UI like GIMP's. Back when Peter Sikking was involved in GIMP UI, he proposed to implement non-destructive editing as a stack of operations. With a UI like that it would be really easy to visualize the gamma toggles I mention. They would be extra operations overriding the pixel format requested by each operation, they would be optional and added on demand by users. In a sense it's exactly the same you're asking, but implemented at a workflow level rather than plaging the UI with toogles for everything. It would be easier to visualize and follow too. EVERYTHING NEEDS A TOGGLE. It's an operation by operation decision. The user has a right and the *need* to know and be able to control what's being done with the user's own RGB data. GIMP should NOT make such decisions behind the user's back, forcing the user to use linear RGB in one place and perceptually uniform RGB in another place without so much as a by your leave. GIMP can't know the user's technical purposes. GIMP can't know the user's artistic intentions. Right now the babl flips are a hobble, not a help. EVERYTHING NEEDS A TOGGLE is an all-caps overstatement. What's next? Toggles for associated or unassociated alpha on every single operation? And let's go further: If the artist wants to do something in a different color model just because the UI of *each tool* should reflect every possible caprice? A program should provide correct results and provide tools for some creative deviations. That's not the same than saying that the program should provide whatever results any user wants regardless if they are technically correct or not. You are proposing to add options to make operations deliberately give wrong results just because the user wants it. You want to completely take the decision of what's technically correct away from developers. If I remember correctly you criticized pippin because he wanted to do the same in the opposite end (make the program make all the decisions and assumptions, deny the users the freedom to choose). As a user, I would like to see a program that makes both the right technical choices AND allows me some flexibility. That's usually a job for a good UI, and that's why it's critical that functions are designed with both techical correctness and user interaction in mind, from day 1. Nodal interfaces allow a great degree of flexibility by keeping operations as single units that can be connected in different ways. Current GIMP's UI is sequential. One thing comes after another. Each operation (except layer blending) is sort of modal. You do one thing at a time, and you can't go back in time without undoing what you've already done. This means that any time you run an operation on pixels you'll get a dialog with the possibilities of that tool. The more possibilities the tool has, the more controls and more cluttered interface. That's what I'm against. No sane and fast workflow can result from dialogs plagued by dozens of options. It's a problem that has to be dealt in a different way. We don't need tools that allow every different possibility. We need different tools for every possibility. The tools should remain simple and correct, and if you need to do something crazy, there should be a tool to bend how things work. Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB
El jue, 30-04-2015 a las 17:40 -0400, Elle Stone escribió: On 04/29/2015 03:57 PM, Joao S. O. Bueno wrote: Now help us think on the next steps. For example get that e-mail worked into a feasible specification: If you can, refine it, then maybe try to get someone with UI expertise that could fine tune that your suggestions into specifications that could be really great - now we don't have Peter helping the project anymore. (could be someone from your area, to whom you could get face to face meetings) - (I'd rather have another switch along the layer modes than to duplicate all layer modes in the UI, for example) - This link has three screenshots illustrating a proposed UI for allowing the user to easily choose between linear and perceptually uniform RGB and to know at a glance whether s/he's using the default set by the developers: http://ninedegreesbelow.com/bug-reports/gimp-linear-perceptual-rgb.html Is what's shown in the screenshots feasible in terms of linking the operations to the proposed UI? Hi Elle, You know I'm with you regarding giving users more control over how operations are performed, but tossing buttons for toggling between linear and perceptual everywhere in the UI is not a proper solution. It would be extremely confusing, and people would start toggling them randomly without knowing what exactly they are for, and only a few people would benefit from it. I think that allowing that would complicate the UI and the the tools themselves, as all of them should have both paths available. A better solution would probably have to wait until proper no-destructive editing is finally implemented, and operations are visualized as a stack/chain/whatever. I mean, instead of putting toggles on EVERYTHING, why not adding a tool that says from this point, the following operation/s will be performed in linear/perceptual gamma? People used to node-based UIs will understand exactly what I mean. The difference would be that only users who need the toggle will add an operation that makes the switch when it's required. The UI will remain lean, without extra options that could potentially confuse less advanced users. Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Gimp in private schools and educational institutions
El mié, 29-04-2015 a las 14:47 -0400, Nathan Summers escribió: On Tue, Apr 28, 2015 at 4:34 AM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: Furthermore, I suggest you exercise nastyness elsewhere. This is a mailing list for discussing development of GIMP. There's nothing nasty about what he said. The name of the program actually is a serious impediment to the development of GIMP, and if it's not to be discussed here, then where? Sam makes several excellent points about why GIMP doesn't get the kind of professional contributions that other projects of similar stature such as the Linux kernel or Firefox, and I think there's a lot of truth to what he says. Earlier I proposed to solve this issue by adding the en_US-prudish locale as a joke, but now I'm not sure it's even a joke. As every message in this thread (and older threads about the same subject) clearly show, this is an issue that only affects some americans. Nobody else seems to be having any troubles with the name. Even if everyone in the USA have issues with the name (which doesn't seem to be the case either), it's still a regional issue. So IT IS a little bit nasty to treat anyone defending the name as idiots who intentionally chose a name that harms the project. Nobody else cares about the name outside the US, and coincidentally nobody seems to be too concerned about GIMP as a product competing in an industry as americans are. Most of us just want to see GIMP becoming a capable tool suitable for our everyday tasks. I don't think the name will prevent that and I don't think it will ever prevent coders interested in making it a better tool from joining the project. That being said, it is a shame if a few american schools where GIMP could be used stop using it because of the name, but it seems that it could be solved by creating a new locale where GIMP is renamed and point people uncomfortable with the name to change it. GIM could work. But again it's a regional issue, and renaming the entire project because a few people don't like it would be overkill (and yes, in the world context a few americans whining about the name IS a few people). The case of the Mitsubishi Pajero I referred to earlier was solved by renaming the product only for a specific region. The product kept the original name for everywhere else. No big deal apparently. Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Gimp in private schools and educational institutions
El mié, 15-04-2015 a las 10:43 -0400, Elle Stone escribió: On 04/15/2015 08:19 AM, Joao S. O. Bueno wrote: On 15 April 2015 at 05:40, Simon Budig si...@budig.de wrote: No. It would only play into the hands we already have with fake packagers who sell Gimp without mentioning the Gimp brand name and without mentioning that Gimp is available for free as well. Indeed - Mr. Bagot - I think the best approach you have is write the Software name in full in all possible instances (e-mails, documents, letters, etc...) - just write GNU Image Manipulation Program - and leave the acronym as if it did not exist in all written documents. ... Exactly. Software developers shouldn't be required to choose names that are free of all unwanted connotations in all languages, especially given that new unwanted connotations spring up just as fast as old unwanted connotations fade away. Connotations are in people's mind, not in actual words. I am a native English speaker, but I didn't hear the unwanted connotations in the word GIMP until a couple of friends snickered, which reflects rather more badly on their minds than it does on the name GIMP. Guys, don't get me wrong. I didn't suggest that the name has to be changed or that it's even possible to choose a name that is 100% free of accidental connotations for a project. I just threw an idea about a possible solution for people who wanted to use GIMP but had troubles with the name. A patch for changing the name in the UI. You live in an area where the name of the program could be a problem? then build GIMP using the patch. Maybe changing the name isn't even required. What about just adding punctuation to make the the acronym thing more obvious? So, to be clear: what about a patch that replaces the few places in the UI the name GIMP with G.I.M.P.? Not for everyone, just for the people who want to use GIMP but have issues with the name. Personally I'd prefer that people can get over this kind of stuff and do nothing about the name, but the prospect of over-sensitive people keeping GIMP out of children schools because of the name makes me wonder if a little compromise isn't a reasonable idea. It's not the end of the world, and there are several precedents of products that were renamed for specific markets. The funniest one I know is the case of the Mitsubishi Pajero, that was renamed to Mitsubishi Montero because pajero means wanker in several spanish speaking countries. That's far worse than spanish people expecting Joao to be good :-) Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Gimp in private schools and educational institutions
El mié, 08-04-2015 a las 12:58 -0500, Sam Bagot escribió: Hi, my name is Sam and I have been involved in several projects ranging from art classes in public schools to local art communities around Austin. I am a Linux person and use Gimp for everything. I keep running across the same problem though. The name Gimp is offensive to people and suggests inferiority to Photoshop. In my experience, institutions would much rather pay for a professional product than teach a class to children involving gimps. Which is also inappropriately associated with BDSM sex. Either way it's looked at. A product called Gimp can't be used by a public or private school. Is there any thought on salvaging the marketing effort and renaming this product so that it can be taken seriously by people and institutions? Also, a big barrier to entry adopting Linux for people is a solid graphic manipulator. The bad branding is causing many people in my art communities around Austin to avoid Linux in general. What are the plans on renaming and success? Hi Sam, this issue has been brought here a lot of times, and the answers are pretty much the ones you already got: GIMP is an acronym, and is not going to be changed. I have a suggestion, though: Since this seems to be a problem that only affects people from the USA, why not looking for some volunteers from that country to contribute with code or some money for an optional patch that provides and easy way to remove the name GIMP from the UI, replacing it for a different one? For instance, you could call the program Wilber, which is the name of the project's mascot. There are rumors that Wilber is not a dog, but a GIMP. But nobody has to know it :-) Now, seriously. What do devs think about this idea? If somebody provided a good patch for building GIMP easily with a different name as an option, would you accept that patch? In that case, a document with instructions for building the official GIMP with its name changed, linked from the FAQs would be a quick answer for these recurring inquires about a name change. Gez ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Create New Layer Button
El dom, 29-03-2015 a las 11:53 -0400, Elle Stone escribió: What you just described - shift-click the new layer button plus dragging the foreground/background color - works perfectly, MUCH better than using the new layer dialog. Thanks! Many thanks!! By comparision, using the new layer dialog really is cumbersome. Dragging bg/fg colors to the editing area is definitely a handy option in GIMP, and it also has predefined keystrokes (ctrl+. and ctrl+,). iirc the keystrokes are the same that PS uses. If clicking just created a transparent layer, it would be much faster and less disrupting to fill the new layer afterwards when it's required. The only situation that would require an extra click is filling with white if other BG/FG colors are set, but it's just one click away. Where's the documentation for these two shortcuts? I did a quick internet search and didn't find any tutorials or documentation regarding shift-click plus drag the color. GIMP official docs: http://docs.gimp.org/2.8/en/gimp-tools.html#gimp-toolbox-areas The shift-click on the new layer button is not documented though, it's only available as a tooltip http://docs.gimp.org/2.8/en/gimp-dialogs-structure.html#gimp-layer-dialog The docs also say that A good way to visualize a GIMP image is as a stack of transparencies: in GIMP terminology, each individual transparency is called a layer. http://docs.gimp.org/2.8/en/gimp-image-combining.html#gimp-concepts-layers I think that makes a reasonable case for a default using transparency and putting the extra options in a second level. As I said earlier, Tobias' proposal allows that keeping discoverability and reducing workflow interruptions. Regarding your question about hard evidence that backs my claim about most of the people expecting layers to be transparent, I don't have it and I don't think a public poll is the best way to get that. I'm a graphic designer like C R, and my workflow is similar. I'm not a photographer, but cutting out and touching up photos is part of my regular work. I use GIMP professionally (which means it is one of the tools I use to do work that pays my bills) so I think I am a target user. You can interview other target users of GIMP and get better results that what you'd get from a poll, and that's exactly what Peter Sikking and his team did a couple of years ago when they interviewed a group of users for input on their usage patterns. If you put a poll in a public website you will receive answers from everyone, not just from the target users. That will result in useless data. Imagine that you get 20 replies from people who hardly uses GIMP and are just hobbists who need to remove red eyes from point and shoot photos and 2 replies from serious photographers with high-end requirements. I wouldn't like that decisions on usability are done that way. For the same reason some automated statistics won't necessarily throw what target users prefer or need. Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Create New Layer Button
El vie, 03-04-2015 a las 20:36 +0100, C R escribió: Not to be a pain, but if you have a selection already (that you want to keep), clicking and dragging a colour fills the selection, which is not the same as making a new layer with foreground/background, or white. If I'm outvoted on the issue though, I will simply change my workflow. The hotkeys for fill with fg and bg are useful. Also don't forget the x key, which swaps foreground and background colours (I use this a lot when painting masks). The d key changes the fg and bg colours to black and white (d for default) as well. This is the same in Photoshop. That's a good point, but may I ask how often do you have to create a new solid layer while keeping a selection? I can think about a few cases, and not really critic ones since the creation of the new solid doesn't depend on the selection. Anyway, I don't think anyone is asking to remove the extra options from the layer dialog. I think it's rather about making it less invasive. Gez ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Create New Layer Button
El sáb, 28-03-2015 a las 20:31 +0100, Michael Schumacher escribió: On 03/28/2015 07:54 PM, Gez wrote: I'm baffled to learn that the default used to be creating a new transparent layer but it was changed back because people didn't find it, pretty much the same way they are not finding that alt+click creates a new transparent layer now. It is Shift+Click, and it doesn't create a transparent layer, but one with the default values or last values used in the dialog. Is it really a good idea to pop up in front of every user face a complex dialog just because some other users are lazy enough to not read the documentation, the tooltips or the status bar not even once? Um... Haha, double fail! Even though I mixed up the keystroke (which I do use everyday, but my memory betrayed me at the moment of writing it down) and described its function wrong, the question remains. Popping up that dialog with several options is usually NOT what the user needs, and it interrupts the workflow a bit. My point was that, if it's done for the sake of discoverability, the existence of a tooltip listing the alternate functions with modifier keys should be enough. I have the habit of checking the tooltips and status bar everytime I use a new tool, and when I teach other people to use GIMP and other free software packages I always point them to check there for hints about how to use each tool. As I said before, I'm not even interested in having this changed. It's the argument of discoverability something that I find arguable. That being said, I think Tobias' idea is a good solution which provides both an uninterrupted workflow and an easily discoverable set of alternate functions. Gez ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Create New Layer Button
El sáb, 28-03-2015 a las 05:28 -0400, Elle Stone escribió: On 03/27/2015 10:45 PM, Gez wrote: It seems reasonable to require an extra click for committing extra options and having the most commonly used option accessed quickly, without interruptions to the workflow. What's the most commonly used option for a new layer varies from user to user. When I make a new layer, almost always it's either the foreground color or white. Sure. I'm not claiming that everyone uses tools like GIMP the same way. But I'm pretty sure that if there were some statistics about what people need the most when creating a new layer it would be a transparent layer, since it doesn't occlude the underlaying layers. Furthermore, creating a new empty layer and then dragging the foreground or background color from the toolbar swatch to the image takes exactly the same time and effort (maybe less) than selecting the same option in the current dialog. But again, since not everyone uses GIMP the same way, it is impossible to come up with something that makes everyone happy. That's when a good interface designer should design the best possible solution which of course won't make everyone happy but maybe will make the target users of the program more productive. Unfortunately, a solution that covers I don't read tooltips or manuals, it's easy to find, it doesn't clutter the UI with millions of options, it makes advanced users happy, etc. is plain impossible. I'm baffled to learn that the default used to be creating a new transparent layer but it was changed back because people didn't find it, pretty much the same way they are not finding that alt+click creates a new transparent layer now. It's a good thing that features are easily discoverable, but as you said, when a program becomes more complex it's not always possible to keep everything at hand. That's when hints like tooltips and text in the status bar come in, and I don't think it's a bad thing to use them. Is it really a good idea to pop up in front of every user face a complex dialog just because some other users are lazy enough to not read the documentation, the tooltips or the status bar not even once? Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gimp-user] Time to fork BABL and GEGL
El mar, 18-11-2014 a las 00:32 +, Ed . escribió: Elle, If you don't understand the difference between a design detail, and an implementation detail, you need to either a) go away and get to understand that difference; or b) stop commenting. I am neutral as to which you choose. Ed Are you the same Ed. who wanted to ease communication between Elle and pippin? If not, plase give us back the old Ed. we liked him better. You seem a tad biased for someone who admittedly doesn't understand the issue being discussed. Do you really think that asking someone to STFU helps here? Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gimp-user] Time to fork BABL and GEGL
El lun, 17-11-2014 a las 23:41 +0100, Mikael Magnusson escribió: The above two things are implementation details as Simon said. If you don't understand this, then please don't write long articles full of misinformation that get widely quoted. Your answers suggest you didn't even understand what he said. Your argument is like saying it matters if you store an integer in decimal or binary, and doing anything else than the user input is definitely wrong, because there is no longer any way to display it in this format. Gegl stores pixels in memory in some format, it knows what format it used. Gimp can display/edit pixels in some color space (specified by the user). Gimp asks Gegl for pixels saying what colorspace it wants. Gegl presents the pixels to Gimp. All is well. It doesn't matter how the pixels are stored. I think I have at this point a reasonable grasp of what's the plan here and that unbounded sRGB is intended a just one representation of the many possible with babl (and that its primary function is to be used as a PCS)- I also understand that chromaticity dependent operations will use userRGB. However, and this is what Elle is asking and nobody seems to understand, the question is if bablRGB is still going to be used as the RGB space for all the chromaticity independent operations and if that's a yes, then WHY. Is it just to spare one single matrix transform in case the buffer is not available in userRGB? And yes, jonnor said something that seems to contradict pippin if that's the case: in the future RGB operations that now ask for bablRGB should ask for userRGB instead. That of course doesn't take bablRGB out of the picture (it would still would be used as PCS), but means specifically that operations won't be fed anymore with unbounded sRGB but user defined RGB. When Elle says converting to unbounded sRGB, she's referring to what babl will do when an operation requests for bablRGB. (We know it's not a forced conversion at the beginning of the pipe, and the GEGL tree can keep different representations for the buffer). If chromaticity independent RGB operations request for bablRGB or userRGB doesn't seem a mere implementation detail. I think it's a valid question to ask why requesting for bablRGB when the mechanism for userRGB will be available. Could you please address that question with a straight answer? Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gimp-user] Time to fork BABL and GEGL
El lun, 17-11-2014 a las 21:19 -0500, Michael Henning escribió: On Mon, Nov 17, 2014 at 8:48 PM, Gez lis...@ohweb.com.ar wrote: If chromaticity independent RGB operations request for bablRGB or userRGB doesn't seem a mere implementation detail. I think it's a valid question to ask why requesting for bablRGB when the mechanism for userRGB will be available. Could you please address that question with a straight answer? It's very likely that the processing will happen in userRGB for performance reasons. Nobody wants to give you a straight answer because to be honest, we don't know for sure. We could change our mind at any point in the future, and you wouldn't know without reading the code. It doesn't matter what space they happen in because chromaticity independent operations, by definition, do not care which of the spaces we pass them. If we do find a compelling reason to have those operations happen in bablRGB (performance or numerical stability, for example), then we reserve the right to do those operations in bablRGB. And if we do, then nobody will ever know the difference, other than the whopping three people that will ever read that section of the gegl code. Now, please explain this to me with a straight answer: Why is it so insanely important to know what color space an operation happens in, in a situation where it *by definition* does not matter, that you are willing to waste hours of your time and hours of developers' time arguing about it? Sure. My main concern is performance. It doesn't seem likely that flip-flopping between pixel formats can be more performant than just tossing the user RGB to operations. It's already necessary for chromaticity dependent operations, so why not just using it for EVERY RGB operation? There are benefits: The channel data is always in the range the users expects, color pickers pick the data the user expects, and that requires exactly zero conversions. Please note that my question was related ONLY to what RGB operations take and give. If you have a compelling reason to keep an extra representation (bablRGB) as PCS for converting to other color models and give me channels for my processing needs, great. But is there a compelling reason to change RGB from the RGB users choose to something else? Gez. P.s.: If you think this discussion is a waste of your time and my time, feel free to skip an answer. I don't think it's a waste of time at all, it's developer/user interaction regarding important aspects of the tool. Do you really think that discussing this is counterproductive? ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Transform tools usability problem
El sáb, 19-07-2014 a las 00:47 -0300, Gez escribió: I even raised again the issue a couple of days ago on the IRC channel because at some point the ability to turn off the layer visibility while using the transform tool was lost (It's back). ...It's not back. I just noticed that if the layer visibility is turned off after invoking the transform tool, the transformation can't be commited (applying the transform results in the unmodified layer). I'm not sure why this has changed, but it's a step backwards. Now the workaround of turning off the layer visibility can only be used if the layer is turned on again before commiting the transform, otherwise nothing happens. And visibility of the layer can only be turned off after the transform tool is invoked, if the layer is not visible the transform tool does nothing (this is a reasonable behavior, a layer with the visibility turned off shouldn't be affected). I'm not saying that the new behavior doesn't make sense in the big picture, but until there's a method for temporarily hiding the original layer when it's transformed the changes introduced prevent users from using the only possible workaround when the original gets in the middle. Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Transform tools usability problem
El vie, 18-07-2014 a las 15:34 +0200, Przemyslaw Golab escribió: Hello :) I would like to expose one very annoying work-flow problem with transform tools. When you edit your region with transform tools the previous state of pixels is displayed at the same time with newly transformed ones. It often gets in a way of my transforms, it makes hard to evaluate if new transformation is correct because old one covers region that I would like to, for example, see exposed. I feel you... As Alexandre said, it was discussed before. I even raised again the issue a couple of days ago on the IRC channel because at some point the ability to turn off the layer visibility while using the transform tool was lost (It's back). This has been one of my pet-peeves with GIMP when using the transform tools since I started using it, and although sometimes it comes handy to have a reference of the original layer when transforming, most of the times it gets in the middle, covering the references you need to perform the transform in context (due to the nature of bitmap editing, it's more common to import large layers and scale them down than importing small layers and scale them up, so the large layer covering the composite is a really common scenario when editing). When I raised this issue on the IRC channel the last time, pippin told me that in a future all the preview hacks of transform tools eventually will go away. That's great, but meanwhile it would be nice if the current hacks are tweaked a little to avoid this annoying problem. I'm not asking for a full-fledged solution, just turning off the visibility of the layer when the transform overlay is drawn and turning it back on when the transform is commited would suffice. Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Getting contributors via OpenHatch
El dom, 01-06-2014 a las 21:49 +0200, Ofnuts escribió: If you include in it the page from LightningIsMyName that it links to, definitely... Call me cynical, but someone that needs really more detailed instructions will likely not have the programming background to be a useful Gimp developer. Of course I expect potential Gimp contributors to be somewhat already-knowledgeable, at least in the basics of Linux application development. Lines have to be drawn somewhere... +1 I'm not a coder, just a user and I could manage to build GIMP from git without too much hassle. Some things may be not exactly obvious, but I want to believe that somebody who intends to contribute in a software project will be at least equiped to compile the thing from sources. If that's supposed to be an entry barrier, I think it's a good one. Gez ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [FEATURE] - Blend mode Truncate
El 2014-04-23 18:10, Joao S. O. Bueno escribió: Maybe this should have even been the proper behavior for Repeat None - but since it can't be changed now, introducing this as a new repeating mode can bring new ways to use the blending tool and GIMP itself. - Comments on this idea anyone? I like the idea, but I don't think that making it the default behavior for Repeat None is a good idea. People are used to the current behavior, that extends the last color. But as an extra option, it would be really useful. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Histograms in unbounded mode sRGB
El 2014-04-22 15:25, yahvuu escribió: Hi, Am 18.04.2014 22:10, schrieb Elle Stone: I think the only reasonable solution is to keep the WideGamutRGB chromaticities available for use as an editing/compositing color space, and use that color space to display histogram information (and also to display Color Picker and Color Selector information). please allow me to make the case for using the color space of the respective export file format for histogram displays. You recently gave striking examples of how working with RGB _numbers_ can quickly become unwieldy from a user point of view. This probably applies as soon as the limitations of the traditional 8-bit sRGB processing are relaxed. There is nothing wrong with RGB color models, it is just that the numbers can become difficult to interpret for human beings. So, as a thought experiment, i'd like to get rid of any kind of RGB triples in the UI. To see where it hurts the most. This will be the places where RGB numbers are really needed. After all, GIMP is about colors, not numbers. Say, we get an adobeRGB camera image and the task is some touch-up and warping. The deliverables are 1) a JPG for the web and 2) a proPhotoRGB file for that mega stock company. I find that most of the editing can be performed without looking at a single RGB triple. Image transforms do not expose RGB numbers, neither do most of the filters. Even many of the tools in the Colors menu do not refer to RGB numbers. Of course, this is different for levels/curves. But by large, these tools are used on the 'value' channel, not on the distinct R,G,B channels. Here, working on the luminance channel instead would probably be an improvement. I find it is only on *export* when the RGB numbers become really important. Much like output-specific scaling and sharpening, each of the deliverables needs specific color treatment. Here, the histograms need to show the R,G,B channels of the specific output color space to allow assessment and correction of the conversion. Probably, this is also where the curves/levels tools should be working in the output color space. For example, how else could someone boost the midtones without adding clipping -- when maximum and minimum range of the curve do not refer to the actual range of the output file format? (not even talking of non-matching color primaries here) These color modifications that are specific to the output files are hot candidates for being stored in export pipelines, again analogous to scaling and sharpening operations. I'm less sure in how far this is an analogy to CMYK export -- is an equivalent to the 'press projection' needed here? Or is it sufficient to set the RGB color space of histogram/curves etc. to the currently active softproofing color space? This is no doubt an interesting thought experiment, but I'm afraid it can't live much beyond it. The way users interact with GIMP is too complex to do something like that. Your example cherry-picks situations where the color part can be left for the final stage, but there are several manipulations where you start by doing some color correction. And since RGB is how digital color images are stored, having tools for watching what's going on in channels while you edit (like histograms, waveforms, etc.) is essential for manipulating color with accuracy. Destroying image data inadvertently is easier than you think, specially when you're manipulating data that doesn't fit in your output device's gamut. And all this things start to sound like squaring the circle. Again, it's an interesting thought experiment, but if we need thought experiments to make a model fit, breaking the existing paradigms of image manipulation, then there's probably something wrong with the model. I'm not against different ways of doing things, but it seems like making the unbounded RGB model fit requires to re-think a lot of the existing structure, not only the internals of GIMP but also how users use the tool. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Some blend modes break in unbounded mode sRGB
El dom, 13-04-2014 a las 00:45 +0200, Øyvind Kolås escribió: On Fri, Apr 11, 2014 at 11:54 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: On 04/09/2014 06:36 PM, Elle Stone wrote: For Lighten only, Darken only, Multiply, Divide, and some of the other blend modes, results are *highly dependent* on the color space in which the blending is done. Removing clipping code doesn't fix the problem. You seem to be under the impression that all processing whatever the operation is done going to happen in one color space/pixel format a working space. In a GEGL processing world; it is the individual operations that have working spaces; there is no global working space that things happen in. (NB: having gamma toggles in blending modes of GIMP is according to this model making things confusing, compositing in different color spaces should be _different_operations_). Does this mean that some operations (a multiply or divide blend, for instance) will be done in another pixel format where out-of-sRGB-gamut values don't necessarily mean out of bounds values (negative or 1, hence problematic for certain operations) in channels? I think that what Elle is asking is about the RGB operations that break with ubounded sRGB chromaticity values. Several operations don't seem to be suitable for chromaticity values beyond the 0,1 range. Gez ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Some blend modes break in unbounded mode sRGB
El vie, 11-04-2014 a las 02:39 +0200, Przemyslaw Golab escribió: Isn't that expected? You don't change color space, for it to have the same results. You choose best color space for the job and use it from beginning to the end, or if you know what you are doing convert it in middle of work to do the thing you want to do. If all color spaces look the same whats the point of using them. Hi Przemyslaw, Unless I got it absolutely wrong, the plan for GIMP 2.10 is to use forced unbounded colorspace conversions to sRGB for the internal pipeline (at least that's what I got from Drawoc's reply to Elle's previous post). So anytime you open a wide gamut image, it will be converted internally to sRGB for all the processing and compositing. Since the unbounded conversion is reversible (unlike the usual icc bounded transforms that are destructive), in theory you could go back to your wide-gamut colorspace with no loss of color latitude upon export (once you're done with processing). What Elle is describing here is a number of operations that don't seem to work with unbounded sRGB (where values can go negative or 1 to express out of gamut colors and keep the excess gamut from the source wide gamut profile). I've repeated Elle's tests and tried my own tests, and I can see that some operations do break. I'm really interested about this issue, because some basic and important math operations seem to have issues with those out-of-bounds values (like multiplication/division). Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Three questions about opening an image and converting it to linear light RGB
El mar, 08-04-2014 a las 09:19 +0300, Ville Sokk escribió: On Mon, Apr 7, 2014 at 4:24 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: I'm still testing the other gimp/app/operations layer blend modes. But probably *all* clamping code should be removed from *all* layer blend modes. Elle's two cents worth I would like to mention that the current blending modes were created to replace the old 8-bit ones. I was told they should be as close as possible to the old ones (so you could open images made with =2.8 in 2.10 and they would look the same). There have been talks about adding blending modes with normal formulas (without clamping and other weird stuff) but this hasn't happened yet. I think people weren't sure how to show both sets of blending modes in the UI. As a user following the development of GIMP, I think it would be far more interesting if the blending modes and operations work correctly and consistently with the new core. I'm aware that keeping legacy compatibility is high in the priorities list, but maybe that can be added later. From what you say, it looks like proper has to wait. It seems more reasonable if it is the other way around. At the moment some legacy compatibility seems to be getting in the middle every time you want to try the new capabilities of the program. Clipping and some blending modes is one of those things, and some confusing bits about editing in linear and gamma precisions too. Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Three questions about opening an image and converting it to linear light RGB
I just noticed that I sent my last two e-mails to Nicolas without forwarding them to the list. I think his replies address these questions, so I'll copy them here. Sorry for the inconvenience. I forgot to hit reply all. El vie, 04-04-2014 a las 08:53 +0200, Nicolas Robidoux escribió: Some operations are made worse if you don't allow out of gamut values (e.g. blacker than black and whiter than white). What do you mean with blacker than black and whiter than white and how those achromatic values can be out of gamut? I get it if you mean that white can go beyond 1.0 (display referred white) in scene referred HDR, but what does blacker than black mean? Negative light? Could you please explain that and give an example of how those values could be produced? The first example that comes to mind is convolutions that are implemented in a separable way and that have negative coefficients. I vaguely remember something about resampling with a transparency channel too (which is done correctly in ImageMagick; there is a thread where I question this and then approve in the ImageMagick forums). I'm not sure if this is exactly what you mean, but I remember from Blender that some of its antialiasing filters created negative values in alpha channels. iirc Blender used to clamp those negative to zero, which was a terrible idea, since in an image with associated alpha those clamped values meant that pixels that needed to be semitransparent became fully transparent. I can't remember if it was fixed (and how) but I do remember that either the negative values or the clamped values in alpha channel introduced compositing artifacts. It looks safer to avoid negatives in convolutions in the first place. So: If your operation is made worse by out of gamut values, clamp them first thing. Sometimes it isn't enough for fixing the problem, and in the context of unbounded gamut I think that clamping means clipping gamut, which defeats the purpose of unbounded gamut. Maybe I'm getting all wrong, so I'd appreciate is somebody clarifies it. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Three questions about opening an image and converting it to linear light RGB
El sáb, 05-04-2014 a las 12:21 +0200, Nicolas Robidoux escribió: It is my very strong opinion that values should not be clamped by default. If you are writing an operation (a node) that is broken by negative or values breaks, do not clamp the input and output without carefully considering the possible impact on the entire toolchain. Very very carefully: Clamping values can have surprising side-effects (as the Blender community apparently discovered through experience). If it is likely that your operation will be fed, for example, negative values, try to write your operation so it does something sensible with them. Clamping should be a last resort. Not even a last resort. Clamping unbounded values will destroy the excess gamut that the unbounded transform is supposed to keep. Blender works in scene referred linear (from 0 to infinity) and clamping is used to restrict the values to the display-referred limits when the user needs it. In Blender chromaticity is never out of bounds (unless you explicitly fed a node with an ilegal value, like a negative value), it's just intensity. For instance, if your red channel goes beyond 1.0 it never means redded than red. We agree: values should not be clamped. My question question (and I think also Elle's question) wasn't about whether those values have to be clamped or not, but about the impact of values beyond the display referred bounds resulting from the forced conversion to unbounded sRGB. Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Soft proofing and the GIMP Display Filters and Color Management settings
in sRGB. Of course you won't notice it if you're doing minor tweaks, but do you think it's worth to keep 8-bit and editing in the source colorspace just because it would take some extra CPU cycles to take it to a larger gamut working space? Thanks for your feedback. I'm not trying to prove who's wrong or right here, just trying to discuss the validity of assumptions we make (mine included, of course). Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Soft proofing and the GIMP Display Filters and Color Management settings
El jue, 13-03-2014 a las 12:53 -0300, Gez escribió: The difference in performance was almost unnoticeable, and for a single layer the difference in memory consumption was around 300 megabytes. Hmm. That's not correct. The difference seems to be much less if you discard the undo information. Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Soft proofing and the GIMP Display Filters and Color Management settings
El jue, 13-03-2014 a las 02:36 -0400, Liam R E Quin escribió: Why? Again, processing in high bit depth, soft-proofing against the target colorspace, saving to the destination bitdepth and profile. Because for 256-colour GIF animations you are forced to care about individual pixel values, and use indexed-mode colour with a fixed palette. (strictly speaking GIF can handle higher bit depths too, but for widest distribution you have to keep it simple). GIMP has the GIMP Animation package to help people make animated GIFs so it has quite a following. If an 8-bpc buffer can be displayed, the it's probably possible to generate an indexed projection on the fly, pretty much like gimp-2.9 does now. Yes, although 8-bit GIF is not 8 bit per channel but 8 bit for all three channels, so you really care about which colours are allocated. Like, a lot. Anyway, we'll see how it turns out. GIF animations of kittens might not actually be in GIMP's primary use case market... Ok, so the problem is indexed images. How does it work now in 2.9? Is it really 8 bpp or is it 8bpc and the projection is converted to indexed? I found these articles (maybe outdated) that seem to imply the latter: https://lwn.net/Articles/497132/ Because GEGL operations are defined on abstract buffers, adding support for an entirely different image format is a matter of writing a new format for babl, the underlying pixel transformation layer. During the GEGL hack-a-thon, Kolås wrote such a back-end for indexed color images (such as you find in the GIF format). Natterer had originally planned to drop support for indexed images, but with the babl format defined, they work just as well as any other format in the GEGL-ified GIMP. GEGL also allows GIMP to use all sorts of painting and filter operations on indexed images (such as smudging and blurring) that are typically not possible on indexed color. http://blog.mmiworks.net/2009/06/gimp-squaring-cmyk-circle.html The core of the solution model is that this projection is again a surface, that can be worked on, to make the corrections that are specific to this indexed set‑up. The non‑destructive nature of GEGL makes it possible to reapply these corrections after more creative development, or to adjust them at a later stage. What I'm saying isn't very different than developers already said: https://mail.gnome.org/archives/gimp-developer-list/2012-August/msg00084.html I'm just presenting a case for a simplified workflow that could cover the same possibilities without a lot of modes and options that could lead to unintended screwups. GIF89a doesn't seem to support embedded ICC profiles, by the way ;) Untagged images for the web are always assumed as sRGB, and I'd say that if you use any other profile you should tag them so CM takes care of the proper color transforms. Untagged images in an unknown colorspace are one of the nasty consequences of an inefficient color workflow that made the hideous command assign profile necessary in the first place. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Soft proofing and the GIMP Display Filters and Color Management settings
El mié, 12-03-2014 a las 17:27 -0400, Elle Stone escribió: On 03/11/2014 02:39 PM, Omari Stephens wrote: Hopefully the printer people will correct me if I'm speaking nonsense here. CMYK printer profiles have four channels because ink produces color subtractively, but not perfectly, as inks are not as narrow pass reflective as one might like. So using C+M+Y to make black produces a muddy black and uses a lot of ink, which is sloppy to print. So the fourth color is black. That's spot on. Another reason is that black ink (carbon based) is cheaper than color inks (and 1 ink pass is cheaper than three pases, and it dries faster). However, because blank ink isn't perfect either, a pure black pass doesn't look deep enough in large areas and will look rather like dark gray than like black, so it's common to add a little C, M and Y to get a rich black. More than four colors of ink gives smoother color reproduction and also may extend the available color gamut, depending on the inks. The corresponding ICC profile is a Lookup Table profile, which basically says r% ink-1 + s% ink-2 + t% ink-3 + u% ink-4 + . . . + z% ink-n (where r, s, t, u, . . . z are arbitrary percentages) equals a particular location in the CIELAB reference color space, for all possible combinations of various percentages of the n available inks. The color profile also contains additional information like black generation, and TAC (Total Area Coverage percentage, a maximum ink coverage recommended for the media used). If you go beyond that value the media will take longer to dry, dot gain could saturate and mud details, etc. In the New GEGL World, converting between different channel layouts is going to be a reality, and we should at least put _some_ thought into what that means for color management. Of course, this is way out of my depth, and I have no idea. I'm also curious as to what gegl n-channel editing might be like. Soft proofing to an n-channel printer is a one use case for n-channel editing, when the goal is to convert to the n-channel ICC profile and tweak the channels while soft proofing. Hopefully again the printer people will correct me if I'm speaking nonsense. Dan Margulis gives examples of image editing in an artificial CMYK matrix color space, requiring four channels. Margulis is a respected name, but I'd take what he says with a grain of salt. The last time I checked he still insisted that doing creative editing in device CMYK is a great idea and that color management failed, something that contradicts the direction of the entire graphic industry for the last 15 years. Would there be a use case for editing in n-space (as opposed to soft proofing to an n-space output profile), where n is greater than 4? If you have to treat one of the CMYK primaries as a spot color, or if you need an extra spot color, then yes. It's indeed useful and a quite common requirement in the print industry. For instance, if you have a color that can't be achieved mixing CMYK inks (saturated greens, oranges, blues, etc.), an extra print pass is used, inking with a specially formulated ink that reproduces the exact color you need. That's what a spot color means. When you want to get red mixing 100% yellow and 100% magenta (and you want that exact combination) you're using both yellow and magenta as they were spot channels. It has nothing to do with CMYK, because you're overriding color management and using an arbitrary mix, not a colorimetric translation. Perhaps this is not a popular point of view, but in my opinion, using CMYK just because you want to tweak channels manually (as if it was possible to predict the printed output of that procedure) is a bad idea. If you want to work on a computer screen and send the output to print, the most reliable way to get the color appearance properly translated is a solid color managed workflow. Spot plates only have to be color corrected for previewing purposes, but they won't be separated in individual channels. They are extra channels, completely separated from the CMYK process colors. The only interaction with the CMYK channels is defining overprinting/knockout. Gez ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Soft proofing and the GIMP Display Filters and Color Management settings
El mié, 12-03-2014 a las 02:19 -0400, Liam R E Quin escribió: On Tue, 2014-03-11 at 15:45 -0300, Gez wrote: Note that the case I mentioned the other day as seeming to be out of scope is when you *are* the print shop, and you (sometimes) receive the cmyk files, or need to edit them. E.g. remove an impression number from the imprint page and then send to imposition... but it seems it's in scope and just not there yet. You're right, there's no free software tool fully capable for that purpose. The Separate+ plugin offers a rudimentary solution for that. The resulting layered composite is far from ideal (ugly would be a better description) but it kind of works. Krita, although has native CMYK mode, it doesn't offer the tools (at least not yet) for that kind of job. Early binding is still here. I can live without it, but of course that it wouldn't be the case if I was a print-shop. I'm curious to know how many print shops would consider using GIMP if it had native CMYK. I suspect that the majority of people ranting about the lack of CMYK are mostly designers who know just one way to send stuff to print shops, not print shops. From a user point of view having all the imported stuff converted automatically to a high quality internal model (high bit depth linear scRGB?) and having per-image output/proof settings seems more straightforward and less error prone than the current mixture of profiles. Are you going to pay for the extra memory I'll need? I only have 32G and already with 2.9 I sometimes am swapping. No, but I can make you some coffee while you wait :-p Ok, good point. I missed the segment of users who work with huge scans completely. On the other hand, is 8-bit enough for the type of work you do? Although I'm still using 8 bpc for my work because I do it with GIMP 2.8, I have a really hard time trying to keep good quality after a few rounds of edits. Maybe defaulting to 32bpc is too resource-intensive for a lot of works, but wouldn't make more sense to have a higher quality default for editing and keeping 8 bpc just as an output bit depth? Anyway, rather than bitdepth, my comment was about giving the artists a framework to create freely without worrying (much) about the constraints of input/output colorspaces. It's impossible to have that with 8 bpc. And correct me if I'm wrong, but I suspect that using proofing filters on non-linear 8bpc carries a lot of problems and the result can't be completely reliable. Maybe we can have the flexibility and power just keeping two modes: 16 bit integer for memory-conservative tasks and 32 bit float for high quality stuff. Economy of system resources is important, but I'm sure that image quality is far more important in a image manipulation program. It may or may not be a problem for keeping legacy compatibility, but I can imagine how simplified the UI and common workflows would be (no bit-depth modes, no assign/convert to profile, no profile-mismatch warnings, simplified CM preferences, etc). You might not always be able to do round-tripping, because a colour in the input image's colour model might be out of gamut for the working profile. I don't know how big an issue that would be. Similarly you'd end up using colours that wouldn't come out at all right on your output device. The warnings are there for a reason... scRGB exceeds the gamut of the usual profiles, following what I proposed in the previous message, if you go -for instance- AdobeRGB - scRGB - AdobeRGB with enough precision that shouldn't be a problem and RGB - CMYK roundrip is impossible anyway. I'm not an expert by any means and I might be wrong, but that doesn't seem to contradict what I said. And regarding you'd end up using colours that wouldn't come out at all right on your output device, that's exactly what soft-proofing (the topic of this thread) would prevent. If you have in the workflow I presented, say an AdobeRGB image as input, it would be converted to scRGB. All its colours would fall inside the scRGB gamut, so no problem. If you save back to AdobeRGB without changing anything, color shouldn't change. If you save to sRGB, colors would have to be converted using a rendering intent, because the output gamut is smaller. You could soft-proof your editing against sRGB to see how colors would be affected with the selected rendering intent. The good thing about this is that your XCF file would store unmodified color information, and that would allow to save later to AdobeRGB, Prophoto or whatever you want. Now, if you were obligated to convert your imported image to a working profile (like you are now), and that profile has a smaller gamut than the original image, your imported image is hopelessly degraded. You're always tied to the color gamut of your working RGB profile. Anyway, this is just an idea. It's not a small change and I'm not suggesting that it has to be done the way I said. I think this is an interesting topic to discuss since seems
Re: [Gimp-developer] Soft proofing and the GIMP Display Filters and Color Management settings
El mié, 12-03-2014 a las 23:35 -0400, Liam R E Quin escribió: [ resending this to the list, at Gez's request :) ] Sorry for the accidental private mail :) Anyway, rather than bitdepth, my comment was about giving the artists a framework to create freely without worrying (much) about the constraints of input/output colorspaces. It's impossible to have that with 8 bpc. And correct me if I'm wrong, but I suspect that using proofing filters on non-linear 8bpc carries a lot of problems and the result can't be completely reliable. No, I think it's probably fine. Most commercial RIPs these days deal with at least 10 and more likely 16bpp. Notice that I'm talking about processing only. The output bitdepth should be the usual for each file format (for instance, although commercial RIPs no longer choke with 16bpc files, it's still recommended to send 8 bit and probably sending more won't make any difference, at least for offset). Maybe we can have the flexibility and power just keeping two modes: 16 bit integer for memory-conservative tasks and 32 bit float for high quality stuff. That would rule out editing GIF animations and also make preparing images for the Web or for use n mobile devices very hard. Why? Again, processing in high bit depth, soft-proofing against the target colorspace, saving to the destination bitdepth and profile. The project file keeps data and color latitude, the exported files are converted to the desired parameters. You can do exactly that with Blender's compositor, and it can save JPGs or PNG for the web. If an 8-bpc buffer can be displayed, the it's probably possible to generate an indexed projection on the fly, pretty much like gimp-2.9 does now. Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Soft proofing and the GIMP Display Filters and Color Management settings
El mar, 11-03-2014 a las 07:16 -0400, Elle Stone escribió: I don't know anything about CMYK printing and I've never used the CM+ plugin, so please bear with me while I ask a couple of questions: Putting *editing* CMYK channels to one side, is it useful to modifythe RGB channels while soft proofing to a CMYK profile (or even n-channel profile whether color or black and white)? I thought that was what the CM+ plugin made possible? Is this an example of what Gez calls late binding? Not exactly, but related. There are three possible workflows for print: Early binding: All the assets are converted to CMYK and editing is done in CMYK. The files you send to the print shop are CMYK. Late Binding: Everything is worked in RGB. The print shop converts to CMYK. Intermediate Binding: Creative work is done in RGB, the files are converted to CMYK prior sending them to the print shop. GIMP can't edit CMYK directly, but it can serve to the other two possible workflows. soft proofing to a CMYK profile is useful because you can work in RGB with all the freedom it allows, but at the same time you can preview how the target gamut and rendering intent will affect your image. I think this is specially useful when using colorimetric intents, where all the out-of-gamut values get clamped. CM+ allowed that. Iirc, it did more or less the same than the current color proof filter with some extra goodies (individual CMYK channels preview, black ink/paper white simulation, etc.) Check this video from 1:40 https://www.youtube.com/watch?v=Q99MeymK7wAfeature=youtu.behd=1 (if you can endure the disturbing music, it shows the filter in action). Having the title/status bar(s) show which display filters are active would be very useful, especially given that if you close the display filter window, any activated filters (or deactivated, in the case of the Color Management filter) are still applied to the image. That would be an interesting addition, but I wonder if the current model of having multiple working profiles can't be replaced by something more useful. This is probably off-topic, but having to worry about the file profile, a working profile, a print preview profile and a print profile in the preferences as global settings seems messy and inefficient. And in GIMP 2.9 it probably doesn't make so much sense as it used to. From a user point of view having all the imported stuff converted automatically to a high quality internal model (high bit depth linear scRGB?) and having per-image output/proof settings seems more straightforward and less error prone than the current mixture of profiles. It may or may not be a problem for keeping legacy compatibility, but I can imagine how simplified the UI and common workflows would be (no bit-depth modes, no assign/convert to profile, no profile-mismatch warnings, simplified CM preferences, etc). Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] GIMP: IDEA FOR BLENDING LAYER
El dom, 16-02-2014 a las 19:40 +0100, TheSoftware Makers escribió: I am looking for a blending layer that allows you to apply the color dodge effect. I was looking for the effect shown in step two: http://abduzeedo.com/lens-flare-revisited-pixelmator. I can't follow the instructions because I don't find color dodge in GIMP. Do you have any ideas? Nick, As Bill mentioned, GIMP has a dodge blending mode, and apparently it does the same than color dodge does in Pixelmator. However, keep in mind that for this kind of effects, blending is better done in linear space (I bet pixelmator works that way). Also, working in 8 bit per channel can limit the quality of the blending, so working in higher bit depth is advised. GIMP 2.9 (the development version) allows both working in high bit depth and linear space, but current stable version doesn't. This is a simple test showing the result of a dodge blending applied in 32bpc linear float: https://dl.dropboxusercontent.com/u/255376/gimp/dodge-blending-linear.png Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Remove you can drop dockable dialogs here label?
On Sat, 2014-02-15 at 04:09 -0500, Sam Gleske wrote: Hide the drop icon (as it is currently mocked) completely until user mouses over the area. Regular users who don't populate that area don't necessarily need to see a drop area but new users can still discover it if they accidentally mouse over it. With the assumption that they accidentally removed the docs of course. I'm not sure about this. The problem is the one on the right, isn't it? First, we have to keep in mind that there are two possible situations: single window mode and floating windows. The drop target I mocked on the right is intended for single window mode only. It wouldn't make sense with floating windows because you can't dock dialogs in the image window when you're using that mode. Also hiding and showing the drop target on mouse over would require to reserve the area or making it pop up anytime you hover, and that would be very annoying at any rate. I think the drop target on the right should be displayed only when there is no image open and no docked dialogs. The drop target on the left is part of the toolbox window in window mode, so it's a little bit different. It can be showed always (when there is no dialog docked, of course) both in single and multi window modes. El sáb, 15-02-2014 a las 10:24 +0100, Liam R E Quin escribió: Having a pop-up menu when you click on the button, with restore recently removed docks and add dockable dialogue would help even more. I agree it would be useful, but we have to think about how to display and hint a widget that it's both a drop target and a button. In my first mockup it looked like a button, as Alexandre pointed out. That would fit with this idea of adding two options, but it would probably hide from users that they can drop dialogs there. ...Unless both are present, a button and a drop target. Any idea about how to communicate that without getting the text back in the drop target? There's also the problem with single-window/multi-window modes. Anyway, this is only brainstorming. I'm sure our GUI expert will have better ideas about how to solve this. :-) Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Remove you can drop dockable dialogs here label?
El vie, 14-02-2014 a las 19:03 +0400, Alexandre Prokoudine escribió: On Fri, Feb 14, 2014 at 6:52 PM, Gez wrote: https://dl.dropboxusercontent.com/u/255376/gimp/GIMP-drop-icon.png In general, I like the idea, but there's an obvious usability problem here: this icon looks like a button, and the first thing one group of people will try to do is to click it. Needless to say, they will fail. Another group of people will decide that this is an inactive button and that they should do something to activate it, which is, again, unapplicable to this case. Hmm, that's a very good point. What about this? https://dl.dropboxusercontent.com/u/255376/gimp/GIMP-drop-icon_b.png My educated guess is that only a fraction of users will read the tooltip and act accordingly. I'd love to be proven wrong, though :) Yes, unfortunately I think you're right. That's why I included in this mockup one target on the right side of the window. The flashing edges are quite discoverable when you already have a dock there, but there is no visual hint in the empty window that you can actually drop the dialogs there. Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Gimp on Steam
El lun, 10-02-2014 a las 13:57 -0500, Sam Gleske escribió: Also, Steam allows DRM free packages (i.e. you install via steam but you can take the software out of steam and run it without steam even if steam is not installed or running). So I think no modification would be required from a developers perspective. It would just require the headache of a packager. Ok, let's see if I can redeem myself after the pointless noise I generated yesterday with a decent question :-) What about the source code? Does the Steam platform provide a way to distribute the sources of GIMP? Does a link to the sources in the description (pointing to gimp.org downloads section) suffice to comply the GPL requirements? Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Gimp on Steam
El dom, 09-02-2014 a las 17:53 +0100, Michael Schumacher escribió: On 09.02.2014 16:24, Gez wrote: As far as I know, Steam is a Debian derivative. Technically Debian packages should work, so no extra work should be needed since Debian is pretty much up to date with GIMP (at least on testing, I'm not sure what Steam uses). Do not confuse Steam with SteamOS, the operating system. Oh, you're right! It was about Steam the distribution channel, not about packaging for SteamOS. For some reason I thought it was about building for SteamOS. I was completely mistaken. Sorry for the noise. Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Search Action dialog feature
El vie, 17-01-2014 a las 01:05 -0500, Liam R E Quin escribió: There used to be a recently used menu from Filters (actually there still is, but it doesn't list filters implemented in GEGL in 2.9; I expect this will get fixed and I should check there's a bug for it) A useful enhancement would for Recently Used Filters to be remembered between sessions. Yes, I know and I use the recently used section of the filters menu a lot (on the stable version), it's very convenient. I meant improvements on that area, like the one you mentioned (remembering recent filters between sessions) or maybe a section for the filters that are used more frequently, not just the immediate recent ones. I don't think that precludes a search function for other things. Some things I always have trouble finding include . text to path This is a good example because it's something I never use so I didn't know where to find it. But using the same logic I'd use with any other coomand I found it in the first try: right click on text (both on the text on canvas and on the thumbnail icon in the layers dialog). . save channel to file I agree on this one. But it seems more a workflow problem than discoverability. Channels manipulation is in my opinion one of GIMP's weakest points. . crop to selection (hint: it's not under Edit or Layers) Crop affects the entire image, so the command seems well placed where it is. Can you find delete undo history? (hint: it's not under Edit) Never had problems with this one, I have the undo history window docked and there's a pretty obvious icon for that. And the undo history window can be invoked from the edit menu, so your hint isn't exactly correct :-) The bindings aren't logical to everyone and never will be, as there are too many of them. Sure. Don't get me wrong, I'm not saying that all of them are obvious for every user out there. But I think that in general terms, the placement of commands follows some logic. Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] GIMP System Requirements
El 23/10/13 20:57, Robert Krawitz escribió: The problem -- and this is more so with GIMP than with many apps -- is that it really comes down to what you want to do and your level of patience. If you're using it on web images (maybe 1 MP or less), you're not doing anything fancy, and you're running a light weight desktop, particularly on an older distribution, you might be perfectly happy with 256 MB of memory and a Pentium 3 processor. If you're working on multi-layer 50 megapixel images, and you're doing a lot of transforms, you might find even 8 GB unpleasant. I agree with Robert's comment. I use GIMP for my everyday graphic design job, and I think that something around 4 GB of RAM is generally enough for most of the simple tasks needed (cutting out images, doing simple comps, banners, color correction, etc), even in 20 or 30 MP images. However it's true that such amount of memory falls short pretty quickly when you start working on complex compositions with several layers, masks and large images. I use all the 8GB of RAM available in this box pretty frequently, so it's hard to tell how much memory is enough. It depends on the work you'll be doing. If a general, non-specialized user asks me about how much memory is fine, I'd say something between 2 and 4 GB should be enough. But if you're an artist or a designer, then I'd say the sky is the limit :-) As much RAM as you and your motherboard can afford is the right amount. Gez ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Next minor release?
El 04/10/13 05:12, Jehan Pagès escribió: It was the reason of why italic/bold could not be simulated anymore in 2.8.6 for Windows. https://bugzilla.gnome.org/show_bug.cgi?id=708110 In my oppinion, that's not a bug, it's an improvement.:-) Bold and Italics variants should be designed specifically and not simulated. If the font family doesn't provide such variants, it's better to leave it as is and use only the available ones, for the sake of typographic quality. This is an example to follow: http://tavmjong.free.fr/blog/?p=822 Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] layer multi-select
El 04/10/13 14:57, Matthew Smith escribió: Hello I am going to make an effort to get a layer multi-select going. In this email I will outline what I hope to achieve and I am asking what would be the most effective way to go about submitting a patch that could get accepted. IANAD ;) but wouldn't be better to make this in the gtk3-port branch? I'm not sure if it's worth to work on anything related to widgets using gtk2, considering that the port to gtk3 is planned for the next release after 2.10. Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] wgo, model releases, and cc licensing
El 27/09/13 19:01, Pat David escribió: All, I had an interesting discussion today in IRC I'm summarizing here in order to clarify some sticky points. I had recently pushed a new tutorial that included an image I took of a friend. Michael had concerns about the use of this image and the cc-by-sa license I was applying to the entire work. Mainly, did I have a model release for the woman in the photograph (I thought I did, but didn't apparently). IANAL, but I think the rule of thumb for CC is that you should have all the requirements for a traditional copyright covered first. If you hold the copyright, then you're entitled to re-license your stuff with more permissive licenses like Creative Commons. But first make sure you have ALL the legal requirements for copyright covered. A portrait and most of the photos showing people faces require a model release if you want to present them as *your* work and protect them with a copyright. In most countries (if not all) the copyright and similar intellectual property rights preceed any other right, so if you want to share (via PD or CC licencese) you have to legally own the stuff. If you took images published under permissive licenses (PD or CC) for your work, you shouldn't worry. The model release and the ownership are responsability of whoever publised the images under those licenses. In that case you only have to honor the conditions of the published license. Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Designs made using Gimp
El 09/09/13 14:06, Michael Schumacher escribió: On 09.09.2013 18:41, Mahavisnujana Ochoa wrote: [a wall of urls] This is a good way to get into many spam filters. I'd suggest to - put those onto some image posting, like e.g. flickr, deviantart - paste a link to the collection, instead of all the single items - write aome explanatory text in the mail And I'd add that a development mailing list isn't the best place to post your portfolio of things made with GIMP. There are forums, a user mailing list and other places for that. Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] non-destructive editing and adjustment layers
El 01/09/13 17:22, kcle...@users.sourceforge.net escribió: Okay. so do you mean that any non-GEGL plugins or filters should be treated as not 32-bit compatible and is therefore capable of silently clipping data? What Alexandre is saying is that you won't have to worry about it when 2.10 is out, because that version won't be released until the rest of the legacy stuff is ported to GEGL. Due to the lack of manpower, using developers time to address something that is only relevant during development is a waste of time and efforts. If you're using 2.9 you should know that you are using a development version and things aren't ready yet. You asked and your answers were replied. You have a list of plugins that aren't ported to GEGL yet, you know the effect, you know how to tell if they are/aren't ported and you know that the legacy plugins won't stay like that whenever GIMP 2.10 is released. Do you still think developers should use their time to code warnings about it? Gez P.s.: This thread has been quite informative though. Anyone new to this development version will have a nice summary in the mailing list archives. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] Open Source PSD Library
I bumped with news about a new open source library for opening and writing PSD files. http://layervault.tumblr.com/post/56891876898/psd-rb?utm_content=buffer76c92utm_source=bufferutm_medium=twitterutm_campaign=Buffer It's a Ruby library, which probably makes it not directly useful for GIMP, but I guess it could be helpful for the student who's working on improved PSD handling in this year's GSoC (apparently the PSD format is really messy). The library is released under the MIT license Cheers, Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp Export Properties Not Preserved
El 20/07/13 13:59, Jason Simanek escribió: You shouldn't have to press load defaults. Defaults should be used automatically each time you export. Since I am opening several different images, altering them and then exporting, I have to click Load Defaults for each one. The settings that initially show up seem to vary. Maybe they are somehow derived from qualities of the image file? Ahh, yes. Sorry, I forgot to mention. GIMP attempts to keep the best quality and don't screw the jpg files with a quality setting lower than the original. So, if your jpg had a quality factor of 95 and your new default is 93, it will use file's quality despite the default. If your file had a quality factor of 90, it will use the default of 93. That made sense when save and export where the same thing. Actually, it was me who reported the issue of GIMP destroying jpegs inadvertently (default quality setting used to be 85 with the most aggressive chroma subsampling, so overwriting a high quality jpg with such crappy settings was a catastrophe). I wonder if that feature is needed now that save and export are separated and we have a more reasonable factory default for jpg. I'm not entirely sure it should be removed, though. It's still useful to know if the original jpg had a higher quality setting than our default. How many of [the images] do you process at a time to make a batch save/export feature necessary? And if the number is high enough, is it really wise to work with so many unsaved files at once? Could you please describe your workflow and what kind of things you do with GIMP that would make batch save/export useful? Mostly it's for some kind of web gallery or a series of photos for printed layouts (magazines). Example #1 Website for a Diaper Cake maker (decorative cakes made out of baby diapers and other baby-stuff. Gifts for parents with newborn babies.) The owner has photographed 30 product examples. Each image needs to be scaled and cropped to a certain format so they all match. I don't really want to create a separate XCF file for all of these images and the custom scaling and cropping that I do is not of use for any other output. I just want to open them up, do whatever to each one and then export them all to the same location with the same settings. And move on. I see. And I understand why you need batch exporting. GIMP in its current shape doesn't seem to be the most appropriate tool for that kind of work. Now the question is (I'd like to know what developers and GUI team think) if GIMP should be tweaked for making that kind of workflows easier. The infamous save/export separation certainly made this kind of stuff a bit harder. In my oppinion (probably because my workflow was improved by the change instead of being impeded) you should try alternative tools for that work. Darktable seems to be an excellent choice for batch processing and judging by the example you just mentioned, I think it will fit to your needs perfectly. I guess you want to do it with GIMP anyway. In that case, since I'm just a user as you, I think you should ask our devs and gui expert if they have some workflow change in their plans to facilitate that kind of tasks. Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp Export Properties Not Preserved
El 18/07/13 00:27, Jason Simanek escribió: Hi, Is there any way to set default JPG/PNG/whatever export settings? I am manipulating a lot of images right now and every JPG export involves changing the Quality, the Smoothing and the DCT method. Over and over and over. This happens with Export as well as using the Save for Web plugin (which really should have a way to specify defaults). Jason: When you export (as jpg, for instance) you have a dialog with advanced options and two buttons: save and load defaults. Just save a new default with the settings you want and it will be used next time you export. Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp Export Properties Not Preserved
El 18/07/13 10:28, Jason Simanek escribió: Hi, On 07/18/2013 01:05 AM, Guillermo Espertino (Gez) wrote: Just save a new default with the settings you want and it will be used next time you export. Well, now I feel dumb. Thanks Gez! This certainly fulfills my need, but I find it odd that the only way to alter that setting is from within the export/save dialog. But it's there at least. No need to feel dumb. I guess it's true that those buttons are not in the first place one would look. However, I think it's a smart place to put them: Usually you realize the default is not suitable for your needs while you're changing the output options over and over again (pretty much what happened to you), so being able to save a new default from those settings comes quite handy. Apart from that, I think that having those options in the export dialog keeps us from having a too crowded preferences dialog, which is also a good thing. In my oppinion, it's a reasonable compromise. I still think the Save All Open Files feature would be cool, though. Indeed. But again, for avoiding menus unnecessarily long and overcrowded, that has to be implemented in a smart way. Probably it could be an option for the close all dialog instead of an independent command in the file menu. And that would be only for saving, not exporting. Opening several files and exporting/overwriting them all is probably too specific and should be implemented with a plugin, not to GIMP itself. Batch processing and export aren't kind the things I'd do with GIMP (basically because it lacks the tools for that at the moment, I'd use Phatch or even darktable for things like that) so, until GIMP has a user-friendly macro system, I don't think batch exporting is essential. I mean, GIMP seems to be more oriented to complex manipulations rather than taking several images and apply repetitive tasks to them, and I don't think it's wise to work on several complex manipulations simultaneously without saving, to make save/export all necessary :-) Of course, this is just an oppinion and I'm not saying your workflow is wrong. Just I think that needing that feature is probably something constrained to a specific workflow. Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] [Feature Request] Enhance the operation of the 'Create from Clipboard' method
El 12/07/13 18:39, Sylae Corell escribió: Hello everyone, So, I regularly use the Create from Clipboard feature to make quick edits, especially from images grabbed off the web. However, I'm often an imbecile and accidentally click copy image location instead of copy image in my browser. Would it be possible, if the clipboard data is not an image, have gimp detect that a text url is there and prompt to download it? Thanks for helping make this program, guys. It's one of the jewels of Open-Source :) Sylae: You can use File Open Location to open image URLs. Anyway, I guess it would be nice to have the feature you describe. The functionality for opening URLs is already there, so the only thing needed would be to detect if the text string in the clipboard is actually an url of an image, and then trigger the existing procedure for opening files from urls. Sounds like something useful. Gez ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] So, I got a part-time writing gig...
El 30/05/13 10:52, Pat David escribió: Hi guys, Not sure about the best place for this, so figured I would talk to this list about it. I recently became a part-time writer for PetaPixel.com (photography-centric site). They do a fair amount of traffic with photographers, and as a long-time F/OSS user, I figured it might be a good opportunity to mention/share/promote the cause. Hi Pat, These are great news. As you said, it's a great opportunity to get extra exposure, but I'd like to add a couple of comments regarding the way of exposing our tools. I figure more exposure certainly can't hurt, and if it can be done in a context where our F/OSS tools are spoken about in a manner that considers them as on par or better than commercial offerings, even better. Be careful when you describe our tools. Try to do it in a honest, objective manner. Sometimes we, as long time users and advocates of free software tend to make some mistakes, like overstating some advantages and hiding some disadvantages our software has. I would avoid using stuff like on par or better than because it often calls for a flame war and we don't want that. Also (I'm not sure if this applies to you, but still) the more we use free software, the less we use the other software. And it's easy to miss new stuff when you're not using that software anymore and it might happen that the comparison isn't accurate enough. I love GIMP, I've been using it as my only image manipulation program for the last 6 or 7 years, and I have my reasons to use it, but I have to remember myself all the time (when talking to friends and colleages) that some things I find convenient or even great maybe aren't a big deal for other people, and things I got used to ignore/endure/workaround ARE a big deal for other people (high bit depth editing, non-destructive layer styles and adjustments, for instance). I'm not sure if it is a good idea to mention that those annoyances will be fixed anytime soon (most of the historical issues are being addressed in the current development version and the rest are part of the roadmap for the next versions). The hard fact is that the current stable version of GIMP still has some limitations that can constrain the artistic freedom of a high end photographer. Of course you and me and several other GIMP users have learned to use some workarounds and minimize the impact of those limitations but it's a good idea to keep in mind that some of our workarounds can be deal breakers for other users with high productivity in mind. So, my advise is: stay true. Curb your enthusiasm and try to focus on the stuff that GIMP can do well. Don't get me wrong. As I mentioned before, I love your tutorials because you do show a professional-grade usage of GIMP. You know your trade and I'm sure you'll do a great job, just please be very careful with the choice of words and comparisons. So, if anyone would like to see something in particular worked into an article, either a feature or technique, that I can write against something a bit broader in the photography world, I'd love to hear it! I'll do what I can to raise awareness, even if only small steps at a time. I think the kind of stuff you show in your tutorials is good. I can't think of a specific subject right now, but I guess that any photo-related procedure explained in the way you do in your blog will be fine. Cheers, Gez. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] GIMP - Installed language!
El 19/05/13 07:46, Michael Schumacher escribió: On 19.05.2013 12:36, Mirella Istrate wrote: Just a stupid question: WHY I cannot install GIMP in my preferred language (English)??? I live in this moment in Switzerland and it is impossible to install other as German language!!! You can choose the language used during the install - English is available there, as well as some others, more translations are welcome - and you can change the language of the GIMP UI in the preferences. Michael: That's true for Windows (I don't know if that applies to Mac too), but language can't be chosen during install in linux and GIMP will default to the system's language. However, as you said, it's easy to change it using the preferences. @Mirella: Are you using GIMP 2.8.x, right? ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Adobe software issues
El 08/05/13 09:26, Elle Stone escribió: This isn't a direct reply to your question, as you are asking whether Gimp itself can or will handle raw processing and I'm not sure when/whether the Gimp developers intend to go that direction. But there are two alternative approaches already being used by many people who use Gimp: First, at least two open source raw processors have plugins to allow use with Gimp: http://photivo.org/photivo/download_and_setup/gimp http://ufraw.sourceforge.net/Install.html Second, Raw Therapee (and no doubt most other open source raw processors) allow the possibility of setting things up so that the processed image is automatically sent to Gimp: http://www.rawtherapee.com/ Almost all raw processors (proprietary and open source) use dcraw to decode (but not to process) the raw images. So when dcraw adds support for a new camera, the various raw processors also update their code, usually very quickly in git/subversion/etc, more slowly in terms of an actual new release. If you need immediate support for a new camera that is not yet supported by your chosen raw processor, dcraw (command line) can be used to process the image (it's easier than you might think, even if you don't usually use the command line). Even if a new camera isn't yet supported officially by dcraw, usually you can decode it using the -o 0 option to output raw color, in which case you would need to create and apply a custom camera input profile. The list of currently supported cameras is here: http://www.cybercom.net/~dcoffin/dcraw/ and if you read the faqs (same page), you'll find suggestions for getting a new camera supported more quickly than might happen if you just wait until the camera winds its way through the usual channels. The default ACR settings result in an image that has been made prettier by application of a default black point, added contrast, an S-curve, and some saturation, sharpening, noise removal, etc. The open source gui raw processors (UFRaw, Photivo, RawTherapee, etc) all have their own default prettier settings, but you probably would want to experiment to find the settings that are prettier to you. dcraw is a pure raw processor, that is, it doesn't do any prettifying post-interpolation image processing, so the results will look flat until you add your own curves, saturation, etc. Kind regards, Elle Stone I'd add Darktable (www.dartable.org) to the list. It's awesome although it's not available for windows, just Linux and OSX. The aforementioned programs are specialized tools for RAW processing and can be used in conjunction with GIMP, pretty much like Adobe Photoshop uses Adobe Camera Raw as a gateway instead of offering tools for processing RAW directly in Photoshop. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp gradients
El 11/03/13 11:20, Alexandre Prokoudine escribió: In a nutshell, and that's my personal view, the gradient editing should happen on canvas, much like in Inkscape (0.49 also places numerical input for colors stops position on the tools settings toolbar). And in GEGL-based GIMP a gradient fill should be re-editable. That was my point in my first reply. The tool itself could be extended in the future and the current limitations in gradient editor aren't that critical to justify an overhaul (at least not now). This is also my personal view as a user, but I can live with the current tool waiting for a more flexible, non destructive on-canvas tool. Gez. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] GIMP - flesh out a way of allowing lazy rendering?
El 04/03/13 11:24, Joao S. O. Bueno escribió: [snip] So, we might as well start fleshing out what would be needed to get lazy rendering done, just to get it clearer for everyone, and maybe have one or more of the steps needed for that as Summer of Code projects. +1000! While I was reading the previous thread I was wondering how much performance can be achieved with optimizations, and how far is GIMP 2.9 from a reasonable speed according today's standards. As Joao said, even boosting the speed by 300% we're still far behind the performance one would expect from a tool like GIMP. Maybe it's time to apply all the cheats available to make GIMP fast. Work with scaled down proxies when the view is at 100%, constrain the feedback of filters to the visible region of the image, and do everything else in the background. I know this issue has been brought to the table a couple of times in the last years. The answer was always that GEGL would provide the mechanisms to do that, but today, with GEGL, GIMP is effectively slower. Considering the current performance in GIMP 2.9, this should be a top priority task, because honestly, without a reasonable performance all the work done may seem useless to the eyes of the user. Of course it's not useless and it is much appreciated :-) Gez. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] GIMP - flesh out a way of allowing lazy rendering?
El 04/03/13 11:24, Joao S. O. Bueno escribió: possibly even clipped to 8bpp with dumb acelerated 8bpp GEGL operators and no conversion needed Here I don't agree. In my opinion 8bpc should be only available for file I/O. I wouldn't mind even if it's removed from the precision menu :D Gez ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Change Request: Redesign the Color Balance UI
El 10/02/13 15:57, Alexandre Prokoudine escribió: On Sun, Feb 10, 2013 at 10:36 PM, Timo Witte wrote: I used Color Balance a lot recently. And i want to propose a redesign of the UI to make it more intuitive. I have made a quick mockup of that: http://files.spacefish.biz/gimp/new_color_correction_menu.png Maybe i got this wrong, but isn´t the Color Balance menu just a simple 3-Way Color Correction Panel? http://i.imgur.com/PhaXziO.png would probably be a slightly more traditional rendering :) What do you think about the idea? I guess some people would like to retain numeric input, but that's just my gut feeling. For me 3-way would be preferable. The tool could offer both methods so users can choose. Actually, Blender has two different methods: Lift/Gamma/Gain and Offset/Power/Slope (the second is the ASC-CDL standard exchange format for color grading). If the 3-way UI and the current numeric inputs have a correspondence, users could change between modes without loosing the grading. Boosting the color balance tool to add this new stuff sounds like a really cool GSoC project, especially now that making GIMP suitable for VFX work became one of the targets. Gez ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] 15 lines
El 25/01/13 16:54, Daniel Hornung escribió: On Friday, 25. January 2013 11:30:40 scl wrote: I'd say, it depends on the images the particular user usually works with. While a screen or web designer might work with small images the most time, a photographer or scientist works with much bigger images. Different users have different needs and a default value - may it be 3, 4 or 15 lines - is always insufficient for anybody. Suggestion to fit with both web designers and old book scanners: What if not the number of lines were fixed but the distance between lines in screen units (physical distance or fixed amount of pixels)? I could nearly always live with a line every 10 or 20 pixels, and would find it very convenient if the distance was about the same no matter what my zoom level is. Even though it may sound reasonable, the problem there is that you get a grid that doesn't divide your image in even parts (when the size of your image isn't an exact multiple of your grid module) I don't think it would work. Just to clarify: I'm not against the grids or the corrective mode. I actually use them a lot (I guess that for straightening there are better options, but por perspective correction the grid and corrective mode are very useful. My problem with the default grid is that it gets in the middle more often than it helps. Maybe it's just me, but although 15 lines (or more) is ok for complete, large images, it's usually excessive for small/mid size selections in a zoomed out document. When you have a document with seveal layers smaller than the canvas size, the grid gets in the middle and it's really annoying. I know I can change it, I guess I could save a new default for me, but asking if that default is suitable for the majority of the userbase seems a reasonable question. I know that transforming large images is one of the several valid use cases of GIMP, the question is if it's more frequent than transforming individual, small elements of a layered composite. It's just matter of defaults and how useful they are. Oh, and btw. What about having different grid settings for normal and corrective mode respectively? I don't mind the 15 lines grid for corrective mode, but I find it almost useless and interfering for the normal mode. Gez. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] 15 lines
Hi, I find the default of 15 lines for the grid in transform tools quite annoying most of the times. When you're transforming small things the grid really gets in the way. I think a more conservative setting, say 3 or 5 would be more a flexible default. What do you think? Gez ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Help with a Gimp 2.10 question
El 18/12/12 14:28, Paka escribió: * jEsuSdA 8)lis...@jesusda.com [12-18-12 11:39]: Hi Gez! Great opinion and nice data. As I suppose, maybe Photivo will be the chosed. Darktable will be fine, but there are no Windows version at the moment. Being crippled by windows is not the end. You can always install a linux distro into a virtualbox (all free apps) and run photivo/darktable there. +1 Pascal de Bruijn used to compile a custom Ubuntu LiveCD with bleeding edge Darktable. I'm not sure if he still does, and I don't know is they also include GIMP, Photivo or any other photo processing/retouching application. Fedora has a custom design spin with graphics software and there are other distros with liveCDs with plenty of graphics packages. I'd avoid windows. Although it's a system with a huge userbase (this also applies to free software for graphics), the performance and DE experience is generally inferior than gnu/linux's. Apart from that, most of the windows installs you'll find are 32 bit, which is likely to be insufficient for high resolution image processing. Gez. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Minor enhancements in the export dialog
I'm adding an extra item to the list: I also had several of reports about people choosing the file filter dropdown (in the export dialog) by mistake, thinking it was the format selector. A label saying show only: or something like that could help. Also the widget is too prominent and it drags your attention to it before the file format selector, which is usually more important than the file filter dropdown. Gez ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Minor enhancements in the export dialog
El 25/11/12 11:57, Richard Gitschlag escribió: Now that is strange, because using Windows GIMP 2.8 it seems to be the default setting for my Export dialog, even between sessions. Yes, It's also the default setting in linux, but the problem is that people seem to miss that using the extension will save the proper format and the think they have to choose the output format manually. That's why I propose to make that feature more obvious adding a better description. And this is kept between sessions, but the PNG extension is always used in the filename. If you change the extension to JPG, for instance, when you close and re-open GIMP it will go back to PNG (using the default use extension option, but it won't remember the last extension used). Gez ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Selling GIMP Creations
El 22/11/12 11:14, Caitlin escribió: Hi there, I was just wondering whether it would be okay for me to sell images and any products (which materials created in GIMP have been incorporated into) that I've made using GIMP? The images etc used would originally be my own, however, there may also be some circumstances where the entire image is created in GIMP (i.e. without a photograph or anything used as a base/template). Thank you so much for your time -- much appreciated! Kind regards, Caitlin Caitlin: You own the artwork you created with GIMP. You can do anything you want with it. The license of GIMP doesn't affect the works you create using it, it only governs what you're entitled to do with the software itself, and it's a very permisive license that lets you get the program for free, share it with your friends, inspect the code and modify it (if you can) and distribute those modifications, as long as you distribute the source code along with the executables. That license (the GNU GPL) grants you rights and some obligations regarding the program, but your creations are not covered. So, feel free to sell or give your products away. It's up to you and if you made it with GIMP (or any other free/libre software) doesn't change it. Gez ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Overlay Mode - fix.
El 14/11/12 09:32, yahvuu escribió: Am 13.11.2012 18:37, schrieb Michael Natterer: The problem is much bigger. Almost *all* of our layer modes will be Legacy, and the new modes will operate in linear light. Just adding a hack for overlay is not going to fix the root problem. are you referring to technical concerns or rather to UI design challenges? I think the solution that was designed to update the color transfer blend modes (#325564) is sustainable here, too: Old modes have '(legacy)' appended in layer mode menu and don't show in menu unless an XCF with one of them is openend. They never show in paint menu. Working with a legacy XCF thus offers some 40 blend modes, which can naturally be displayed in two columns, side by side. This is important in order to enable manual replacing of the old blend modes on a layer-by-layer basis. The legacy modes are CPU hogs, because they need to apply gamma to both inputs and de-gamma the output. I see no way around that. When a legacy XCF gets openend, an automatic conversion to the new blend modes can be offered, informing the user that the color appearance might change. This needs to be undoable. The notification should be non-intrusive, probably similar to Firefoxen's door hangers[1]. I believe a lot of the rationales also apply to GIMP. However, this needs to be in line with general GIMP UI (peter?). Writing legacy XCF is clearly an export. @Gez: i believe this is mostly in line with your proposal, only that i'd like to avoid a modal pop-up on opening the legacy XCF. I think that a checkbox in the layers panel would be more elegant and less of a clutter than adding legacy blending modes to the available blending modes. I was thinking about adding it along with the lock buttons. A checkbox labeled legacy mode that adds the needed gamma correction nodes to all the layers and replaces the new overlay for soft-light is all that we need. I can't see a reason for having legacy blending modes co-existing with native. The legacy mode should be only for compatibility. Users should always use the native mode and only use legacy for the very specific cases when old files need to be opened and their appearance has to match with other old files. For artistic purposes, the appearance of the old blending modes should be replicated using different tools (probably adjustment layers in the future. The non-destructive workflow proposed by Peter should provide all the needed tools for that). Duplicating the number of blending modes available adding the old ones is cumbersome and seems quite pointless. There's an extra use case where legacy mode could be useful, and it's working for web mockups. As far as I could see, and the last time I asked pippin about this he said the same, since web browsers blend RGBA images in gamma-corrected space, it's necessary to design web mockups with gamma-corrected alpha overs to match the web appearance. Currently only alpha-overs are affected, but the web is getting blending modes soon in CSS, and apparently they will be also blended in sRGB space. For that specific case using the legacy mode would be mandatory. But again, it doesn't have to co-exist with native. It's switching to a mode where everything has to work in the old way (except overlay probably. I'm not sure what overlay formula will be used in web browsers). So, summarizing: - There's no real need to make new and legacy co-exist. Those seem more like exclusive modes. - The new mode should be default, and the legacy mode an alternative. - The current and future web seem to blend RGBA in nonlinear space, so having a mode for that could be needed (and in such case the term legacy isn't entirely accurate). Regarding the modal popup: this is a very special situation. The user has to decide wether to use the native mode or the legacy for the imported file. Making that step transparent could mean leaving that important difference unnoticed. Kind regards, Gez. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Overlay Mode - fix.
El 14/11/12 23:18, Ofnuts escribió: Use legacy mode when the image is iprocessed in 8-bit? (which could be on e of the technical reasons for the non-linear blending anyway) That's interesting, and iirc it was one of the first proposals. The problem with that, in my opinion, is how to communicate to the user the difference and what bitdepth to use as default. If a default session of GIMP starts in 8 bpc int... Should the blending behave as the old GIMP? I don't think so. But perhaps the solution is indeed a new mode there, among the other bit depth modes. What about a new mode, a legacy/web mode which is 8 bpc int, with nonlinear blending but it's NOT the default bitdepth? The rest of the modes should be linear to ensure the best quality, and probably the current 8bpc mode should be replaced by a 16bit int mode with a conversion to 8bpc in the end (to make sure all the color operations, blendings and filters provide good quality results, even in 8bpc). I'm not sure about the technical viability of this proposal, but from a user point of view the impact in the UI would be minimum (just an extra mode in the precision menu). The legacy files would open using that mode, and in that mode the blending should be done in non-linear space, and the layers UI would show the same modes, but they will work as in legacy. If the overlay mode uses the new formula, the imported legacy files could get the overlays converted to soft-light. The same mode would work for web design. If that's possible from the technical side it sounds like a pretty elegant way to address these needs, and meanwhile it would keep the rest of GIMP working at the best quality for the creative work. Gez. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Overlay Mode - fix.
El 13/11/12 14:37, Michael Natterer escribió: The problem is much bigger. Almost *all* of our layer modes will be Legacy, and the new modes will operate in linear light. Just adding a hack for overlay is not going to fix the root problem. --mitch Apart from the different overlay formula and all being blended in linear light, is there any other layer mode that changes? I was thinking about the simplest way to tackle this problem, and if those are the only differences this might work: If the file was created with 2.8 or earlier, show a warning and offer opening the file anyway or using the legacy mode. If the user chooses legacy: - Promote the file to high bit depth. - open it normally (afaik this would convert the colorspace to the working space and linearize every layer) - add a gamma correction operation to all the layers applying the sRGB TRC (1D LUTs?) - blend - Linearize the composite prior the last color-management op. - Regarding the Overlay operation: Just replace it using the soft light mode instead. Correct me if I'm wrong, but in GIMP 2.8 and previous versions both modes seem to provide the same result. Probably applying gamma correction to inputs that were linearized from a gamma corrected source sounds redundant, but this is supposed to be a legacy mode, a compatibility layer, so the reduced efficiency would be probably justified. If this is possible, switching from legacy to the new native linear blending would mean just bypassing the gamma correction nodes. I'm not a coder and I don't know anything about the GIMP/GEGL internals, so I tried using the logic I'd use with a compositing software. If this is a stupid oversimplification you're entitled to make me STFU :-) Gez ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] SmartDeblur
El 23/10/12 06:16, SorinN escribió: We already have a plugin which ca do something similar in GIMP (and is standing as a gimp plugin for quite a while ..). Now this plugin seems to be unmaintained. please check here : http://refocus-it.sourceforge.net/ SoriN: Does Refocus work for motion blur too? As far as I could see it was very good but only for out-of-focus pictures, not for motion blur. Also defocus does, in my opinion, a very poor work when the image has an alpha channel. It tends to introduce noticeable artifacts around the edges. Gez. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] GIMP's ICM simulation must be improved as PhotoShop
El 23/09/12 19:33, Alexandre Prokoudine escribió: On Mon, Sep 24, 2012 at 2:28 AM, Guillermo Espertino (Gez) gespert...@gmail.com wrote: I've used this one in 2.6 for print softproofing: Gives better results than the print preview settings in GIMP and seems to be more consistent with what I get from CMYKtool, which has a very reliable preview (at least in my experience). Did you mean to link to http://registry.gimp.org/node/24944 ? :) I was asking myself where I put the link and YOU HAD IT! Next time don't take my things without asking first. Thank you. :-p Gez. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] segmentation fault when trying to replace deprecated functions in lcms.c
El 19/09/12 10:43, Christopher Curtis escribió: On Tue, Sep 18, 2012 at 7:33 PM, Joao S. O. Bueno gwid...@mpc.com.br mailto:gwid...@mpc.com.br wrote: Why a new branch? Things in other branches tend to bit-rot horribly. This is GIMP unstable - it should go into master. Wouldn't it be better to keep the mainline in a near-releasable state rather than letting things bit-rot in master, causing 3-year intervals between releases? AFAIK, the work Elle is doing is critical for a proper color managed workflow in high bit depths. Without it the next realease of GIMP, even if it's released earlier, won't use the real benefit of high bit depth, because color transforms would throw away the extra color depth. Moving it to master could mean that mode developers and contributors realize its importance and they won't let it bitrot. Proper color management is as important as high bit depth for people who really needs high bit dept. Gez. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] segmentation fault when trying to replace deprecated functions in lcms.c
El 18/09/12 20:33, Joao S. O. Bueno escribió: Why a new branch? Things in other branches tend to bit-rot horribly. This is GIMP unstable - it should go into master. +1. Merge! :) ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Shape layers for GIMP?
El 09/09/12 18:22, Jeremy Morton escribió: Yes, processors nowadays are very powerful and indeed applying a bunch of effects onto a shape layer every time you make a change takes a good amount of CPU power; but that's fundamentally different, because at least there, there is a finite limit of the number of operations that will need to be reapplied per change (ie. every single layer effect is turned on, the CPU will have to re-apply every single layer effect). However, the idea of being able to modify any change in the undo buffer is much more difficult, because there is a potentially infinite number of past changes. I could design a really complex shape, apply 100 effects, then go away and do loads more complex work with loads more complex effects, then design another really complex shape, etc. By the time I want to go back 1000 (by the way, actually finding the edit I want to modify would be rather difficult at this point too!), the CPU has to apply 1000 processor-intensive effects. That's WAY more work than even the worst-case scenario with something like a shape layer. But it just gets worse and worse. What will the performance be like if I want to modify something 10,000 moves back? 100,000? At some point this idea because unfeasible, it seems to me. Modern CPUs can perform quite a lot of operations without cumbersome delay, but even the most powerful CPU is going to start to hurt at some point, and in advanced graphics editing, that point may arrive rather quickly. Well, I guess that it all depends on how GEGL manages the nodetree. AFAIK GEGL works internally as a nodetree. It's not a linear stack of operations, so every branch of that nodetree will have its own history of operations, and layers, text objects, etc. will be different branches. So if you did 10 operations in your document, probably only a small percentage of those operations belong to the layer you're working on. The rest can be cached, and that cache should survive until you do something that affects that cached layers/elements. Apart from that, 1000 move operations don't necessarily mean 1000 cached bitmaps of every position. It doesn't even mean 1000 move operations again if you have to recalculate the tree. If you have a stack of 1000 move operations, the only two operations that matter are the original and the final position. It's not necessary to recalculate all of them if you don't have to go back to an intermediate position. I don't know the internals of GEGL and I'm sure that creating a high-performance non-destructive workflow is a challenging task, but I can think of several tricks that would work around the complexity of a node tree. It can be optimized if you can avoid redundant operations. It's possible to take snapshots of everything but the area you're working on, etc. I know nothing about programming, but I have some experience with nodal compositing programs and that's how they work. You don't put 1 move nodes if you have to tweak the position of an element 1 times. You just tweak the position and the node will store the position. And I guess that the undo stack of that operation will store only the 1 changes in the coordinates. It can be done. Software packages like Nuke or even Blender, which is far simpler, do something similar and for animation! This is a good example of a very complex tree in action: https://www.youtube.com/watch?v=POpi-Jt_EaQ Gez. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Shape layers for GIMP?
El 08/09/12 16:23, Jeremy Morton escribió: I think the first stage, to make it really useful, would be to incorporate the Script-fu layer effects here into GIMP proper: http://registry.gimp.org/node/186 Are they already in GIMP? I can't see most of them. Once they were in, GIMP could apply them to shape layers automatically. Those layer effects are just scripts inspired in Photoshop's layer effects (which are non-destructive and editable). As far as I know having GIMP ported completely to GEGL will make things like that possible (while the old core didn't), but still somebody has to code the feature. I'm afraid it's not as simple as incorporate the existing effects to GIMP proper. Regarding the original topic, I remember there was a vector layers GSoC project that never made it into GIMP. It's from 2006, so it was designed for the old core, but maybe somebody could take a look, at least to see if some of that code is useful for introducing the feature to the new GEGLized GIMP. Gez. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gegl gaussian blur gamma error
El 07/08/12 08:04, Øyvind Kolås escribió: I'll try to explain the desired situation in the end differently: Files coming into GIMP and going out of GIMP might have assigned ICC profiles, this is for import and export. There is no such things as a working space in GEGL buffers flowing between operations in the graph have defined color spaces and each node/operation have their own logic for preferred working space and the raster data is converted before processing. ICC conversion should only happen on import, to a well defined babl supported color space, and on export to whatever preferred color space the user has. The babl color spaces used by GEGL have unbounded gamuts, and the conversions in use are precise conversions rather than conversions implemented using interpolated 3d lookup tables. The consequence of this is that all blending, resampling (scale/rotate), blurring etc. should happen with linear gamma. There should be ways to change the colors in a buffer to correct for a wrong profile. As well as deciding that you want to export images from the composition with a different profile from the input. /Øyvind K. Sorry if this is an stupid question :-p What about display filters/soft proofing/whatever you call display correction? When/where it happens? There is an interesting section about that here: http://cinematiccolor.com/ (page 29 of the document) I'm not sure if this is too focused on motion-picture work, but the whole document looks very interesting anyway. Is any of this appliable to GIMP? Gez. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Update and apology
On 25/07/12 07:44, wanderer wrote: Well, as an user who read the list it came to my mind the implementation of auto-save in Gimp. I guess you already had that discussion, but I think that a good software is the one that understand that us, mere mortals human beings, make a lot of mistakes and try in some manner to reduce the range of these mistakes. Keep in mind that it could not be as trivial as it sounds. Image files processed in GIMP can be really big, and probably the penalty in performance and diskspace of having constant backups is too much. Probably it's better to wait until GIMP gains a non-destructive workflow, where storing copies of the internal GEGL tree seems more feasible than duplicating large files all the time. Gez ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp UI ... hesitant about compiling a list...
On 24/07/12 15:56, Simon Budig wrote:
Please try to state your question/suggestion in a way, that non-native
speaker have a chance of understanding. I did not get at all what you
want, and my english in general is pretty good. Thanks, Simon
He seems to suggest that GIMP developers should conduct a user
experience study.
But he also seems to suggest that instead of artists or any kind of user
in the target audience, developers should interview clueless people who
refuse to learn anything or is dumb ('idiots' in his words) enough to
take years to figure that floating selections can be anchored back or
turned into new layers.
It can be summarized like this: Perform a user experience study
interviewing MS Paint users to figure out how to turn GIMP into MS Paint.
Gez
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] A letter of complaint
On 23/07/12 14:15, Akira Tanaka wrote: That is all. If you took the time to read this, you have my thanks. You're welcome. bye then. G. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
