Re: [Gimp-developer] Ang: Why GIMP is Inadequate
It's just Troy... again. :-) Once a year he writes about a free application that "still isn't there" (according to him). Some of the points point he expressed in the post may be valid (at least technically), but they're not exactly breaking news for anyone. Repeating year after year the same story won't help to make programs better. I remember myself being a jerk like that some years ago. :-p But finally I got how things work here and, although I'd love to see things happening faster, I truly appreciate the great work you guys are doing, and I don't care if I have to wait. Thanks a lot for working in this great program! ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Photoshop ?compatibility? mode
And all this conversation is because you think CTRL+Backspace makes more sense than CTRL+. (because you're used to that combination) and you don't want to take 30 seconds of your time to personalize the accelerators? Seriously? GIMP accelerators are customizable using a visible option from the Edit menu, and you can even choose to assign accelerators dinamically from the preferences. The menurc file in the prefs folder has the list of accelerators. You could create a custom version with the combinations you want (or google for it, just to find that someone already did it). A couple of days ago a voluntary coder (with an impressive CV) arrived to this list offering his help and he only got a couple of replies. This pointless discussion got a lot more of attention. Just my 2 cents. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Photoshop ?compatibility? mode
As it was stated before, making applications act "similar" doesn't turn out in "familiarity", but in a percepction of incompleteness. The most our applications looks like others, the most former users of other applications will spot what's missing, perceiving differences as limitations. When I switched from GIMP after almost 15 years of Photoshop the first reaction was the same. I wanted GIMP to behave like photoshop, because I considered Photoshop's the right way of doing things. Now I'm glad it didn't work that way, because it forced me to understand that I was using a different program. In the future I'd love to see even more differences. Who knows, maybe a node UI instead of layers, for instance ;-) Moving in that direction, imho, would stop this endless and pointless flamewar about GIMP vs. Photoshop, and people who moves to GIMP would be doing an informed choice instead of seeking a free-of-charge Photoshop. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
> These concepts do transfer to GIMP, and if one is generally empowering > students with the ability to do manipulation on images.. teaching them > how to do it with GIMP gives them both a skill and an option of a tool > they can use without a fee; as well as have the freedom to improve in > the other ways free software does. Pointing out that some things work > better in Photoshop doesn't seem constructive in this discussion. Indeed. I was baffled to see how some GIMP people started to downplay GIMP as not suitable for this particular need. It's a school teacher trying to get kids into the basics of image manipulation, not a high grade training for the print industry! GIMP is absolutely suitable for this task, and it can be used in real world environments too. I use it everyday for my professional design work. I have to work around some edge cases, of course, but for most of my work it is usable (and I send works to different print providers in a daily basis). I don't care much about CMYK since I use intermediate/late binding, but the lack of higher bitdepth is indeed a hurdle when I work with narrow range monochrome gradients or alpha channels. Anyway, I don't see how some gradient banding or the loss of precision with some filters could be a real concern for kids learning the basics of image manipulation, at least to the point of considering to replace GIMP, which is free, with an expensive commercial application. And even in that case, GIMP uses the same principles than Photoshop, so you can use it to learn to work layers, blending modes, masks, filters, selections, levels, curves, color balance, cloning, healing, etc. It's all there. Apart from that, I'm with pippin about the premature CMYK conversion. I came out of the University (where I studied graphic design) with a rather limited knowledge about color management, thinking that early binding was the only way to work for print and that with the right CMYK values I would get perfect Pantone colors :-p When I switched to free software and met GIMP I had to learn some basics again to work without CMYK and the quality of my prints improved a lot, because that time I knew what I was doing. Of course there are cases when the access to CMYK separations is useful, but I would have preferred that they teach me to work with color management properly and learn to tweak CYMK later. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CMYK file export plug-in
Hi. Although it's a good idea to have the separate- plugin bundled in default GIMP installation, I'd like to discuss some enhancements that could be done in its bigger brother Separate+ to make it more functional for people who needs more advanced CMYK usage. The idea is quite simple and wouldn't even require changes in GIMP, although I think we should discuss the default behavior of GIMP when opening CMYK files (and that would probably require the modification of the import plugins of formats that allow that color mode). But that's a different story, let me explain the idea first :-) After reading about (Pippin's) idea of CMYK/spot projections instead of a native CMYK mode for GIMP I realized that some of those concepts could be applied to extend the existing separate+ plugin. It doesn't look too difficult to implement and it would probably calm down most of the people who needs CMYK and grasps every opportunity to start endless discussions about why GIMP isn't adequate :-p, at least until the real thing is ready* Currently, Separate+ plugin separates a flattened RGB image into CMYK. it uses layers (or layers with layer masks) to display the separated CMYK "channels". It's effective for color managed conversions (it even allows to use devicelink profiles) but when some manual tweaking is needed there's no way other than working on the fake channels or the pseudo-composite masks directly, with the disadvantage of not having a reliable feedback of the operations performed. Most of the people ask for CMYK because: - they want to use C, M, Y, K channels as spot colors in certain parts of the image (for pure cyan, magenta, yellow, green, red or blue) - they want to control black generation (for pure black text or grays. Which is again using the K plate as a spot plate). - They want to create custom rich black or super black areas. - they think they can get perfect Pantone colors. For the rest of the cases there's no better choice than relying on color management, so it's reasonable to expect a proper conversion when the right profiles are used. But what happens with those particular cases I mentioned? Is it possible to do that currently in GIMP? Pretty much, yes. But it's tedious and error prone. Using Separate and then tweaking the pseudo-channels allows to solve those problems, but with some time consuming operations. Those operations are: - Combining the alpha channel of the pure C, M, Y, K areas with the corresponding separated channel via screen blending mode. - Converting desired CMYK percentages to grayscale values and fill the selection (the alpha of the area that should have a specific CMYK) with the resulting values for each layer created by Separate+ The resulting file will be perfectly fine, but reaching that point is tedious and several things can go wrong in the process. So, what if the ideas of spot layers is applied to Separate+, using naming conventions to define what to do with them? Example 1: Adding overprinted pure black text and strokes on a color illustration. Preparation: put the color illustration to be separated with Separate+ in the bottom layer, in other layer named "pure-k" put the text and strokes. Procedure (to be automated): a) Separate with Separate+ as usual. b) take the "pure-k" layer's alpha channel in the original file, blend it using screen mode on the separated k pseudo-channel. note: "pure-k", "pure-c", "pure-m", "pure-y" would be the names for these special layers. Example 2: Creating a logo with a custom rich black or Pantone color Preparation: put the color illustration to be separated with Separate+ in the bottom layer, in other layer named "c60m50y30k10" put the logo. Procedure (to be automated): a) separate with Separate+ as usual. b) take the "c60m50y30k10" layer's alpha, copy the selection to the separated document, convert every porcentage to a grayscale value and fill the selection with the corresponding values for each pseudo-channel. note: choosing arbitrary ink amounts may exceed the TAC for the target profile. Ideally this should be controlled but probably this is too fine-grained for a temporary solution and the user should take this precaution (after all, this can also happen with a native CMYK mode if the user doesn't check warnings) About Pantone colors: it's pretty much useless to rely on Pantone CMYK values since they only work if very precise printing conditions are met. In my experience it's better to recourse to a color managed conversion from the Formula swatches (which are stored in Lab and GIMP can use them converted to RGB in a GPL palette). In my opinion converted formula colors look closer to spot colors than official Pantone CMYK values in most of the print shops I printed with. This method is actually endorsed by Pantone as the most appropriate for intermediate/late binding workflows. Example 3: In this post from David Revoy he used the previous cases together, but he used Photoshop for the task: http://www.davidrevoy.com/index
Re: [Gimp-developer] CMYK file export plug-in
2011/3/21 Jacek Poplawski : > On Mon, Mar 21, 2011 at 11:30 PM, gespert...@gmail.com > wrote: >> Most of the people ask for CMYK because: > > I need CMYK support for photo retouch, to create better colors. > CMYK is no different than LAB, HSV or RGB. Well, CMYK is quite different than LAB actually. Could you please elaborate about how you can create better color in a colorspace which is device dependent and has tipically a smaller gamut than most of the RGB working spaces? When you work in CMYK mode in a program like Photoshop, the visual feedback you get is an on-screen soft-proof of the CMYK color converted to your working RGB profile. So what you see isn't really what you get, and it's probably better idea to do your photo retouching in RGB soft-proofing to your target CMYK. The good thing about this is that you'll keep the larger gamut and your colors won't be unnecessarily and irreversibly clipped to a smaller gamut. CMYK (and it's not just me saying this) is an output colorspace to send images to four-inks process printers. With color management the CMYK mode should be legacy. > It is colorspace like > others, but uses 4 channels instead 3. That's not completely true. If inks were perfect, the fourth channel wouldn't be necessary. Black was added to compensate CMY inks imperfections and also to save ink and make prints cheaper. Tell me if that's not a declaration of device-dependent colorspace! When it comes to monitors, it's obvious you need to work in a device dependent colorspace. You can't use another device to see your images when you manipulate them, so there's a reasonable excuse to use device dependent colorspaces as working profiles in that case. But how your RGB image is separated to CMYK is defined in the target profile. Messing with those separations individually is modifying the way they were separated by the profile, which is the one in charge of converting the colors to the best possible values for the target device. Despite it's a pretty common practice, it doesn't sound correct. > Instead focusing on CMYK I would give Gimp access to use any defined > colorspace in realtime, just as RGB. ... > So adding support to display group of layers as RGB/LAB/HSV/CMYK could > be good first step. As far as I know (please correct me if I'm wrong), the idea with GEGL is to work in device-independent, 32bpc float linear space and then go to Lab, RGB (or even CMYK) depending on the need. So the first step you mention is on the works. What I discussed in my previous message was an interim solution mostly for black generation and pure CMYK primaries, the things that management won't solve exactly as the user wants. Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
> On 2011-03-29 14:09, LightningIsMyName wrote: >> ** Default JPEG Quality (quickie, not a real topic) ** >> Change to 95 2x1, and add a hack to save defaults (using something >> like the PNG plugin does, or something more elegant). Note that a >> decent system to save plugin defaults, along with other api changes, >> is not something that will happen for 2.8. > > So you set the quality slider to 95 to ensure files will be big, but set > sampling to 2x1 to ensure the image quality will be poor? I don't see > the sense in this. > > Also the JPEG export plug-in has had a stored default for years. What > are you trying to add? > > Note that if the source file is JPEG the plug-in offers similar settings > to the originating file by default. You can still click "load defaults" > to override it. I did a couple of quick tests with an image with photos and design elements (type and areas with solid fill) and I got better results both in overall quality and file size using 1x1 and smaller quality factors than using worse subsampling and higher quality factors. In my test the best relationship between quality and filesize was using quality=92, subsampling=1x1 and floating point for the DCT method. The resulting file was smaller than the ones I exported with quality set in 95 and 2x1 or 2x2 for subsampling. with 1x1 subsampling and quality set in 90 the edge artifacts in type and solid fill areas became visible but the edges were sharp as in the original. The photo didn't show any noticeable compression artifacts. That's completely different with 2x1 and 2x2 subsamplings. All the edges became softer and when the quality factor is high enough to avoid compression artifacts the resulting file is larger than when 1x1 was used. So I'd suggest a different default quality setting for jpg: 92 / 1x1 / floating point. If file size matters (the size gain isn't too significative, but still), a quality factor of 90 will still give considerably better quality than the current defaults. >>and add a hack to save defaults (using something >> like the PNG plugin does, or something more elegant) I don't understand what's missing in the current implementation. I could change my defaults and store the new configuration as default through the advanced options of the jpeg export plugin (in 2.6.x) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
Jeremy: You have some good points, but also Alexia and the rest have. All this stuff was studied and the consensus was to go ahead with the current implementation. Of course it's hard to please everyone and this can look bad for some people while looks excellent for others. You already can have a single keystroke overwrite by assigning manually a key combination to that command, so your need is covered. Arguments against unifying export and overwrite are strong, based on preserving the integrity of original files from reckless/distracted users. Overwriting the original file with a modified version is irreversible and it's fine if the proposed workflow protects users from that, leaving the option of overriding that protection only to advanced users who have to assign voluntarily a kestroke for the overwrite command. Sounds fair to me. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp-developer Digest, Vol 106, Issue 6
Gabriel: I'm afraid that if you hand-picked the colors using CMYK and not using any other technical background but your experience, then your color system is fundamentally flawed. CMYK is a device dependent space and if you didn't keep that in mind at the beginning of the process, then it's likely that your color system is only good for the print shop where you printed your catalogs. Of course I can be wrong and you already took care of that. I'd like to know more abour your project. By the way, I speak spanish (I'm from Argentina) so feel free to contact me to my personal address if you want to continue the discussion. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
