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 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 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] 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 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] 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 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 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] wtf with the download?
El dom, 31-05-2015 a las 17:14 +0100, C R escribió: > It does say "via BitTorrent" on the teal link. > There's a good case to be made for just listing the torrent file as a > smaller text-link after the orange download button, though. If I had my > way, we would not be listing a torrent at all for windows users, as there > are far too many things that can go wrong for that platform. However, I'm > trying to present a solution that everyone is okay with. Esp the developers > who will, in the end, be applying these patches to the site. Most of the > devs have been supportive of keeping the torrent link (at least as) > prominent as the direct download link. Hi, I just followed the previous posts and I confirm that it looked bad before you trimmed the text as Michael said. Now text fits, but the problem wasn't the length of text but its font. font-family: Segoe,Myriad,Tahoma,"Trebuchet MS",sans-serif; I guess you have one of the listed fonts installed so you can't see how it looks when it falls back to sans-serif, which is the font Micheal and I are seeing (and everyone who doesn't the MS fontos or Myriad). I don't think it's a good idea to use those fonts. If you want something better-looking that system sans-serif, you should use webfonts in order to make sure that what people see is what you intended, otherwise it's a lottery. On the other hand, the html you used is a bit messy. It's not completely wrong and it probably validates, but it's unnecessarily convoluted. First of all: don't use tables for layout. Also don't put stuff in divs, style them directly. You could style the "a" element itself and float it to the left with CSS, and you could remove all the divs and the tables. Just do this: http://Package-GIMP-windows-stable-jernej"; class="button-http">Download GIMP 2.8.1.4Via HTTP Description With that html alone, and styling the a.button-http class (and .button-http span) you're done Make them float to the left of the paragraph and you get the same with a fraction of the markup. If you're in doubt just poke me or check the Visual Formatting Model docs at W3C Finally, on a personal note, I think the rounded corners for buttons look a bit dated. The current trend for this kind of stuff seems to be no rounded corners at all or a very small radius. Thank you for taking care of this. Let me know if you need a hand. 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] 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 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 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 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
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 > 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 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 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 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 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] Create New Layer Button
El vie, 27-03-2015 a las 09:16 -0400, Elle Stone escribió: > On 03/26/2015 08:16 PM, Ofnuts wrote: > > It was also not so obvious to some more advanced users :) let's face it, > > in a software with the breadth of Gimp, everyone is going to overlook > > some feature. > +1. I'm the kind of users who read the tooltips, so I knew the feature and although I have no personal interest in having it changed, I wouldn't mind if the behavior is reversed (clicking on new layer creates a new transparent layer and shift+click brings the dialog for alternate options). 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. That being said, It's kind of depressing that being "people who read tooltips" makes you an "advanced user". Come on, it's not that hard to read at least once a program's tooltips and status bar :-p 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 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] [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 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] 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] Attempt to summarize the discussion of my examples of what doesn't work in unbounded sRGB
El lun, 21-04-2014 a las 11:49 +0200, Nicolas Robidoux escribió: > On 21 April 2014 10:47, Teo Mazars wrote: > > > > ... are you really saying that Gradient should be implemented using a > > non-perceptual color space? > > > > I am sure this has been discussed in more detail elsewhere (didn't a CSS > committee discuss this somewhat recently?), but the short answer is that > most people will be happier if gradient is done in a perceptual color space: > > http://www.imagemagick.org/Usage/color_basics/#gamma As a user, I find both useful. If I need a gradient for a background, I prefer perceptually uniform gradients. When I need to mask images, linear gradients make more sense. But that's probably a matter of taste and not only a "technical" decision. For that reason, I think that forcing one or the other is insufficient for catering users needs. For gradients it makes a lot of sense to add an option so the users can choose. It has been discussed that alpha blending in gamma space should be provided, although it's not "correct", to keep the appearance of legacy files. In that particular case, an option is given for people who choose that appearance, even though it's technically incorrect. Why not offering an option for technically *correct* gradients? Anyway, I think it would be much better to make GIMP work properly in linear space (the way light behaves in real world) and worry about gamma correction only in the end, for display and export. If a specific tool needs a temporary flip to gamma and back for whatever reason, that can be added on top of that (ideally as an option, so no technical use is hindered by a personal aesthetic preference). I'm pretty sure that a true linear workflow with some options to specific gamma corrections can make all the linear/gamma modes go away from the precision menu, simplifying the UI and making everything more consistent. 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] Attempt to summarize the discussion of my examples of what doesn't work in unbounded sRGB
El dom, 20-04-2014 a las 17:03 +0200, Øyvind Kolås escribió: > the sRGB chromaticities; or CIE Lab, or any other babl defined format. > With a potential future babl lcms2 extension; the original pixels > could even be kept in the layers raster storage.. doing so would have > no effect on display of the pixels or processing of them since things > are converted _on_demand_ to the pixel formats requested by the > operations. Doing this would for the user not be functionally > different in any way; apart from a risk of things being slower. Exactly how much work is required to create transforms from any other colorspace to the existing babl pixel formats? Is sRGB hardcoded in all the operations that flip pixel formats or it can be replaced without having to re-write all of them? I mean, would it be possible to create different "profiles" (note that I'm not talking about ICC profiles) specifying the primaries, gamma and white point of other colorspaces so they can be used instead of sRGB? If that was possible, it would be accessible to people like Elle who want to create such profiles and edit in a specific colorspace without the unbounded transforms and data, right? 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 and Adobe RGB (1998)
El jue, 17-04-2014 a las 16:48 +0200, Nicolas Robidoux escribió: > Opinion: > > Using, internally, a reference unbounded color space (or two: one linear, > one perceptual, with, possibly low precision shadows for speed), and > converting in and out of it when an image is imported or exported is a sane > choice. It's still not clear (at least for me) what is the impact or the unbounded color values in processing. I'm not pretending I have all the answers, so I'm proposing to discuss it. Elle and I brought a couple of examples where those unbounded values introduce problems, and we didn't get direct answers about them. I think it's not a sane choice pretending that all the cases that don't fit the model are just corner cases. It's quite contradictory to be extremely worried to keep the appearance and behavior of legacy files, and at the same time throw away valid cases of high-end professional editing, labeling them as "corner cases". > Deviations from the "standard internal color space(s)" should be motivated > by the operation being performed, not by the color spaces of the initial > and final results (which may or may not belong to the same ones in any > case). > There are, no doubt, situations in which alternate internal color spaces > could give better results. But catering to these corner cases is likely to > cause endless headaches for developers and bring no benefit whatsoever to > 99.999% of users. It would be interesting to discuss if those cases are really corner cases. Pulling mattes from green/blue screen shots is really common in VFX, and high end cameras usually have way more color latitude than sRGB, what means that an important part of the gamut needed to pull those mattes would end in the out-of-gamut, hence "unbounded" realm. We're not talking about details invisible to the eye as in Elle's yellow cone flower example. Please, don't take this as an attack to the project. I'm just sharing my concerns as a commited heavy user of GIMP and free software. In the end I'll respect your decisions even if I don't agree with them, because you guys are doing all the heavy lifting. 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 and Adobe RGB (1998)
be proven wrong, it's a good way to learn new things :-) > While doing > global overrides of some of the internal pixel formats that are > absolutely colorimetrically defined would make it easy to misconfigure > the color settings yielding surprising and inconsistent behavior. That's true and I've witnessed that hundreds of times during my carreer as a designer. Most of the graphic designers I know (who use Adobe) don't know what to do with the color settings dialog and leave them untouched, or in the worst cases touch it without knowing what they're doing. But you can't just assume that all users won't know what to do with color profiles. As I mentioned before in the recent softproofing thread, I'm all for removing some confusing and error prone elements of the color managed workflow, but that should result in something the allows a sane color managed workflow where users have control, not a "transparent" thing where you only select your output bounded color profile and nothing else. > > Adobe RGB (1998) is important for: > > > > * People preparing images for printing > > The default GEGL/babl pixel formats in floating point are unbounded; > and personally I think the 16bit formats should be made 4.12 instead > 0.16 fixed point to provide adequate headroom/footroom - though with a > predominantely floating point based processing doing this might not be > a huge win. As a person whose work consists in sending files to offset print shops weekly, I tend to agree that the AdobeRBG's gamut gain in green is almost irrelevant, and the gain in cyans is marginal, considering the gamut of the usual output colorspaces. I don't think AdobeRGB is that important for general print, but it's still widely used and some specific models of photographic printers seem to be specially tailored towards the green and cyan extra gamut provided by AdobeRGB. > > * People who want or need a small gamut color space that is nonetheless > > larger than the very small sRGB. > > The usefulness of the extended range in cyan/green; and how many > perceptually discernable colors you gain compared to sRGB is > questionable. I agree. > > A summary rejection of Adobe RGB (1998) ignores the needs and accustomed > > workflows of the many, many photographers who work in the Adobe RGB (1998) > > color space. > > Not having saddle adapters as mandatory attachment mechanisms for car > seats ignores the needs and accustomed workflows of horse riders used > to maintain and customize their leather saddles. Heh, that's not a good argument for something that is more a PR issue than a technical one. People use Adobe. You can't use that argument in a world where people still uses toilet paper :-) 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 dom, 13-04-2014 a las 19:25 +0200, Øyvind Kolås escribió: > On Sun, Apr 13, 2014 at 7:17 PM, Michael Natterer wrote: > > On Sun, 2014-04-13 at 13:01 +, pip...@gimp.org wrote: > >> Thus there is during processing no predetermined format; as soon as some > >> processing is done on the pixels from the storage format of the raster > >> layers > >> in GIMP; it is quite likely that the format of the pixels are "RaGaBaA > >> float"; > >> though it might be quite a few others. > > > > Um? I don't see much premultiplied processing around. > > > > It's mostly "RGBA float" or "R'G'B'A float" isn't it? > > gaussian-blur, whirl/pinch, scaling, warp tool, pixelize, and most > compositing modes are using "RaGaBaA float" if they used "RGBA float" > instead their innerloops would have to take alpha weighting into > account to avoid color bleeding from transparent pixels into opaque > pixels. > > /pippin I can see the associated/unassociated alpha and linear/gamma switches are in place and I think all of it makes sense (maybe there are places in GIMP where those switches don't work properly yet, but that's not the question) What I still can't understand is how unbounded values will be managed in some RGB operations that don't work well with negative values, and none of the answers in this thread seem to clarify it. There are several examples, but the simplest situation I can think of are the multiply/divide blend modes. A simple operation like multiplying cyan*red (0,1,1*0,0,0) breaks when those red and cyan comes from a wide-gamut colorspace and have been converted to unbounded sRGB. I tried with a wide-gamut profile where red and cyan converted to unbounded sRGB had these values: RED: 1.6548, -0.1319, 0.0052 CYAN: -0.6548, 1.3290, 0.9948 Note that those values are perfectly complementary and if you add them together you'll get white as expected, but the result of multiplying them goes completely bonkers: -1,0835 -0,1492 0,0051 That should be black. Neither clamping or clipping will give black. Ok, it's pretty close to black if you clip the result, but it still has a little blue that shouldn't be there, and that will accumulate through the composite. How are cases like these managed using unbounded sRGB? multiply/divide are basic operations that are present in several blending modes. Is this a problem or I got it all wrong? If this is a stupid question please let me know so I stop asking :) 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 dom, 13-04-2014 a las 00:45 +0200, Øyvind Kolås escribió: > On Fri, Apr 11, 2014 at 11:54 PM, Elle Stone > 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 > 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
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] 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 mié, 02-04-2014 a las 16:38 -0400, Michael Henning escribió: > > Will the image be converted to extended sRGB before image editing can begin? > > Yes. > > > Will the user see out of gamut (that is, out of the sRGB color space's > > gamut) RGB values expressed as RGB values that are less than 0.0 and/or > > greater than 1.0? > > Yes. There is one complication: Users have the ability to choose to > edit in different bitdepths, so the integer bitdepths will be clipped. Does this mean that in float bitdepths a pixel in a layer could have negative RGBA values? That could break compositing badly if those values are not clipped (and clipping those out-of-bound values would destroy the original gamut, defeating the purpose of the unbounded colorspace transform). Maybe I'm getting it wrong, could you please clarify 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 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 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
a working > profile. "File Open Behaviour" has three settings, and one is "Keep > embedded profile." You're right. But have you considered the consequences of editing an image in a large-gamut colorspace in 8-bit integer? AdobeRGB isn't enormous, and posterization will show up earlier than 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 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 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 gam
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 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=Q99MeymK7wA&feature=youtu.be&hd=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] Soft proofing and the GIMP Display Filters and Color Management settings
El lun, 10-03-2014 a las 16:06 -0400, Liam R E Quin escribió: > +1 although for print work at this point you have to move to Krita or > Photoshop, most likely photoShop with a "preflight" plugin, so that you > can adjust individual plates (e.g. with dodge) for the different ink > colours (CMYK at the most basic, or two plates for a duotone). That's not entirely true. You could use an intermediate or late binding workflow, do the creative part in RGB and convert to CMYK later. IMO, although early binding has a couple of advantages, tweaking the CMYK plates individually gives you the false illusion that you have extra control, and you can easily end up screwing your output unless you know exactly what you're doing (for instance exceeding the recommended TAC for your output). I've been working for print using free software for the last 6 or 7 years, and GIMP is part of my pipe. I have some tricks for duotones/tri-tones that I had to develop out of necessity (it's true that GIMP's UI doesn't offer a handy way to create them, but combining the decompose tool with the Separate+ plugin you can get very good results). I think it's just matter of workflows, and although GIMP isn't suited for early binding, it can provide a reasonable set of tools for intermediate and late binding. And because of this, soft proofing is extremely important. You can use RGB for print, but you need a reliable set of tools to proof colors against the desired output, and you need them to be handy. 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] Remove "you can drop dockable dialogs here" label?
El vie, 14-02-2014 a las 11:04 -0300, Gez escribió: > https://dl.dropboxusercontent.com/u/255376/gimp/GIMP-drop-icon.png The same icon and tooltip can be placed in the top-right corner of the no-image window (in single window mode) if there are no dialogs docked. ___ 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 mié, 12-02-2014 a las 03:03 -0500, Andrew Pullins escribió: > I was wondering if it was possible to remove the "you can drop dockable > dialogs here" label from underneath the tool box? I found a way to remove > wilber from the top which I really do not like, I think Wilber should be at > the top. once I found this I tried to remove the label but can not seem to > find a way to do this. If there is not I think you should really consider > removing it from GIMP. 1. it is an eye sore and looks like it is a mistake, > and 2. you removed the doc area borders from underneath the dialogs > assuming that users are smart enough to figure out how to doc dialogs > together. why not remove this text. I was thinking about this and came up with the idea of replacing the text with a plus icon and a tooltip instead of the text. I was about to create a quick mockup on this capture https://dl.dropboxusercontent.com/u/255376/gimp/drop-area.png (it shows how bad it looks when the toolbox is downscaled, not to mention how much worse it gets when the text is localized) Then I realized that probably a simpler solution is to just hide that text when the drop area isn't big enough to contain a dialog inside. My screenshot is a good example. You can't put any dialog there without rescaling the toolbox. Anyway, that text still looks pretty bad, even when it's appropriate, so here's the mockup with the idea: https://dl.dropboxusercontent.com/u/255376/gimp/GIMP-drop-icon.png I think it's quite compact and easy to discover, and it definitely looks better than the current text. The idea of hiding it when the drop area is too small still applies. Gez -- > Jesus is my Lord and Saviour. Praise be unto God for giving us a way to > live with him. I think this is pretty much O.T. ___ 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] Gimp on Steam
El dom, 09-02-2014 a las 20:20 +0400, Alexandre Prokoudine escribió: > On Feb 09 2014, 19:25 Gez wrote: > > > GIMP is way beyond the stage of getting exposure and growing a userbase. > > I have some very serious doubts about that :) What I meant is that "exposure" is something GIMP already has. It doesn't have a huge userbase because people don't choose it, not because they ignore its existence. Considering the product vision, I'd say that an important part of the target audience doesn't choose it because some of its limitations. Fortunately those limitations are being addressed, but developer time is required for that to happen, hence... > > > The attention should be put on making it better and more suitable to its > > target audience, and that requires devolopers and a lot of work, and I > > doubt that Steam (or any other non-free distribution channel) can make > > any difference in that regard. > > That's apples and oranges :) Developers and packagers are not the same > people in the GIMP team. I'm slightly concerned about how distributing > GIMP through Steam is going to affect packagers, but I'm not worried > about developers at all in that regard. Yes, you're right and again I didn't express myself with clarity. In my head :-p the logic was: perhaps making GIMP comply with the requirements of Steam does require some developer work. I'm no sure about this, but what about input devices? It will be ok to include a program which is basically controlled by keyboard/mouse/drawing tablet in a computer intended to work as a game console, or will they require the program to work with their controller? Blender and Krita developers seem to be willing to push their programs in Steam, so I wouldn't be surprised if they devote some resources to make it happen. Something that doesn't seem to be the case for GIMP, and that wouldn't report a real benefit to the project. 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 12:24 -0300, Gez escribió: > As far as I know, Steam is a Debian derivative. Technically Debian... Sorry for the double-posting. My connection is having hiccups. 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 10:31 +0400, Alexandre Prokoudine escribió: > On Sun, Feb 9, 2014 at 10:13 AM, Abraham Levi Mireles Alvarez wrote: > > > > I think the main benefit would be in the distribution and secondly in the > > exposure. > > I understand that you are excited about Krita + Steam, but there are > people who are not familiar with Steam at all, myself included. > > Why is it better than the usual distribution channels? > What kind of extra work should packagers do on top of what they already do? > How much time does it take to prepare builds for this distribution channel? 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). However, I don't see the benefit. Using any developer time to take care of including GIMP on Steam would be a waste of time. GIMP is free software, and they can include it anytime if they want (and respect the license). GIMP is way beyond the stage of getting exposure and growing a userbase. The attention should be put on making it better and more suitable to its target audience, and that requires devolopers and a lot of work, and I doubt that Steam (or any other non-free distribution channel) can make any difference in that regard. 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 13:58 -0600, Chris Mohler escribió: > I look for 'flatten image' under 'Layers' every single time it seems > :/ Don't know if it's habit from PS or that's simply the place I > think it ought to be. You nailed it: it's habit from PS. :-) I remember having troubles with that particular command when I switched to GIMP. It took me a while to re-wire my brain, but after using GIMP exclusively for several years I can't remember where it was in PS :-p Anyway, I think you brought a valid example because it's both reasonable to look for it under "layers" or under "image" (where it is). That's why I don't invoke the command from the menu and I use right click on a layer thumbnail in the layers dialog. It's the last command in the list, so it's really easy to spot it 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] 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] Search Action dialog feature
El jue, 16-01-2014 a las 14:29 +1300, Jehan Pagès escribió: > Well that's the same but inside GIMP for internal commands. You want a > blur command? You type "blur", and it will propose all the various > filters, like "gaussian blur". > > This is such a common feature, and useful as hell! I think a search command would be useful for filters indeed. I can understand that less used filters grouped in categories are sometimes quite difficult to find, but that shouldn't be the case for the rest of the tools. So, if the proposal is to improve the filters dialog, adding a search function and some other useful features (I think Peter mentioned a better method for accessing frequently used filters, for instance), I'm all for it. But a search tool for every function in GIMP seems a terrible idea. You should learn to use the program, the tools should be arranged in a way it's useful and easy to reach/discover. And they are. I think GIMP UI has a decent distribution of commands in its menus and a search function there would be completely unnecesary. I use GIMP daily and I don't think I remember a single time I coudn't remember where to find a command. Filters are a different thing, as they co-exist with plugins and addon scripts, under group names that aren't always so obvious, and under a menu that can become quite large. I'd definitely a search function for filters, but not for the rest of the program. It seems silly. The menus make sense, the keyboard shortcuts are 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] UI theme for GIMP
El jue, 28-11-2013 a las 13:29 +0100, Przemyslaw Golab escribió: > In Blender users can adjust DPI of the UI making widgets smaller or bigger > as they wish. Maybe something like that would be good option for solving > problem with different, too small or too big, screen resolutions? Using the DPI setting for changing the UI widgets and text is plain wrong. The DPI selector should be used to set the right DPI for the screen, so the UI looks consistent in different screen sizes (i.e.: No tiny buttons on large, high resolution screens and no gigantic buttons on old CRTs). What Andrew Price suggested in his UI videos is a misuse of something that was designed for a different purpose. Of course, that doesn't mean a UI "scaling" factor can't be used. But I think that we should be better ask our usability expert for recommentation of real-world sizes for the UI elements based on the best performance of readability and usability, so the default theme is designed around it. If a particular user wants larger buttons or dialogs, I think it falls in the theme customisation territory. I don't think programs should provide such specific features (that are, at the same time, unrelated to the program's main goals). 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 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] GIMP System Requirements
El 23/10/13 18:52, C R escribió: Things like the perspective tool can get really slow if your graphics card isn't any good, and if your photo is really big. Does GIMP use any hardware acceleration on transform tools? Iirc it doesn't, but I might be wrong. 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] 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] 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=buffer76c92&utm_source=buffer&utm_medium=twitter&utm_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 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] 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] [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] OpenCL and GIMP tile size
Maybe this is out of place, but speaking of tiles, I noticed that several compositing packagings and 3D renderers draw the tiles outwards from the center of the image. Some programs even offer preferences for different tiles drawing. Outwards from center seems to be faster (actually it's a perceived faster, not real faster) than rows from top left to bottom right. I think that drawing the tiles outwards from the center of the view would provide a huge boost in perceived performance, because you'd always be seeing the first tile in the visible. Right now if you're looking at the bottom of an image and the top is beyond the visible area, you have to wait for the tiles to be drawn, and in slow operation that's perceived like extra slowness. Is this even planned or considered? Is it possible? Sorry if this question adds noise to the thread, this has been on my head for several days and I needed to ask. 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] Sketch Based Deformation Tool
El 17/03/13 04:00, Sashi Kumar escribió: Hi, Does implementing Sketch based Deformation tool in Gimp be a good idea? Cage Transform tool is pretty slow. But I think it would be better if a sketch based interface is used for deformation and it would be more efficient to use. This tool is based on the project - http://igl.ethz.ch/projects/image-deformation/ I would like to implement this tool as GSoC project this year. As a user, I'd say the "puppet deform" took (the one that creates a triangulated mesh from the selection and allows to add arbitrary points to "rig" the deformation) seems more useful than this. I think that having the cage deform tool already and having the possibility of adding the puppet deform tool we have enough. What I would like to see is a precision tool for bending images or creating shaped envelopes. For instance, sometimes you need to fake a decal or label on a curved surface of a bottle, and you want to create an envelope that matches the curvature of that bottle. With the cage deform or any of the other proposed tools you can make "artistic" approximations, but you don't have enough control to make symmetric or parallel envelopes. So what about an interactive bezier envelope? Gez. ___ 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 gradients
El 10/03/13 15:16, Ofnuts escribió: This must be part of Gimp's Great Oral Tradition... I can't find the word "drop" in http://docs.gimp.org/en/gimp-gradient-dialog.html :) This said, after trying it, the gradient editor indeed looks better. Heh, I didn't check the documentation, but one of the great things in GIMP is being able to drag and drop colors from swatches (it's also a nice method for color fill without going to the bucket fill tool, so I use it a lot and it's the first thing I tried when I wanted to edit a gradient. I guess this should be added to the documentation. - To modify an existing stop: grag and drop a color on the black triangle. - To add a new stop, drag and drop a color on the gradient preview - To move stops and modify the transition curve between them, drag the black and white triangles respectively. IMO it's very, very simple (of course, if you found how to do it or somebody told you, so point taken about the lack of documentation about this way to customize gradients). Gez. ___ 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 10/03/13 11:10, rafał rush escribió: Hi Gradients in gimp are very very painful thing. I love gimp and i used it a lot but gradients are nightmare. I see that you are making new tools and other stuff but the most important thing and the thing that all graphic designers using all the time is gradient. To make simple gradient i must do hundred clicks. Gradient window is weird and difficult for new user. Are you planing make gradient tool more user friendly? A nightmare, a pain? I can agree that editing the endpoints is not as straightforward as it should, but adding stops requires only to drag and drop colors on the gradient editor. How exactly would you do it "more user friendly"? Probably in the future when a gradient is a GEGL node the tool could be extended to allow th edit the stops on canvas making the gradient editor almost unnecessary, but right now it's not possible since you have to define the gradient before applying it, and once you did it it becomes pixels. The gradient editor could use some improvements, of course, but saying it's a painful thing, a nightmare and stating that you have to do "hundred clicks" is an unnecessary exaggeration. Why don't you try describing the parts you think are more problematic and propose how to do it better? Gez ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
