Re: [Gimp-developer] Color space support
If you take a look on the list archives you'll find that I was one of those designers saying that GIMP sucks because it doesn't have a CMYK mode. But I changed my mind! :-D Honestly, It took me to really understand how color management works and leave some old bad habits alone to get it. Now I'm working in RGB and sending to print shops with good results. I send sRGB images or CMYK separated with Separate+ or CMYKtool. CMYK mode is a legacy from the past, and with the growing adoption of CTP and DI systems we shouldn't be discussing this. Both Adobe and Pantone are recommending to work with late binding, although Adobe software still allows to work with early binding. So no matter what designers say, even their loved flagship companies are thinking different. What is hard to understand for desingers is that the problem isn't CMYK but spot colors. We tend to use CMYK because we see it as an image created by 4 spot colors instead of a device dependent interpretation of an RGB image. It took me some time to get used to it, but the idea of creating a separation projection on the top o a color managed RGB image, letting the user define spot colors, is growing on me as the best way to tackle this difficult issue. So forget CMYK, The projections system proposed by Peter will take spot channels in consideration and that will solve most of our problems. Not going back to a legacy hack. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP T-shirts in our online store
Ismael: I don't know the official position about this, but I think that the Wilber image you used looks pretty dated. I'd use the Tango version or the icon for Mac that Jimmac designed. They look much better and as far as I could see, the Tango version is being used for GIMP since 2.4 http://macin.files.wordpress.com/2008/09/gimp-icon-512x512.png http://jimmac.musichall.cz/images/blog/gimp-mac.png Saludos Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP T-shirts in our online store
I do t-shirts with gradient/blending all of the time - it's not any more expensive, but it can be trickier to set up and print. The main thing I see w/those PNGs is that they are too low-res for a full-front print Ehhhrm... I was talking about the re-drawn Wilber designs, not the gradients or amount of colors. The PNG files were only samples of what versions of the mascot I was referring to. Both Tango and Jimmac's versions are vectors. You can clean them up to match your color requirements and print them. Gez ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] We should go for a single-window mode in 2.8
Peter: Thanks for your reply. You exposed some issues that I didn't took in consideration. Of course I'm not saying that Blender's UI can be ported as-is to GIMP. However I found some of those ideas pretty interesting for our case. first I noticed this set-up has no rulers or scrollbars. we have and I am avoiding the replication of the all over the screen. The buttons window has scrollbars that appear if they're needed. Blender doesn't use scrollbars in the design area itself since it's easy to scroll and pane the view. GIMP is pretty much the same. Honestly, having middle click + drag to pane and CTRL + wheel to scroll makes those scrollbars old :-) you can see here sort of the same problem that that control bar below the canvas is repeated for each of them. that sort of hides that they have to repeat that clever divider/split handle for each pane (OK, we could only show it for the current active pane, but that is slower) I think that it boils down to having an effective way to highlight the working image. I think that working with more than one image at the same time is not a real use case. You'll always be working on a single image since you have just one mouse pointer. Finding a good strategy to switch between the active images would solve most of the problems (maybe just a click on an inactive window and a colored border like this? http://www.mmiworks.net/pics/blog8/lgmbigparadeL.jpg). The file menu would be just one, the rulers should appear in just one window at a time and we even may get rid of the scrollbars :-) another thing I see here is filling the new tile immediately with the same thing as the parent one. I thought I wanted to do that too, but then realised that in GIMP an empty tile would be automatically a drag-n-drop target to open an image, from the parade, file browser, etc. In blender you work with a single project and open separated resources. Of course it isn't the same in GIMP. I think that again the active image window should define the title displayed. being empty does give a requirement where the new tile has to appear: for l-to-r locales it has to be on the right, so it would have to be 'pulled in' from the right. which would put that clever split handle in the corner where resize corners are found: bottom-right. ouch. I din't consider rtl locales at all, good point. Anyway, the resize handlers of the view in blender ar performed by dragging the edge of the window, not the corner. The corner icon is only used for splitting, joining or floating the window (with shift+click+drag on the icon) then there is a the arbitrary splitting. I have a funny feeling about that. has to do with how arbitrary the result is. and how, and how fast, do I build 9 (halfway) equally sized tiles to start filling with images? I know a fast way for that (View-Tile-9-square) but that is incompatible with arbitrary splitting. In blender you have a pre defined orthographic 4-view window. I guess you can split the main image in two, leaving an empty area, and via the view menu perform something like: split this window in 9. Then drag and drop images from your OS file browser in each empty window, making always active the last touched. and how does blender define the current canvas one is working on? I would expect the load of inspectors on the right and bottom of the screen to track the current canvas. yes, mouse pointer focus. And that's true, it's not usable in GIMP. But I guess that a single click in an inactive window could make it active. It's the same that you currently do to make active another image window when you're working with multiple windows opened. HTH, Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] We should go for a single-window mode in 2.8
Just a couple of things: - The splitting could display another view of the same image, just like in blender. That would make working with views a breeze (for icons or pixel art, for instance). It doesn't need to be empty if you dragged it from an existing image window - About the problem of arranged multiple views, it seems that one would use that amount of images just as reference, or for fast switch. Then, a view could have a parade mode that allows you to open a directory or a selection of images in a row. And you can use that row as a fast switcher to open (or drag as a layer in the active image) any of the images. In that case the parade won't be a group of opened images, but rather a thumbnailer. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] We should go for a single-window mode in 2.8
Peter: What do you think about the method for splitting/joining views in Blender 2.5? It's fast, it kinda covers the idea of the image parade and it allows to float a section as a new window. The only thing needed would be something to mark which is the active image and that would be enough for most of the described cases. I prepared a brief screencast showing how it works. http://dl.getdropbox.com/u/255376/Blender-UI.avi I think that some interesting concepts can be picked up from this kind of non-blocking UI. Gez ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [PATCH] Improve brush outline for fuzzy brushes, sample screenshot included
what about printing a semi transparent copy of the actual brush on the canvas? Is it possible? The ghosted brush can have two opacities, one for the preview when the tool isn't in use, and one more transparent when the tool is in use. I wouldn't mind to have a simple circle of the size of the brush as the default mode and an alternative option for overlaying a semi-transparent brush image. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Remove zoom tool...
Luis Diego: Yo can remove it yourself when you want. Just go to (assuming your GIMP is in spanish, your name looks spanish to me :-) ventanas Diálogos empotrables herramientas and you can activate/de-activate any tool in the toolbox, including the zoom tool. Despite what a lot of people say, GIMP UI allows a lot of customization. So it has no point to discuss about the default workspace when you can change it so easily. hth, Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Scrollwheel actions by default?
The defaults are ok and match other graphic packages like Inkscape. I wouldn't touch them. Maybe you're coming from another software like Corel Draw and you got used to the scrolling with the mouse wheel, but that is not the same for everyone. CTRL + Scroll wheel does the same. The only difference between the default and your proposal is pressing a single common key. Your suggestion is only matter of personal preferences more than how it should be. For instance: Photoshop uses CTRL++ and CTRL+- to zoom in and out. We have just + and -. Should we change it because there is people used to photoshop and finds hard to get used to the diferent keystrokes? We have configurable keys, even we have a dynamic shortcuts configuration function for that. You found that by yourself and you changed the actions according your preferences, so the option is there, and people used to different defaults can customize their key shortcuts. We should change defaults only if there are better options. And in this case is proposed to change one existing and working shortcut to another, without much more reasons than because I like it better :-) Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
I'd really love to see GIMP Paint Studio presets as default too. That would make possible to get rid of some default brushes that really don't cut. About the large size brushes, I also agree. I think that several small round brushes should be removed (since brush scaling covers that need). We have nine small variants of round brushes, in a scale range that can be covered probably with a couple of them + scaling. I think we should have: - Larger round brushes. - GIMP Paint Studio brushes and presets - five to ten texture/grunge bruses, in two sizes: large and small. I'd get rid of that outline squares, crosses and some of the special effects brushes. Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] sorry
Hi Esteban. I found your marbles. Here you are... You can go now. It's perfectly clear. You're leaving because you prefer Mac OSX and Photoshop and people here have been mean with you. We understand. Good luck and bye. Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp interface changes
The more I read this, the more I feel that a solution like the present in Inkscape (wich is not precisely an example of a great interface) would be a one-time solution for everyone. Just to see what I'm talking about, open a new Inkscape session, go the the right edge of the window and drag the bar to the left. There's the space that will be used to dock the dialogs. If GIMP would have something like that to dock the floating windows and toolbox, I guess most of the one-window fans will be satisfied. I can understand it's not a trivial work, but seems to be a reasonable solution that can make everyone happy. I wouldn't need more preferences options, it can behave like the current windows regarding how the windows positions are saved. I guess that would be a tad problematic when there is more than one image open, though. I'd personally stick with the floating windows just like they are now, but maybe that possibility would calm some people out there. :-) Gez ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP PDF export plugin
El jue, 26-03-2009 a las 21:43 +0100, yahvuu escribió: Hi all, just to be shure (i'm probably just paraphrasing Andrew A. Gill's follow-up): I think this task can be done equally well in an RGB space, say sRGB. If Pantone's Bridge has sRGB approximations, it should be trivial. If not, you have to convert that single color from your best-guess CMYK to sRGB first. It won't be useful if the image has to be imported in a program that actually lets you assign CMYK values. Following with my example, the bitmap could be imported into scribus and put together with a logo, with the right CMYK values. Chances are that, though quite similar, the colors won't be the same. Thanks to GEGL's dynamic nature, the sRGB-CMYK separation will be live, so the resulting CMYK can be cross-checked immediately, like read-after-write with good old audio tapes. But it will still be difficult to specify a color. For instance: I need the background of the image to be C=60%, K=100%. I'd use that combination because I want a rich black with cold shades of gray. If I use RGB, the separation will include Magenta and Yellow depending on the output profile and I wouldn't want that. Please do so. The general need for CMYK support beyond mere color separation has been put out quite clearly. Yet AFAIKS none of the examples has shown a requirement for doing actual image processing in CMYK space (which is a good thing, btw). By this i mean anything which can't be done by processing the plates as separate grayscale channels (see Øyvind Kolas's post). It's fine to adjust the grayscale channels if we get a corrected preview interactively. In fact, that's the way you do some adjustments in Photoshop. But there are several tools (channel mixer, curves) that is useful to have working in CMYK space. --- Also, in this discussion it seems that it was never considered that you can be working on images that somebody else sent you and you don't control how they were created. If somebody sent you a separated tiff of a magazine ad and you have to do some editing on it, you'll be destroying the original separation converting it to RGB. And that's unacceptable. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP PDF export plugin
Even though I agree that most of the CMYK cases mentioned use CMYK almost as spot colors, I can think of a very common usage scenario in Graphic Design where you need to be able to edit CMYK directly: Corporate colors. Most frequently Pantones. Brands have their corporate colors and ask designers to use them, but they can not always afford extra spot passes in offset press, so the colors have to be converted to the most aproximate CMYK combination (the Pantone Bridge catalog is for that). So you have to adjust the color of a photograph of a sign, a truck and a producto of your client to their corporate CMYK color. It's a photograph, you need CMYK, you can't use spot. This is a very common scenario, and it's a task for a image manipulation program. Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CMYK editing (Was: GIMP PDF export plugin)
CMYK exists because, though is possible theoretically, it isn't possible to generate black from mixing CMY inks. As the C, M and Y inks aren't perfect and have some contaminants, mixing them ends up in a dirty brown instead of pure black. That's why CMYK exists, and that's why it isn't so simple to print an RGB image. The problem resides mostly in the generation of black and gray shades. Although there are systems that do a great job converting a photo to CMYK on the print side, it's still a problem to do a simple task as placing a pure black overprint on a solid color background without destroying some underlaying information on the separation. I'm a designer, not a photographer, and an image manipulation program is an essential part of my workflow. And placing some black text, or editing a large image with a black or gray background, adding black drop shadows, aren't rare at all. And it's a pain without the ability of editing the separated CMYK. It's not about if the printer will handle the file or not, is about creative control. Sometimes you NEED to control the black overprint. Sometimes you need to use spot colors and you need to control the channels and how they overprint. Even with Adobe software, before having spot channels in Photoshop, it was a common practice to separate to CMYK to make 2, 3 or for 2 inks prints (replacing the corresponding plate's ink for a custom ink). Simply because other programs didn't support the Adobe's custom multitone files but did support CMYK tiffs. Well, I can't do duotones with Gimp to insert in a 2 inks flyer. CMYK editing would help. I can't control the black generation of a separation, because the separate+ plugin doesn't support that. It just support existing profiles and there is no control. I can't control CMYK curves. And trust me, that's extremely common. I can live without CMYK, I have some workarounds and can do some tricks, but it certainly makes my designer work harder and less productive. I can wait, I'm ok with the argument it's not trivial, requires a lot of work, requires a lot of refactoring. But I'm not ok when somebody says that it isn't necessary. Maybe it isn't for photographers, but it certainly is for designers. GIMP stands for GNU Image Manipulation Program. Not just for Photograpy. I think that CMYK editing is certainly in the scope of the product vision. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CMYK editing (Was: GIMP PDF export plugin)
Hi Robert, thanks for your comments. This really sounds like you're using black as a spot color rather than going generic editing in CMYK space. That was just an example. Another example could be just putting an image in front of a gray gradient background. In my experience, it's not that easy to find a printer that can convert a RGB gray into a perfectly CMYK neutral grey. Or isolating a photograph, putting it on a solid color layer and apply a drop shadow of the isolated image on the color. Why should I send an RGB file and see how my printer's RIP separates the grays and the shadows when I could be specifying: I just want 100% black over the color? They are only real world examples. Probably there are excellent print shops in Germany or USA that deliver excellent results from an RGB jpeg, but that's not always the case. I question whether doing this in an image editing application is really the right thing to do. If you're doing black text, you probably want the text to be vector rather than raster anyway -- printing an image scaled to 240 DPI is fine, but the text won't look so good at that resolution. In that case, you're better off using something like Scribus to do that kind of overlay, at least until GIMP has vector layers. Again, that was just an example. It may be true in a brochure or a magazine page, but what if you need to add a texture to a title, breaking the borders of the characters with a grunge brush? or something like that? But let me show you a very simple example: http://www.flickr.com/photos/superdd/2781429410/ This image was created in Inkscape and exported as PNG. Then in Gimp the yellow part got some texture and color work. What if I want to put that image in a page of a magazine that I'm creating in Scribus, and I want the black part of the image to be the same black (100% black) than the text. In that case I would have, according to your workflow, to: -take the image to gimp, make the texture part, remove the black part, save it, import in scribus the color blob and a black-only SVG version of the drawing, make them match in size and alignment (ouch, I should have imagined that I would need some bleed on the color shape to avoid alignment errors), and export them as a CMYK PDF to send to the print shop Or simply separate in GIMP to CMYK, remove the black part of the CMY channels and tweak the black channel, save as TIFF and import in Scribus. Call me crazy but I choose the last one. Of course there are alternative ways, but sometimes it's faster and more direct, thus preferable, to do it with the image manipulation program that using three or four separated applications for a simple task. Which again is a spot color kind of use case rather than a CMYK use case. Yes, but we don't have spot channels either. At least having CMYK would work as a viable temporal solution until we have spot channels. I find it hard to imagine that GIMP will support spot channels if it won't support CMYK channels. It wouldn't make much sense to add a spot channel to an RGB image, would it? Does that indicate that separate+ is what needs to be enhanced, rather than the core application? This discussion was about a PDF export plugin at the beginning. I was trying to make evident that a PDF export plugin is probably useless without CMYK/SPOT/VECTOR LAYERS, and improving and integrating the Separate+ Plugin instead of focusing on a PDF exporter would make sense and a big difference. Gez ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP PDF export plugin
I send files to print shops every week. Here in argentina even serious printers require proprietary file formats like AIs and CDR, though they're fine with tiffs and PDFs. I don't understand why there is so much interest in supporting PDF export from GIMP, since the exported data will be only bitmap, and in that case a tiff file is enough and is absolutely compatible with every design program out there. In my oppinion, PDF only makes sense if there is mixed data like bitmap images and vector shapes or text. For flattened bitmaps, I'd say TIFF is even safer than PDF. My current workflow consists in separate RGB images to a CMYK tiff using the Separate+ Plugin. Usually I do some black overprint tweaking using the faux channels that Separate+ creates. When I need a PDF, I use Scribus or this script:http://my.opera.com/area42/blog/cmyk-tiff-2-pdf-for-gimp I think PDF will only make sense when vector shapes, CMYK color and spot channels are in GIMP. Meanwhile, Separated Tiffs are enough and I think that putting time and efforts on a PDF exporter wouldn't make a real difference. I'd prefer to see the separate plugin integrated in gimp, direct save of the separated tiff through the save plugin, importing separated tiffs directly (opening CMYK tiffs currently results in an uncorrected image with distorted colors wich is pretty unusable). So -1 to this. There are oteher things far more important than this. Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dockable Dialogs Should be Dockable Everywhere
I think it's not about customization or not. Is about avoiding a cluttered prefs menu with gazillions of options and provide smart ways to customize instead. Look at this for instance: http://www.youtube.com/watch?v=v5IjbClO8Sk (the upcoming Blender 2.5) There you have an example of a highly customizable environment without the need of marking checkboxes in the preferences section. Gez ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Silent profile embedding.
Hi. I don't know if this can be considered as a bug, but I'd like to discuss some potential issues in the color profile embedding strategy. Currently (correct me if I'm wrong) the procedure for images without embedded profile is to silently embed the working RGB profile upon opening. This can be really problematic when the user has a sequence of images without profile (for instance a rendering from a 3D program) and want to retouch a couple of images. The result will be that the retouched images will have a profile and the others won't, and that can bring troubles when importing the image sequence into a color managed software. A simple way to avoid this would be to ask when an image without profile is opened, just like when an image with a different profile than the working profile is opened. A dialog could allow the user to choose wheter to keep the image unmanaged or embed the working profile. Additionally, a label on the top of the window stating the profile embedded (or the absence of a profile) by the image mode would make the status of the color management to the user. Also the feature that avoids saving an image that hasn't been modified in some way conflicts with the silent profile embedding. The profile insertion is a change, but that feature isn't aware of that change. The dialog for keep unmanaged/embed profile would serve to fix this as well: If the user selected the embedding, then there is a change. If not, the opened image is unmodified and can be closed without saving. What do you think? Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp's default screentones, brushes and palettes
What about this: http://www.gimpstuff.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Block user interaction while a plug-in is running?
IMHO the way GIMP works is fine, and interaction should never be blocked. We don't want a program that is unusable while an effect is being applied. A better solution (and I think that the porting to GEGL is aiming in this direction, among other things) would be to put the filter and the transformations in a sort of queue, so the interaction is never blocked and the processes are stacked so you can continue working while a filter is applied. Of course, in some point it will be necessary to implement a smart queue that blocks some processes that can be incompatible between them, but I think that simply blocking interaction while a plugin is working would be a step backwards. There's something I saw in Avid Liquid that is extremely interesting. The program shows a quick preview of the effects using the GPU while you edit, and it renders the filter in the background. Of course I won't compare a video editor with a program like GIMP, but I find that method very interesting. Using low resolution proxies of the filters would give an instant feedback of the filters while the real transformation is applied in the background, queued. That would be in my oppinion a smart way to avoid blocking interaction without limiting the possibilities of the program. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dropping two images from Gqview -- Gimp
I agree that it's quite confusing to have two different behaviors for something that looks almost the same. But I think it is good to have the other functionality available too, so I guess it is worth to add a modificator key, as Peter suggested. Something like this, for instance: - Drop multiple images on Wilber (both in image window or toolbox): opens each image as separate documents- - Drop multiple images pressing alt: opens them as layers in the same document. The question is how to proceed when there is an image already opened in the image window. I guess it should open images as layers in that case (without pressing alt), and work in the same way that it does now, since there wouldn't be a wilber in the image window. What do you think? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A Photographers View of Gimp 2.6
Stephen: - GEGL Unsharpen Mask: AFAICS, the values are the same of the regular unsharp mask filter, but it has a larger scale. It allows extreme values (i guess it makes sense for really high resolutions) - View at Simulated Output: That's what the point to point option allows when deactivated. - Noise Reduction: There are several great plugins for noise reduction: Greycstoration and wavelet denoise being a couple of them (Greystoration is really impressive). - High Dynamic Range Imaging: There is a exposure blending script that allows too merge 3 different exposures in one image, The resulting image isn't an HDRI though. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Transparency in transform tools
(hiding the original layer during the operation is possible, but because of the simplicity of the preview rendering, the preview may look much different that you'd expect.) Probably this should be discussed a little bit more. There's a particular situation where having an opaque original makes very hard to use a transform tool: when you paste a layer that is bigger than the image area and you have to scale it down to a desired size. You simply can't see the background because the opaque original is in front, so you can't apply the transformation with precision. The same applies when you have to rotate an element to match an angle of something that is behind the layer that you want to transform. I can think of a couple more of examples where this situation makes very hard to work. There's a workaround, that is lowering the original layer opacity then transforming, but it's not very handy (you have to do that and then remember to raise the opacity after you apply each transformation). This makes working with transformations quite slow and tedious. If it's possible to directly hide the original, I'd prefer that option until the GEGL porting of the display code is ready, even knowing that the transformation proxy isn't very accurate. I'd like to know how other users feel about this. 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 Digest, Vol 72, Issue 31
The same applies to other tools. Again, every effect is doable now, but the UI would be much cleaner with the notion colors, not color, and oh that extra transparency channel so it is treated like something alien among colors (in nature it is not -- water, glass, air are transparent as well as the chalk, snow, paper are white). And nature hasn't CTRL+Z. There are things that we must live with. Gimp is a computer program. It -like others- may or may not reproduce natural certain behaviors of natural media, because it's a computer program and there's code behind the tools you use. Maybe you'd like to point us a program that already has that feature so we can see what do you actually mean with transparent color. As other people pointed out, what you're asking for seems quite similar to the substract mode, that is already available both as a layer blending mode and a blending mode for the brush and airbrush tools. And the alpha channel handling is quite the same that other programas have (like the acclaimed Adobe Photoshop). Could you please try to explain in a more accurate way what do you need? As far as I could undestand, it looks like you want to paint with air, wich sounds pretty funny. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Transparency in transform tools
I'm testing Gimp 2.5.4 and it's amazing. I know it's late for a feature request, but I think it's worth to discuss about the current behavior of the new feature present in the transform tools: the ability to set the transparency of the layer or selection being transformed. I think it would make more sense to apply that transparency to the original layer instead of the transformed instance. In most cases, the original occludes the background, and what the user usually wants is to see the transformed object on the final context. This situation becomes particularly annoying when scaling down images. The larger original doesn't let the user see the real background, where the transformed image will end up. So this new transparency function would be much more helpful (in my oppinion) for the original, not for the target. Somebody suggested in the IRC channel that the original should simply dissapear, because the user wants to see the result of the transformation, not the original. I think that there are lots of situations where having a reference of the original, un-transformed image would be very useful, but not that useful if having it doesn't let me see the background. So, what do you think about applying the transparency to the original insteado of applying it to the transformed image? Gez. P.s.: I'm having a problem with the windows position when compiz is active (it works fine with metacity). The position of the windows is remembered, but they open a tad lower than the original position. It causes that the lower part of the windows appear behind the gnome's bottom panel (I'm using Ubuntu 8.04.1, 64 bits). ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Font are small of tool-box in gimp 2.5.4
2008-09-18 Sven Neumann * app/widgets/gimpdock.c: made the font scale factor for the docks configurable in gtkrc. * themes/Default/gtkrc * themes/Small/gtkrc: for documentation purposes, added the default value for GimpDock::font-scale here. Changed all style property names to use the canonical names. :-) Alexandre We all love when grumpy Sven says NO! at first, but later he introduces silently a patch. :-) Now seriously: That's a great option. Too big fonts were a problem for us who use western characters, because they used a lot of screen space and now the more compact dialogs look much better. But that seems to be a problem for systems with eastern characters. So this patch will indeed make everyone happy. Thank you Sven! ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Proposal new default layout starting 2.6
If you check this list's log you'll learn that the layout you suggest has already been proposed about a year ago. I know because I did it. Later I proposed that layout again in my brainstorm entry about the no-image-open dialog. I used that layout for several months, but I changed my mind. And now I'm using a totally different one. http://www.ohweb.com.ar/screenshots/one-window-layout.png The screen space usage is addressed too, and I have all in one (I have one window button less in the bottom panel with gimp 2.4, and that's good). This shows that a single problem may have more than one solution (although this solution has the disadvantage of being only useful with high screen resolutions). One of the Gimp's strengths is being able to customize the UI to have your layout, my layout and differents layouts, depending on what are your needs. But, in other hand, Gimp has a problem with it's default layout (in my oppinion). And it's not the lack of familiarity with photoshop or whatsoever. They tell us that this layout is better for new users, but every new user I know (mostly when they come from windows) the first thing they do is closing the right docker (trying to close the program). And they loose it forever (they have to re-construct it if they want it back). That's overkill. That's one of the things that make gimp's UI look weird for newcomers. And that's frequently a problem with multiple windows UIs. You don't know what X closes the program and you end up closing other windows. I'd try to address this problem instead of thinking on mimicking other programs UIs looking for familiarity. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Proposal new default layout starting 2.6
This has been addressed in GIMP 2.5. And the change is even explained in the release notes. Oh, I didn't read that part. Great news. Thanks! ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] need help with bug #464466 (downscaling quality)
Please consider adding typographic elements (logos, text) and icons/diagrams to the test images. One of the most critic use cases where downscaling shows issues is with high contrast such as dark typography on light backgrounds. This is particularly important when working with small designs for the web (banners, for instance, which end up too blurry). ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Export File dialog question
From my user perspective, I'm ok with the save / export separation. - Save only for XCF - Export for other formats (using the current method, guess format by extension, or manual selection of the output format). We users are used to save anything, despite if it's a lossy format or not, and that's bad for our workflow. I guess it will take some time to get used to the new method and break the habit of pressing CTRL+S to save when we are working on a jpeg file (for instance). But in the end it will be educative and possitive. The right way to manage files is separating the native, loseless format from the lossy, export file formats. The benefit will be a reduction of accidental data loss and an improvement in the work flow. I'm concerned about the save a copy command, though. It will certainly present a usability problem. Should it save, export, or both? Should it be removed? My guess is that it should not be removed, because it provides a useful solution when working with different versions of the file. In my oppinion, it should do the same that the save command. It means that it will no longer export to different formats, just xcf. Again, that will force users to adopt a better workflow (much people uses save a copy for exporting to a lossy format keeping the original). These changes can be quite traumatic for some users but in the long term will benefit the usability and interface coherence of the program, so in my honest oppinion, they have to be performed. Guillermo Espertino ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ?no image? window: progress...
As you can see from the responses to your mail, there are quite a few trolls on this list who aren't even willing to try the new stuff. Otherwise we wouldn't have gotten so many responses that are obviously based on wrong assumptions and that clearly show that people have not followed your invitation to try the stuff in SVN. Your comment is, as usual, insulting. It's not clear in the first Peter's message that the changes are already in SVN. He talks about concept and specification. So I just checked the wiki and, based on what is described there, gave my oppinion. In the same wiki Peter asks for feedback (but since it's a closed wiki, the only feedback we can give is using this list). You're assuming, as usual, that a final user should compile the svn code, know how to deal with the installed version and the development version in the same machine, etc. Otherwise the user can't speak his mind. Personally, I think I would be able to compile myself gimp in my machine, but I don't know how that would affect my current installation. And, since I'm an end user, I use gimp for my everyday work and can't change my working installation to an unstable version. I try to contribute from my place, but it's clear that this kind of contribution is not welcome. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] ?no image? window: progress...
About the graying out toolbox, dockers and elements not used when no image is open, I think it breaks a functionality that is already present in gimp: the ability to custumize the interface (moving dialogs to dockers, changing the dimensions and position of elements, etc.) That's, imo, a regression. Having to open an image to be able to customize the interface adds an extra step that has no purpose. The drop zone still makes me wonder. I can't avoid seeing it like the photoshop gray background. You say that gimmicks should be avoided but there is a button for the tip of the day at the bottom, wich apart of being some kind of gimmick, changes the morphology of the status bar. I wonder why the drop zone can't be divided in two blocks, one with the tip of the day (with a switch to not sowing it again if selected) and the suggested drop zone. But that would imply to create a sort of splash, welcome screen that is not encouraged in the specification. The empty drop zone without a label is no longer a gimmick, but now it's just an empty space, and again, if that window is resizeable and the toolboxes (even grayed out) have an always-on-top hint, it will look like the gray photoshop background where many of the users will suppose that image windows *should* be opened. My question is if that really will improve the user experience, or people will still be crying for the same, even after the change. Obviously, this specification at least removes the menu from the toolbox, wich is a great improvement. In my honest oppinion, gimmicks aren't too evil. They help newcomers and, if they can't be de-activated, don't bug advanced users too much. A couple of days ago I tried the MSN messenger clone emesene. They used a very interesting idea for the UI customization. There is a secition in the options where they placed a wireframe of the UI blocks wich can be turned on or off with a single click (there is a gray wireframe and the selected block is highlighted). What about using that for the no-image window? Change the empty window for a single window with construction blocks. Default would be drop zone, common tasks, tip of the day. Very newbie friendly. For advanced users, there could be a section in the prefs that allows to simply turn-off those blocks, and get an empty, no-gimmicks drop zone. Blocks may be pluggable, so it would be possible to add new blocks to customize the welcome window if it's needed. I can think of recent images lists, acquire/ batch acquire, etc. Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature idea for GSoC - Separate+ Plugin integration
Guillermo, I would encourage you towards formalizing this application - try to summarize objectively what exists today and what do you plan to implement. Also, try some guestimates on a time frame for completing each task. Joao: Unfortunately I'm not a coder. I'm not even a student :) Just throwed the idea to see if someone could be interested on it and take it to GSoC. About the plugin itself, it already provides profiles management. It's completely functional but it's limited in the separation methods. The real deal with improving this plugin would be adding point gain, black generation, overprint threshold, curves, etc. The integration part is definitively too simple and not-so-atractive to start a GSoC project, as Sven pointed out. Thanks for your kind reply. Regards, Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Feature idea for GSoC - Separate+ Plugin integration.
First of all, sorry if this is the wrong place or moment to post this. II think that integrating the separate+ plugin to Gimp would be a great GSoC project. The lack of CMYK color has been a longstanding request and this plugin is the only tool that approaches that possibility atm. It would be very useful to have the plugin integrated to the open and save dialogs, adding lzw compression to the output, improving the usability/accesibility of the plugin interface, etc. More complex enhancements would be: adding extra options for separation (black generation, UCR and GCR, point gain, curves, etc). This would be really useful for print people and would -imo- stop a little the crying for native CMYK in gimp, giving more time to focus in porting to GEGL to finally reach that goal, maybe with less of the repetitive noise of people's ranting. Regards, Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] no-image-open redux
I'm afraid that this no image window sounds more and more like the photoshop-esque gray background window that everybody have been asking for all these years. The idea of keeping it, even when there is an image open, seems to back that up. It will end up as a maximizable window and all the other windows will have a always-on-top hint. And we'll have WiW. :-p Until I don't see the proposal of the UI team, I won't understand why an introductory window with common tasks (new, open, open recent) is a bad idea. Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] no image open spec...
Oh... the no gimmicks thing. Nevermind then... Gez. Anyway, I'd would like to know why common tasks wouldn't fit there (apart of the usual it sucks). Create a new image, open an existing image and open a recent file are the first things people do with gimp. So why not? I use drag and drop to open files, but I wouldn't put new image and open recent as secondary commands, available only via a menu. Those three actions share the same hierarchy, imo. And finally... a drag here sign sounds as a gimmick too for me. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmap: my summary.
Sven Nwumann wrote: Nice to remind us of some issues but we are not going to put user wishes on our roadmap. It is rather distracting to post user wishes to the developer list. People here should be aware of the shortcomings and without being a developer, your opinion is just one of many users. But let's look at some of your suggestions nevertheless... Dear Sven: What I suggested are not my wishes. I'm a professional designer and GIMP is a tool for my work. The things that I wrote are issues that make my work more difficult, while they shouldn't. I tried to describe problems in a common workflow that need to be solved, not specific requests of my preference. I'm not asking for a save for web plugin, a slicer tool, or a plugin for a specific application. They're simple annoyances that make using gimp less effective for common tasks of image manipulation For instance, the first request. An opaque original when you're transforming loses its purpose. If it obstructs the context it has no use. Being semi-transparent would be a great help, because that way it gives a visual track of the original dimensions/shape. But if it cannot be made semi-transparent for a couple of years, maybe the best solution is hiding the original and work directly on the transformed. This isn't a wish. Nobody can scale down an image to place it in a certain place when a big original doesn't let see the context. I know that I can low the layer opacity to 50% manually before transforming it, but it is tedious and reduces the productivity. I wonder if it is impossible to automate that manual procedure meanwhile. When I wrote the word obvious (I guess it was a bad word choice) I was thinking in what it was proposed for the image navigator (changing simple booleans to semi-transparent objects) and in my head made sense that this issue could be covered. I never wanted to suggest that it's trivial to implement it. 2) Bad words choice again. Redrawing is not slow. I can drag the view and it's very fast. The problem is turning on/off or moving a layer. I work with large images and blending modes. Just open three images in a A4 artwork, 300 dpi, put normal the firs, multiplied the second and screen the third and switch on and off one of the top layers. It is slow. It's just the visibility of a layer and it doesn't give inmediate feedback. I don't want to start comparing applications, but among the tools that I've used, Gimp is the only program where turning layers on/off them doesn't give inmediate feedback. The problem extends to color adjustments as well. I can wait for a filter, but when you're tweaking colors a realtime or near realtime feedback is important. The improvements you planned for this area will be welcome. 4) Ouch! :) I read something about angle constraints using shift in the old documentation, but I tried to find it again and I couldn't. I guess I'm wrong then. Anyway, not having angle constraints in the path tool kills a big part of its functionality. Right now it's impossible to make vertical or horizontal segments, and needing them is not rare at all. Beyond that, the bézier tool of Gimp is awesome. About the other things, I can't make patches, but believe me that I'm trying to convince people with the proper abilities to join to the development team and provide solutions for commonly asked requests. It's not an easy task though. Thanks anyway for your detailed reply. I appreciate you took the time for it. Cheers, Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmap: my summary.
Roadmap will be closed by the end of this week, so I'd like to make a summary of the main issues I'd like to see fixed for 2.6 Since I'm not a coder, I just can give my user pov, so I'll try to be realistic and don't ask for too radical things, just changes to improve the existing tools. Please consider this list just as mere suggestions. Of course, maybe some of these things need full GEGL support and are impossible at this stage, so please ignore them if that's the case. 1) Semi transparent overlay of the original layer when transforming (scale or rotate). (It seems pretty obvious with the planned Cairo support) 2) Redrawing speed at 100% zoom Redrawing when a large image is zoomed out is still slow. the quality of the display is excelent, but just turning on or off a layer (for instance) is slow. I guess that using a low resolution proxy of the actual image for this operation and processing the actual pixels in the background would make the process of displaying layers and applying filters / color adjustments more agile. But again, I'm just guessing, and the roadmap isn't the place to say how it shoul/could be done :) 3) Axis Constrain for move tool. This is very, very useful. 4) Angle constrain for path tool. Afaics in the documentation, this feature existed in previous versions. Was it removed? 5) Fade Tool should work for all the filters and color adjustment tools. Currently it doesn't work for curves or levels, and that would be very useful. 6) Better screen space usage by default. I'd really like to see as an intermediate solution (until the UI team brings a more complete solution) a minor panels re-arrangement to get more screen space (two-column narrow toolbox and tool properties moved to the main docker). An introductory window with the current toolbox menu when no image is open (as I proposed a couple of days ago) would be nice too. Also, the size of the widgets and input boxes in the dialogs is quite big. Everything is spaced, which is pleasant to the eyes, but frequently eats too much screen space. I don't really know if this has to do with the GTK theme or it can be adjusted in GIMP, but just watching the UI I can see that reducing the padding and spacing just a couple of pixels could reduce the size of the dialogs and panels without sacrificing the visual goodness. 7) I left this for the end because I don't know if it will be possible at this stage: The text tool needs improvements. I don't know if they can be made before GEGL or it should be bumped to a future version. - Text edition on canvas. - modify text properties inline (selecting a part of the text and changing the options doesn't change the whole paragraph). - Don't destroy transformations when editing text properties. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmap: metadata and jpeg plug-in enhancements
Currently, GIMP tries to do a bit of both in the same jpeg plug-in and does not do either of them correctly: Raphael: These subjects were discussed before in the list when I ranted about almost the same. Since that some changes were made in the jpeg plug-in for GIMP 2.4.0 and imo they covered the real issues very well (now the plugin uses the existing quality instead of hopelessly destroying the original file changing its quality to 85). Anyway, I agree that the default quality for new images (85) is kinda low. Something between 90/93 should be better for the default value. The plugin already offers the possibility to change that setting in the first save (and better, the plugin lets you set a new default clicking a single button). So it's not a big deal. Another aspect I would suggest to change is the default subsampling. 1x1,1x1,1x1 (the best quality) is imo the better choice, because it gives a larger file, but much better quality. As this setting is hide under the advanced options tag, for the regular user it would be better if the best quality is provided, instead of the the best compression. Best compressions is an optimization. If you need a smaller file, it's a nice option. But regular users (user case: Jane wants to make minor adjustments of brightness and contrast images and remove red eyes on her birthday party) will expect the best quality by default. That's why I think the default values should be changed. About the rest of the current plugin interface, it looks just fine for me. You just mentioned PS. They chose these settings by default (higher quality and better subsampling). People (like myself the first time) tend to believe that PS offers better quality because of that. That's not true and simply changing the default values should help to destroy that false claiming. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmapping, the UI part of it...
Hi, Sven Neumann escribió: Perhaps we are simply talking about different things. Of course GTK+ provides a notebook widget and what else would we need to implement this? Yes, we're talking about two different things :-) I meant detachable tabs and different views like Opera's or Scribus' ones. Not JUST tabs. I (and as far as I could understand the other people that mentioned Opera) was talking about the ability to show the tabbed windows as tileable windows in the workspace (QT and Windows have that kind of options for child windows). That is important when you need to have side by side comparisions of different images (examples of this are grading and gama matching, two views at different zoom ratios, etc.) Is that possible with the current GTK widgets? Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmapping, the UI part of it...
Sven Neumann escribió: How is that different? We already have detachable tabs in the GIMP user interface. So why are you asking if this is possible? Sven: http://www.ohweb.com.ar/screenshots/Opera-tabs.png I know there are tabs wich are detachable already. I was talking about the way that Opera as well as QT apps can manage different views of the tabbed windows. In Firefox you have tabbed windows or a new window (with the whole chrome and buttons). In QT apps and Opera you can do the same, but also you can display views of the tabbed windos (as cascade or tiles). That results in a sort of window in window interface. That's what I asking if it is possible in GTK. Not just the tabs. That's why Alexandre posted the link to CurlyAnkles too. Making it possible to have several images in one image window using tabs would be a nice improvement, IMO. It needs some thoughts on the details but perhaps this can be done off-list to that we can concentrate on getting the roadmap for 2.6 done? Ok, let's follow it in the IRC channel. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] weekend 2.6 UI roadmap roundup...
I'd add the quality of downscaling as a high priority need. Currently it's possible to downscale images using 50% steps at a time (it was discussed before) but it would be better if one single scaling step produces the best quality possible (maybe automating the 50% steps, as it was discussed before). IIRC Sven informed that this issue would be easier to address with GEGL, so I don't know if proposing this fix before GEGL is appropriate. Anyway I'd like to point that it's a need for people who work with graphics for the web. Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmapping, the UI part of it...
Felipe: Tabs don't work for image manipulation because is frequent to compare between two+ images or work with two views (one zoomed and the other at 100%) . If we use tabs we have only one image open at a time and that's mostly a problem for pros. Another common procedure is to have two images opened and drag and drop elements (layers) from one to the other. That's not possible with gimp currently, but it would be a nice addition that would be impossible with tabs. Imo, image windows should remain independant. I guess that there are two options to deal with the problem of the taskbar buttons. 1) As I proposed in my mockup, just make the toolbox and docker dependant of the active image. - When there is no image open: use the splash (one button in the taskbar named GIMP) - When there is one image open: panels attached to the image (one button in the taskbar named GIMP-[document name]) - When there is two+ images: panels attached to the focused image (one button per image in taskbar). Pretty similar to the current behaviour, but removing the extra buttons of the panels. 2) Create (well, it's in part already done) a switcher between opened images. The problem is... where do we place it. Right now there is a button that allows to choose which of the opened images will be displayed in the panels (by default it is set to aouto). Maybe it would be nice to redesign that dialog making it more graphic, and make it work as an opened documets switcher. I'll try to find some convenient way to make it, but I'd love to know what the UI team think about it. Regards, Gez. Filipe Soares Dilly escribió: Hi; Great Mockup. I really like the idea. 2007/10/27, Sven Neumann [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Hi, On Sat, 2007-10-27 at 15:53 -0300, Guillermo Espertino wrote: In general I like this change. But we absolutely need to discuss how we want to handle multiple images with this approach. Things are getting complicated as soon as you have more than one image window. You can try the transient-docks feature (see gimprc). It makes the toolbox and dock windows transient to the active image window. Unfortunately this approach has shown to not work well with most window managers. But perhaps this is something that can be figured out. Maybe the idea of TABs (like in Firefox) is a good solution for this. Grouping all images in Tabs can save you from the problem of many Task Bar buttons and is a know solution (for interface) for the most users. -- Filipe Soares Dilly dilly.carbonmade.com/ http://dilly.carbonmade.com/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmapping, the UI part of it...
Loo wrote: I'm not a developer, but I am a pro, and I would love to see some kind of tab implimentation--as long as the individual images can be undocked or detabbed allowing more than one image open at a time. In fact, that's the most profound idea I'd read about for the UI. Yes, sure. But detachable tabs aren't too different to the photoshop windows in a window approach, and maybe it's a better idea to choose that instead of tabs (for people who usually rant because Gimp UI isn't like photoshop's). Creating a tabbed interface would require to completely transform the current one, and at that point seems to be more feasible to go with the window in window idea, and make several people happy. But personally, I think it would be nice to reach a better solution using the current floating windows. Better for the coders, who won't need to rework the UI completely, better for the existing users who are comfortable with the floating windows thing, and it is well done, better for new users who will find a different way to use an image manipulation program. The good thing about free/open source program is innovation. Great things can appear, not just free-of-charge clones of commercial apps. Regards, Gez ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmapping, the UI part of it...
Henk: Yes, I knew that (both the utility setting and the image dialog). What I meant was to polish those two features and make them work correctly in every platform (afaik the utility setting seems to have some problems in windows, for instance) so can make them available as the default behavior. When I asked Sven some time ago why the utility setting wasn't the default behavior, he answered that it wasn't because it didn't worked completely as intended. I'm talking about trying to address some problems using the existing resources as much as possible, as a realistic short-term solution. Many people ask for a complete UI redesign, but I think that much can be accomplished improving the existing. I think that making this at least would move the UI some steps forward and prepare the field for further changes in the future. Gez Henk Boom escribió: If I understand what you mean by attached, then if you set the docks to be utility windows this is the behaviour that you get already (except when no image is open). This is the setup I usually use. ... Isn't this what the Images dialog does? You can even set it to display as a grid without the filenames. Henk Boom ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmapping, the UI part of it...
I understand. It's clear that everyone's preference may vary on this subject: -Photoshop users will ask for floating windows nested in a container window. -Other users will ask for tabbed windows in a single window. -Gimp orthodox users will ask for individual windows Obviously it's impossible to please everyone. But we should look for a consistent solution that, at least, doesn't exclude completely a group of users. Reading all the comments (including Sven's saying that tabbed windows isn't too difficult to implement) I can see that maybe a switchable interface between tabbed and floating would be the most appropriate solution. The question here is how to make them live together without damaging the UI consistency. And how to deal with some of the current problems with overlapping windows (how the utility windows obstaculize the working canvas when it is maximized, dragging the canvas beyond the image borders to avoid overlapping, etc). But tabbed windows only don't help. A tabbed window should be able to be detached as a floating window and that's were my concern is. This change (just take my idea and add tabs to the document window) may look not too radical but I'm sure that it brings some collateral risks with it that must be carefully addressed before going ahead. I'll try to design some mockups with a possible solution, but this definitively needs the expert eye of Peter, Kamila and the UI team. Regards, Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmapping, the UI part of it...
Sven Neumann escribió: Nevertheless, if we can make sure that there's always a leader window, then using the utility hint is going to work much better than it does currently. Oh, I understand. I can see why Inkscape hasn't the same problem. But in their case they have a complete instance of the whole interface for every document opened, which is not an acceptable thing for a Gimp (well, it isn't acceptable for Inkscape either, I read that they're planning to change for a tabbed interface soon). Thanks for the clarification. -- I looked at Opera, as it has been suggested here. It has very good options for managing tabs (manage different views and make tiles or cascades for multiple views, detach windows from the tabbed environment, etc.) I have to agree that it seems pretty convenient for GIMP. Now, the question is, as gg pointed out, if GTK allows that kind of solution. I've never seen a GTK app doing that, so I'm afraid it doesn't. Gez ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmapping, the UI part of it...
I agree what Peter Sikking wrote. It seems -to my user pov- that cairo migration is something that will provide new methods for addressing some maybe menor, but longstanding UI annoyances, and it's great putting that migration in the first place of the roadmap. What I'd like to propose is a change in the UI for 2.6 (part of it is already possible with the current interface) to gain more screen space. The first thing I make every time I have a fresh install of gimp is taking the tool options to the right docker, and made a minor reorganization of tabs. Then I can stretch the toolbox to a two-column layout so I gain a lot of screen space to work. I'd like to propose at least that change as the default panels arrangement. It gains space, and it makes the interface more familiar for people who worked with other image manipulation packages. Plus, it's a totally reversible change, that users that like the current layout can roll back. The other part of my idea is a possible solution of the behaviour of the application when there is no image open. I developed the idea further in my blog, so I invite you to read it and tell me if this change is feasible. http://www.blog.ohweb.com.ar/?p=59 What is not covered there, but certainly would be an interesting idea to develop, is adding to those changes an optional wrapper window for the opened documents. I wouldn't use it, but it's the number one rant about gimp's interface. Imo, it wouldn't have too much impact in the program usage (because it would be working just as the other way, but having a wrapper window for the opened documents) so it wouldn't be a problem for documentation, for instance. Anyway, I'm one of the guys who think it's pretty useless so I won't mind if there is no gray background :-) Of course I don't want to go over Peter and the UI team (this proposal was already sent to the UI brainstorming blog), so I propose this for discussion and I'd really like to know what do you think about it. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] discussing the roadmap for 2.6
What do you think? I think it's a great idea to have shorter deveopment cycles. It looks like the project is more active and alive. I've heard a lot of people saying that gimp was almost dead, while I was testing 2.3.x series almost monthly. But people tend to think that the activity of a project is measured by the release cycle of stable versions, so this idea will for sure draw more attention to the project (and luckily more developers). The only problem I see with this idea is the GEGL thing. I'm not a coder, but it looks like a quite radical change in the gimp core, so if that's a goal for 2.6 and the development cycle will be shorter, maybe there is no place for further additions. And if 2.6 has only the migration to GEGL and no extra features, people will say again: gimp is stuck. Many of the frequently asked features need the GEGL core (or as it has been discussed before, it's pointless to spend much time trying to code them for the current core when the same work using GEGL will be more straightforward). I mean Layer Effects, CMYK color and 16 bpc, improved image scaling etc. otoh, there are some features that can be implemented without the GEGL migration: Fine tunning of some of the existing tools (angle and axis contrstaints for paths and transform tools, or visibility in the scale and rotate tools, for instance), interface changes, improvements in the text tool, layer grouping, etc. So, an important decision must be taken, imo. Plan the 2.6 version as a new core version (with important improvements in the technical area, but maybe not that visible for the final users), or a new features version. If this isn't defined, there is a risk to fall in a long development cycle again. That's my opinion, of course. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ANNOUNCE: GIMP 2.4.0
October 24, Gimp 2.4, and... today is the Graphic Designers day in Argentina. Nice timing! :) Congratulations developers. Gimp 2.4 will be a great success! ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Is default replace mode in blend dialog of RC3 replaced, with normal in SVN?
Ok with the need of the replace mode as the initial state of the Fade Tool, but what use does it have? I mean, in practical terms, you applied a filter, you want to fade back to the previous state... What's the replace mode use in that case? (if you drag the slider nothing happens). For the eyes of the user, the default mode does nothing, and that's a problem. It doesn't even fade unless you change it to another blending mode. If it's needed internally, ok. But there isn't apparently a reason to have it in the interface as an available mode. I mean: If I can change it from replace to normal manually, can't that sequence be performed at the moment of opening the dialog automatically? Maybe I'm missing something, but if I apply a filter, open the fade dialog and move the slider without changing the mode and hit Ok. What is the effect? That's why I'm asking. Oh, and by the way, why don't the levels and curves tools work with the fade tool? Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Is default replace mode in blend dialog of RC3 replaced, with normal in SVN?
By the way, what does the replace mode do in the fade dialog? It seems to have no effect when you adjust the slider. I understand why Alexander found it odd. I agree that the normal type should be the default (and the most expectable behaviour as well). Anyway, I'd like to know what is replace for. Gez. [EMAIL PROTECTED] escribió: Send Gimp-developer mailing list submissions to gimp-developer@lists.XCF.Berkeley.EDU To subscribe or unsubscribe via the World Wide Web, visit https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of Gimp-developer digest... Today's Topics: 1. Re: Is default replace mode in blend dialog of RC3 replaced with normal in SVN? (Alexander Rabtchevich) 2. Re: Is default replace mode in blend dialog ofRC3 replaced with normal in SVN? (Alexandre Prokoudine) 3. Re: Is default replace mode in blend dialog of RC3 replaced with normal in SVN? (Alexander Rabtchevich) 4. Re: Help needed for the gimp web site (Rapha?l Quinet) -- Message: 1 Date: Fri, 12 Oct 2007 09:34:23 +0300 From: Alexander Rabtchevich [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Is default replace mode in blend dialog of RC3 replaced with normal in SVN? To: Sven Neumann [EMAIL PROTECTED] Cc: gimp-devel gimp-developer@lists.XCF.Berkeley.EDU Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=windows-1251; format=flowed :) As I have Russian locale, it was my translation, and I missed function and realization. I was speaking on fade in Edit menu. Sven Neumann wrote: Hi, On Wed, 2007-10-10 at 09:19 +0300, Alexander Rabtchevich wrote: I've reset the options, restarted GIMP, but nothing has changed. Blend dialog still has the second position in the combobox active - Replace instead of the first one - Normal. Perhaps we are not talking about the same thing. Actually, I don't think that my version of GIMP has a Blend dialog. What exactly are you refering to? Sven -- With respect Alexander Rabtchevich -- Message: 2 Date: Fri, 12 Oct 2007 10:45:51 +0400 From: Alexandre Prokoudine [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Is default replace mode in blend dialog of RC3 replaced with normal in SVN? To: Gimp Devel List gimp-developer@lists.xcf.berkeley.edu Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 On 10/12/07, Alexander Rabtchevich wrote: :) As I have Russian locale, it was my translation, and I missed function and realization. I was speaking on fade in Edit menu. Confirmed. In Edit -Fade Replace is default blending mode. But that's for ages. I don't remember times when it was different. Alexandre -- Message: 3 Date: Fri, 12 Oct 2007 09:46:48 +0300 From: Alexander Rabtchevich [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Is default replace mode in blend dialog of RC3 replaced with normal in SVN? To: Alexandre Prokoudine [EMAIL PROTECTED] Cc: Gimp Devel List gimp-developer@lists.XCF.Berkeley.EDU Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed OK, but to work it should be Normal :). Alexandre Prokoudine wrote: On 10/12/07, Alexander Rabtchevich wrote: :) As I have Russian locale, it was my translation, and I missed function and realization. I was speaking on fade in Edit menu. Confirmed. In Edit -Fade Replace is default blending mode. But that's for ages. I don't remember times when it was different. Alexandre -- With respect Alexander Rabtchevich -- Message: 4 Date: Fri, 12 Oct 2007 10:17:40 +0200 From: Rapha?l Quinet [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Help needed for the gimp web site To: [EMAIL PROTECTED] Cc: gimp-developer@lists.XCF.Berkeley.EDU Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=UTF-8 On Thu, 11 Oct 2007 11:11:41 +0300, Alexander Rabtchevich [EMAIL PROTECTED] wrote: Just to be clear on release notes: not only cheap lens can have vignetting. Some expensive zooms have it at wide angle. Yesterday, I changed the sentence about vignetting to read: [...] when using cheaper lenses or expensive lenses pushed to their limits [...] By the way, I see that you sent your message to both lists (gimp-web and gimp-developer) but it looks like your message never made it to the gimp-web list. You must subscribe to the gimp-web list before you post to it, otherwise your message will be dropped.
Re: [Gimp-developer] GIMP UI brainstorm...
Peter: Thank you for your reply. Now I understand what's the intention of the blog. I first thought that was a kind of community approach to the UI design, but I see that it's different. The next time I send an idea I'll try to fit better into these considerations. Comment your idea text balloon style, instead of writing that long essay in your email Ok, but... Balloons are good for a few comments but they tend to clutter the image and obstruct the legibility if they're too much. More complex ideas will require more balloons or more screenshots (and you said you want one or two). Maybe something like this would help to keep the presentation simple: - Author's briefing: Blahblahblah (with a limit of x words to avoid large essays like mine). - Expert analysis: Blahblahblah because... Anyway my next contributions will do have balloons, and for better legibility a neutral background (which I intentionally avoided because I wanted to show the solution on a real background, avoiding the idea of a single container like photoshop). And a shorter text, sure :-) (I did not read it). I'd really appreciate if you have a moment and read it. It took a couple of hours of my time trying to get a decent solution for a longstanding and polemic issue in gimp. I'd really love to know what do you think about it. Of course I don't expect I love it or it sucks, but your expert oppinion. I don't see the point of the whole blog if there are only screenshots and nothing else. If nobody but the UI team will get something out of that blog, maybe the best idea is just to receive the files via e-mail and don't publish them. People who contributes usually want to have a feedback. Regards, Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP UI brainstorm...
peter sikking wrote: it is good discussing this, I will have to sharpen the 'blurb' on the blog again after this mail. Tomorrow... Ok, I understand your points. I'll do my best to improve my next contributions in those levels. Maybe I tried to cover many fronts in a single idea and should be more specific. Thank you for your kind reply. Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP UI brainstorm...
It's a good idea, but I think you should add a little explaination and a voting system (like digg's one) to get some statistics of the degree of popular aproval of each idea (but I'm not saying that the voting should be considered for implementation, just statistics). A little text explaining the idea would let the visitors understand better the idea. In the mockups I sent you can clearly understand the basic behaviour just looking the screenshots and the title, but there are other aspects that are important too, about the grouping of the windows in a single taskbar button, the new menu arrangement and the tool windows being dependant of the splash or the document windows. It would be nice to have that kind of clarifications too. Also I think that not allowing comments avoids the possibility to participate in an existing thread and suggest improvements. But otoh, it would require someone moderating that blog, so I understand why not. Thank you for the site! Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] features discussion for future Gimp abilities
Gimp is a bitmap image manipulation program, so adding vector graphics for other task than supporting image manipulation procedures (i.e. selecting) is quite out of place. IIrc some primitive shapes are already provided by plugins using xfig, and you can easily create some vector shapes using the path tool (wich is excellent in Gimp, btw) in combination with the tools for converting paths into strokes or selections. If it isn't enough for you, you can import SVG files (which is an standard format supported by most of the modern vector graphics applications) as paths. If it's still not enough for you, it's clear that you're looking for a vector illustration/design program. As you've been told, Inkscape is a great program. If you think is that far behind Corel Draw or Illustrator I guess you haven't used it enough. Using Inkscape in combination with Gimp is like using Photoshop+Illustrator, or Corel Draw+Corel Photopaint. Even those mainstream programs didn't go that way (mixing vectors and raster in the same program) and when they tried to do it, they became ugly bloatware. Corel Draw is one. I wouldn't see Gimp become a 200 MB package with lots of unuseful features that obstaculize its main goal, which is the manipulation of bitmap images. There's a lot of features and enhancements that Gimp needs, but this, imho, is not one of them. Anyway, feel free to follow this discussion off-list with if you want to. I have intentions of opening an unofficial space for functionality discussion (maybe a wiki), to avoid disturbing developers in this list. Regards, Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hue-Saturation tool with gradients
Liam wrote: My own feeling is that it would be better to wait until there is some experience with the post-2.4 GIMP and higher definition colour models before changing any of the colour tools. Our intention is to describe a usage scenario and brainstorm a possible interface for the tool, as well as possible enhancements for that tool. Once we have a solid description and mockup we'll back to this list to propose the changes to the developers, but not with a simple idea but with complete documentation of the case. Anyway, this work is intended for 2.6, so I think it won't harm anyone if we discuss this off-list and try to gather some fresh ideas. Regards, Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hue-Saturation tool with gradients
My previous message replied by Danko was intended to be off-list to avoid the noise and personal opinions, but somehow it ended here, so I'd like to clarify. When I say that one must convince developers I mean by providing strong arguments in favor of the proposed solution/feature. Not just repeating and harrasing developers with demands. I wanted to continue this discussion about the refactoring of the Hue/Saturation tool off-list to avoid unnecessary details of the process, and bring it back to the list later when the usage description and more advanced mockups are ready. If somebody is interested in participating in this process please send me an e-mail so we can coordinate efforts with Danko and Marius Regards, Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Hue-Saturation tool with gradients
Marius B wrote: Hi, It seems that nobody is interested in this enhancement, but IMO it`s a nice feature that is worth discussing. I would like to hear your opinion about my mockup of this dialog http://bugzilla.gnome.org/attachment.cgi?id=92732 in bugreport http://bugzilla.gnome.org/show_bug.cgi?id=461658 I know it`s not perfect, but it`s obvious for me, that the current one needs some redesign. Please correct me if I'm wrong, but that mockup basically aims to change the aspect of the dialog without adding any enhancement. The tool does exactly the same but the dialog looks like Photoshop's one. The only improvement I see is the ability to see the actual influence of the overlap value on the color gradient, wich is cool, but I don't know if it's cool enough to change the whole dialog, that already works fine. Maybe it would be better for future versions to redesign the dialog adding some real enhancements to the tool, like arbitrary 3-point gradient selection and/or a curve for tweaking. In that case, the use of a wheel is better than a linear scale because it matches better with the well known color wheel scheme. Gez. p.s.: I support the idea that Campbell Barton suggested a couple of days ago. Maybe it would be better to create a new mailing list focused on functionality discussion. This would avoid the frequent conflict user requests vs. developers priorities and would bring some fresh ideas for the project. I don't want to bug any developer with functionality requests if this list is only focused on coding, but I'd really like to have a place for discussing features and useability issues that are also very important for the overall quality of Gimp. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Downscaling quality.
Anyway, there is no point at all in pointing out how important such a change would be. Several people have tried to improve the downscaling quality over the last two years. Do you seriously suggest that we wait another two years with GIMP 2.4? I'm reading my previous comments and I can't find the part where I suggest such thing. I'm trying to say that if this version took 2.4 years of development, it would be a pitty if all the new stuff come together with this long time issue. So unless you have a patch that we can apply immidiately, this discussion is pointless. Thanks for remembering me how pointless are my suggestions. Again. iirc you complained about my agressive tone few days ago when I posted about the jpeg quality. But you don't hesitate if yu have to use this harsh tone with others. I'm polite enough and won't respond with the same sledgehammer charm, luckily. I'll be back in a couple of years, when I'll be able to create a patch. Maybe you'll show some respect then. There are scripts available for scaling down in several steps. Just use them. You're absolutely right. This discussion is pointless. If you suggest that a script for scaling down in several steps is a valid solution you know as much about image manipulation as I do about coding. So don't waste each other's time. I'd be happy if you choose to listen to the users, even if they can't make a patch. But since the first time I was here, I see the same: every suggestion a user makes, you almost call him stupid. Please read your reply and David Gower's one. Can you see the difference? Is it so difficult for you to be more polite? I'm out of here. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Downscaling quality.
A couple of weeks ago somebody commented about the quality of the downscaling in Gimp. iirc there was a patch that improved the quality (that was bumped for future releases) and there was a discussion about the pertinence of the different names of the algorithms in the interface. Well, I know that this kind of requests are not welcome when a new release is so near, but I've been using Gimp a little more this days for small images (my previous works were for print or signs, so I didn't find this issue to be critic), but now I do and I'd like to share my experiences and my concerns. I'm working in a website right now, and one of the most frequent operations is to reduce images. I coudn't get a decent reduction using the different algorithms. If you have to reduce a very large image to, say 800 px, you can use oversampling and you get a decent result, but when you're working on images for the web, which are frequently smaller than 100px, the results are very bad. If you use oversampling, the result is a blurred image. If you don't you get jagged edges.This is particularly visible when you work with type, logotipes or high contrast images. If you perform the transformation just once, the imperfections are visible. But the big problem comes when you have to perform transformations a couple of times. And this operations are not rare. It's very common to scale down an image, rotate it and then tweak the size again. The last time I mentioned this, Sven replied: I might be wrong but I think the current algorithms are basically the same as the ones used in GIMP 2.2. So there's really no point in addressing this long-standing but minor issue before 2.4. I thought then that it was ok, but I've changed my mind. It's not minor at all. Since Gimp doesn't support CMYK, it is not a viable tool for image processing for print, so we have a tool mostly for screen works. One of the main professional applications for that is preparing images for the web, and this issue is critic for that kind of work. As a little example, I had to create a button for changing a website's language. I had a high resolution flag of the UK and wanted to reduce it. I coudn't get the image right, by any means. I had to re-draw it using single pixels (I know that diagonal lines are difficult to represent in small sizes, so don't start to call me stupid. I made the same work before with other software and got better results). The release of the 2.4 will be a huge event. The program went through very important changes, and it's becoming a truly professional application. If you compare 2.3.x with 2.2.x the difference is impressive. Now Gimp looks and feel professional. It would be a shame to inherit that limitation from 2.2 series and have to wait until the next version (which, considering the whole GEGL thing. won't be ready soon). Please don't take this comments as another stupid user request. This is very important and for me is the major issue that obstaculizes my migation to Gimp. I'd like to have CMYK, of course, but color management is enough for now, since CMYK is not a small change. I'm not telling that's a small change either, but I think it's critic enough to take a look before 2.4 I've discussed this with several users and they share my point of view. I'd like to know what you guys think about it, and if it's possible, revise the situation before 2.4 Thanks in advance, Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Downscaling quality.
David Gowers wrote: Perhaps you mean supersampling? Yes, it must be. I'm using a spanish localization of Gimp and try to guess the correct translation. Is there a command line option to launch gimp in english (just once, not permanent) so I can use the correct words when I'm reporting a bug or discussing something like this? For now, you should rotate before scaling down if possible. Yes, I try to do it. But it isn't always possible. Most of the times you have to make minor adjustments, and that progressively destroys image data. The opaque copy of the original tends to make the process of tweaking longer, because you can't see the context. Making the original image semi-transparent would be a great help. Presently, the solution to this is to scale down incrementally (reduce scale by 50% until you approach the desired scale, and then scale down to that exact size.) Nice tip. I'll try it. It's not that comfortable but at least is a workaround. Maybe GIMP could implement the above workaround before 2.4. It would be inefficient (scaling down the image N times instead of once) but it would mean that the result was correctly dependant on ALL the source pixels. Yes, this sounds interesting. I'd prefer a little slower transformation if the image quality isn't so compromised. Non-destructive transformation is something that would be more sensible to implement after 2.4. Yes, sure. Non-destructive transformation with GEGL will be great. But it won't be here inmediately, and it would be great to have not-so-destructive transformations while we wait. Thanks for your reply, David. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Request for Change 0 Free Select Behavior
David Gowers wrote: Yes, I'm aware of that. I mean to perform boolean operations on the paths tehmselves. Well I think that GIMP should avoid doing that, and instead expect you to do it with inkscape; transfer of paths between the two programs is very simple and inkscape's just plain better at path editing. I'm not talking about vector illustration. I'm rather thinking about options for combine visible layers in the paths dialog. It would be nice to have a pop up window when you choose that option, letting you choose between different boolean operations. For instance: if you have a road sign, and you created a path for the sign, and another for the pole, if you combine those layers the parts that intersect are excluded (that's the default behaviour of the combination and that's ok). But sometimes you need to join the paths or substract a part. I know that's possible using the selections and channels, but that makes you go through several steps. And sometimes you need a single path (most frequently for keep the file clean without hundreds of layers). Using the selection and turning it back to paths can be a workaround, but it's not 100% accurate and it's not the most handy thing. I noticed this issue a couple of days ago while creating a file for big format print and cutout. I needed to export the vector paths for the cutting shape, and -as I had to isolate the images using gimp, the most handy way to do it would be to make the path just one and re-utilize it later. It wasn't impossible and I made it with selections and exported the paths and combined them later in inkscape, but having a one-step combine would been a very important productivity enhancement. Oh, btw. Another thing I was wondering: Is there a way to straighten a single path segment in the bezier tool? Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Request for Change 0 Free Select Behavior
David Gowers wrote: You can already do that. Right-click in the Paths dialog, all the standard operations (replace, add, subtract, intersect) are available. Unless you mean boolean operations that modify the paths themselves, rather than the selection. GIMP doesn't have that. Yes, I'm aware of that. I mean to perform boolean operations on the paths tehmselves. Anyway the current behaviour is functional (performing boolean operations on the selection using the paths layers as input) so this can be an interesting enhancement but not an urgent one. Oh, btw. I'm experiencing some troubles with SIOX. I thought this was a known bug that had already been fixed in SVN. I'm having that problem in Gimp 2.3.18 and the fix is not announced in the latest realese. Can you confirm if that was actually addressed? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Request for Change 0 Free Select Behavior
Stephen: The Bezier tool is better suited to the tasks you're describing. Using freehand tool as a precision tool (i.e. for background extraction) is a bad idea. Freehand tool is intended to make coarse selections or tweaks in selections that don't need too much precision. I'd reccomend you this workflow for background extraction: -Draw a path along the edges of the shape that you want to extract, draw other paths for the holes (if you create them in the same path layer they are automatically combined with the other paths forming holes). -Turn path into selection -Add a mask channel based on that selection. So, imo, the existence of better tools for the same procedure makes this request questionable. If you ask me, I'd love to have the ability to apply boolean operations between different paths before seeing further work on the free selection tool. Your other proposal (selection stack) is very interesting, but sounds quite difficult tu implement. I'm not thinking exactly in your examples, but in the possibility to transform different selection levels independently (i.e. you selected 3 circles and you want to adjust the size of the first one). Oh, btw. I'm experiencing some troubles with SIOX. In some images (I couldn't figure it out exactly when it happens) after the initial coarse selection the mask is displaced to the lower left of the image (with the right shape, but completely misaligned with the image) making it impossible to perform the extraction. Is that a known bug or it's just me? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
So I broke my promess. creating interaction requires making hard choices, because you cannot make an application for everybody. I have to agree. A good UI doesn't do what users ask. It does what is better for the users. ;-) This approach of taking the lossy format to an import/export section instead of open/save is very interesting and, even though users will have to get used to, will define a more robust professional workflow. For now, the Save as patch is a good temporal fix. What's very important is that the problem of the arbitrary behaviour of the jpeg saving was addressed and users who ignore the whole issue won't be wrecking their images anymore. Thanks! Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
There is another player in the game and that's the last-used values stored with gimp_[gs]et_data(). And that's what has bitten Guillermo. He has saved an image as JPEG with low quality settings. No, I haven't. Since I know the problem I'm using always save as with quality=95 but it's still happening when I get an image from the camera and press save. I know it because I just made a test with the same results. Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
Scott wrote: I am so glad that Guillermo stuck by his guns and apparently *finally* got the developers to realise the illogic of this feature. Scott: Please keep in mind that I was trying to collaborate, not to fight. In these cases is very common to see differences of criteria and some rough defenses. Sven and the people working here are using their free time to improve gimp, and have no obligation to do what users ask. I tried to stick in my position because I find this problem to be critic (because it implies the undoable destruction of image data). But remember that Gimp is free software and it grows with collaboration. Very frequent conflicts may dilute the enthusiasm of contributors (both developers and users). Anyway I'm glad to have started this thread. I can see that much positive things came up, and that was my goal. Not to win, just help to address a problem from my non-developer position. Sven wrote: Can we settle this now and get back to work? Thanks. Yes. This is my last message for this topic. Promess. :-) Thanks! ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
OMG, at last! That's what I was trying to say since the beginning. I know jpeg is a lossy format (I knew that for at least ten years). I know, and always knew, that it has generational degradation. I didn't know that PS compression scale doesn't follow the jpeg specification. Thanks for the information, I know it now. Despite the scale thing, most of the people know that jpeg loses image information. I don't know the internal structure of a jpeg file, but please don't tell me. I'm talking from the user perspective here. What I didn't know (and wouldn't expect) is that Gimp will destroy my pictures without warning me. And that's exactly what I get. I have a picture taken at 95, open it and save it, and it ends up at 85. Why is that? I'm a professional designer. I'm not using jpeg for professional work. I used tiff and PSD with PS and now I'm using xcf. I know that. Don't try to explain me how to work, because I know it. But I'm a person too, not just a designer, and use to take some family pictures. The camera that I use (an old Nikon Coolpix 800) saves in jpeg and tiff format. Tiff format is huge and slow, jpeg is more handy. During a weekend with my family, I took a couple of pictures. Some of them were under-exposed. It doesn't matter. I open them, tweak the curves a little, and save them, for instance. Nobody will be using other formats for intermediate work in such case. It's a single tweaking. This is a VERY COMMON practice. And if you think that is perfectly normal that the program recompresses the images without warning, let me tell you that you're wrong. As others already said: One expects that a fine quality picture from a camera will be saved with a similar quality. Not a half. If gimp can't read the quality setting from the image, then it should display the export settings EVERY TIME you save a jpeg image as jpeg. Destroyed image data is not a expectable feature. Sven wrote: Why should any application do what you suggest? If you open a JPEG file and save it again as JPEG, then the original quality factor is completely irrelevant. You are doing a lossy operation, there is no way to save the file with the same quality again. Yes, but if you had a great looking photo you don't expect to have a heavily compressed image with lots of artifacts, bad edges and color bleeding. You expect a similar quality. If once the image is decoded the quality factor doesn't matter anymore, why don't you display the export options when saving? It would make sense to do that. The user wants control over the exporting process, but for now Gimp is taking the decision for him. Sven wrote: Due to the way file plug-ins are implemented in GIMP, it is not trivial to do this. But you can easily work around it by assigning Ctrl-S to Save As. Then you will always be prompted with the dialog asking you for the save parameters. The problem is not me. I know the problem now and I won't use CTRL+S for mi jpegs anymore. I'm concerned about lots of users that will learn that too in the hard way, destroying some irreplaceable images. There seems to be a big gap between developers and users here. Developers base their opinions on technical issues but seem to forget the problems that pop up in the everyday use. I'm a user, I plan to keep using Gimp everyday, and this jpeg exporting issue is (from the user perspective) definitively a PROBLEM. From the user perspective, the way that Gimp processes the jpeg images now isn't tha obvious. I had to start this discussion here to find out how it works, and now I have it clear. But what happens with the thousands of users out there? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
So please calm down and let the developers deal with this. After all this is a developer list. Your harsh comments are not helpful. I'm not being harsh. At least it wasn't my intention. In fact, this list is commonly considered to be harsh by many people, but now I learn that there's sensitive people here :-) I'm just trying to explain my point. I just want to help the project with my experience as a user, because I can't code. What makes sense for you, may not make sense for users. You find the quality setting of the original file to be irrelevant, but obviously it isn't irrelevant for regular users like me. Because you are using JPEG despite better knowledge that it will do exactly that. If you say that a user must understand the jpeg internal structure before saving a single image, there's no much to talk about. I'll uninstall Gimp and will be working with Imagemagick via command line for processing my images. :-p Seriously talking: Gimp is a program with a GUI, it's having great useability improvements. It's obviously a program to be used by users, not just by developers. For a user, a non-linear scale and a destructive re-save without a warning are not obvious things. I already explained that the JPEG plug-in cannot access the settings that were used to save the file. We can also not easily change the code to always show the settings dialog because then we would have to do show the dialog for all file plug-ins. There might be a way out of this, but there is certainly not an easy one. This is very different. If that had been your first answer I wouldn't say anything else. The problem is real, but the solution isn't that easy because it implies a complete change in the saving plugins? That's fine. But don't start saying that the problem doesn't exist or it's irrelevant, because it is not. Anyway, don't think I'm pissed off. I'm cool with all the replies. We may agree or not, but we all try to take Gimp to a higher level (some people coding, some people using it and trying to report problems like this). :-) Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
Thanks everybody for your replies. It's more clear for me now. - Compression factor isn't linear and in IJG, and that factor doesn't represent a percentage. - Photoshop converted its scale for making it more intuitive, but it has nothing to do with the right IJG scale. Thanks Michael for the link for the jpeg FAQs. It's very clear in the item 5: * Recent Apple software uses an 0-100 scale that has nothing to do with the IJG scale (their Q 50 is about the same as Q 80 on the IJG scale). It's clear that photoshop uses that scale. Tor wrote: It is just a number whose exact meaning you will have to check from the libjpeg sources in GIMP's case. It is just a coincidence that both programs in this case happen to use a scale from 1 to 100. That's the problem: That coincidence. The 1-100 scale is commonly used for percentages, and everybody tends to take it as that. My problem isn't that I can't understand how jpeg works... My problem is that I'm used to take 1-100 scales as a percentage. I'm pretty sure that I'm not the only one. gg wrote: Maybe you should try adjusting the compression level on the camera, it maybe a simple A,B or C choice and is probably not presented as jpeg quality. The images I get from the camera are fine. My problem is that if adjust them, scale them and re-save them without explicitly change the quality setting they turn out really distorted. Even though I understand (now) the difference between that scales, I'm still concerned about that quality loss in my images. I repeat: I just open them from the camera and they look great (Nikon Coolpix 800), adjust levels, curves and color (they still look great), scale them down, and save them using CTRL+S. When I re-open them they are distorted. I'm not talking about repetitive openings and saves. I dont use PS but my guess is that there is no real difference in the implementation , simply in the way this parameter is presented to the user. That was my whole point. If the quality is presented as a scale between 0 and 100 the user assumes that is the same 0-100% of photoshop and other programs. That happened to me. People is always more comfortable with linear scales, they are easier to understand. If the compression factor isn't linear, photoshop must have linearized it for translating that into a sort of porcentage of quality and make it easier to understand. It goes against the IJG scale, but unfortunately this different scale is now more popular than the right one. Does that tie in with your experience? Yes, it does. I can see you understand my point. We, the users, tend to assume things based on the information we get on screen.It should be considered as a useability factor, imo. Developers see it from the technical perspective, but users don't. Users want to have things done. Now, with all these replies I can understand it, but it won't take too long to see a user complaining for the same thing. It's very clear that Photoshop doesn't use the IJG scale, but it should. Users who came from PS are used to that incorrect scale, and find this difference. I think it should be documented in the Gimp Manual and FAQs. It's not a minor issue. Thanks everybody for your explainations! ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
It seems that we're understanding each other. :-) [EMAIL PROTECTED] escribió: yes there does seem to be an issue here. I snipped the generation 0 part of that image did File | Save As... then reopened the new version and repeated the save several times. There is continual degradation. This should not happen with an identical image. This seems to suggest that either there is a bug in the compression or that the decompression is not producing an identical image from the stored data. The explaination from Øyvind K. clarifies exactly what I'm going through, and his proposal makes sense for me. Photoshop always shows a save as-like dialog when you save a JPEG from the camera for the first time, letting you adjust the compression. If I press CTRL+S in Gimp, it saves the file and destroys it. That's where de difference is. Please, keep in mind that I'm not asking to turn Gimp into a Photoshop clone. I've changed not for the money, but for the freedom. So save the Gimp != PS stuff. I know it and I'm ok with that. :) (BTW... after a couple of months with Gimp, when I go back to PS I totally hate it. I haven't CMYK but I have other things that I love. I had to make a sign of 30.000 x 11.000 pixels with lots of layers and Gimp worked fine, while Photoshop choked). Back to the topic: I propose to display the quality settings when an image is resaved as jpeg for the first time, if it's possible. I don't know how it's done, but when I take my image to PS from my camera, it asks me to adjust the quality when I press CTRL+S for the first time. After that it saves normally. I repeat: Now I understand the scale used in gimp for the quality. I know that jpeg is a lossy format and my camera uses it and it destroys image data because of that, I always knew that, but that's not my problem here. My only issue now is the first save of a jpeg from the camera without changing the quality (using just CTRL+S) recompresses too much the image. The first time I open the image (directly from the camera) it doesn't look over compressed. If I save it, it is recompressed too agressively (or at least it looks like that). Nothing warns me it will happen, it just happens and I don't know why. I made the comparison with PS because it doesn't happen there. Just like a reference. Thank you for your time! ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
GG: Can you clarify where this file is when you do CTRL+S ? You say you open directly from the camera , do you mean you are opening a file that is still on the camera ?! My camera stores the pictures in a Compact Flash card. I use a card reader. I copy those files to my hard drive, then I open them with gimp (or gthumb for viewing.) Sometimes I open them directly from the CF card, but it's almost the same, it's a storage medium anyway. I have not checked the source code but I would expect gimp to retain the existing quality setting of the image defined in the jpeg header, in this case determined by you camera. If you can demonstrate this is not happening it probably needs checking. That's precisely what I was trying to say. Is it possible that the quality setting defined in the jpeg header by the camera isn't in the IJG scale? (excuse my ignorance... I don't know how the file is structured). If that happens, is it possible that Gimp is taking the wrong setting as reference from the file? If you want to choose a different compression you should be using File | Save As rather than File | Save . Yes, I'm doing that now. But I learned that in the tough way :-) You also say when I take my image to PS from my camera , could you me more precise about the operations you are using? Are you opening a file on the camera , are you removing it from the camera and putting it elsewhere with this operation, when you CTRL-S in PS where does it get saved, back to the original file or elsewhere on your disk? Steps: 1- take the photo. 2- put the card in the reader and copy the photo to the disk. 3- open it with the image manipulation program 4- save it using CTRL+S In Gimp, it saves the file directly, without asking for the compression setting. Result: an image over-compressed with artifacts. Smaller size than the original. In Photoshop, it shows the quality settings the first time you hit CTRL+S. As I said in my last post Øyvind's test shows there is an issue with degradation on multiple resaves , I dont think this caused by 'quality' parameter being changed. You may have picked a bug and you are misinterpreting this as a change in the compression. Yes, I think so. At first I thought it was a quality setting issue, but since I learned how the IJG scale works I'm convinced that is a bug or, at least, a strange behaviour. Gez ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] jpeg quality factor.
I'm noticing big differences between jpeg files from gimp and photoshop. The same image exported as jpeg with the same quality factor (let's take 75% as an example) gives very different results in both programs. In my tests, Photoshop image has better image quality, but its size is 75 KB. Gimp image shows lots of artifacts and its quality is lower, but its size is 35 KB. Doing more tests I found that the factor 75% of Photoshop is equivalent to the 93% in gimp. Conclusion: Both programs calculate the compression ratio differently. I'd like to know how the compression factor is set (if gimp or the jpeg library manages that). Most people consider Photoshop as a industry standard (which is not, but is a de facto standard) so I'd like to know which program isn't working as it should (I mean, if the qualiy factor is 80%, and the compression algorythm is the same, it sounds ilogical to get different results). I'm worried about that, because one who cames from photoshop to gimp may thing that Gimp jpg files have less quality than photoshop ones. In my personal experience, I find the default compression quality of the jpeg in Gimp to be very destructive. And I don't know if it happens because gimp uses the compression factor from the file and recompresses to its own equivalent. Trying to be more specific: If I open an image from my digital camera with gimp, adjusts its levels or curves, and re-save it, the saved image is very deteriorated. If I do the same with Photoshop that doesn't happen. I think it's problem, but let me know if I'm wrong. At least I know that I must re-save images from other sources using a higher quality factor. Regards, Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
Mark. Thank you for your reply. I'd like to clarify some of my comments. You obviously have to compare qualities at similar filesizes. Everything else is irreelvant. I don't think the way the quality is expressed (I know, it's not quality but compression ratio) is irrelevant. If you came from a program where you saved at 70% and it gave you a high quality image, when you save at 70% and you get an image with heavy compression artifacts, it matters. Don't get me wrong, I'm not asking do it like photoshop, but for the user it's confusing. The first thing that crossed my mind saving a jpeg with gimp was it sucks at 70%... Had to look at the filesize to figure that the 70% of Gimp was not the 70% of Photoshop. You'll say it doesn't matter, Gimp is not Photoshop, and that's ok. But I'm a designer, worked more than 10 years with Photoshop and switched to Gimp a couple of months ago. I'm sure that I'm not the only one following that path. Maybe it's a good idea to document this difference and/or display a warning in the exporter. It is free software, you can look at how it does things any time you want. I know and I'd love to. But I'm not a coder, just a user. Uneducated and jumpy people might jump to all sorts of conclusions - that generally is their problem. I'm not an uneducated or jumpy person, but I swear that the first thing I thought was something is wrong with the jpeg exporter. Higher than? JEPG images do not store a quality factor, and the very notion of using the same quality is simply not achievable with a lossy format such as JPEG. In Gimp the compression factor is expressed as quality factor. So 100% is the best and 0% is the worst. If it would be labeled as compression ratio, more compression should be the worst. When I mention quality I'm meaning the % selected during the export, not the perceptible image quality. I know it's lossy compression and I know it's impossible to get the same quality. In the terms that the percentage is expressed in the export dialog, the user will think that, in a scale between the best and the worst quality achievable with jpeg compression, a 70% is a 70%. Well, 70% isn't the same in Gimp and in Photoshop. And it doesn't sound very logical. That's what I'm talking about. Regards, Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
Owen: Interesting, what platform are you using? Ubuntu Linux (7.04) and Gimp 2.3.18 Here if I can do say 10 re-saves at 85% quality, it produces no discernible changes in picture quality. In fact I have tried to prove that recompressing jpg pictures reduces the picture quality and got bored doing it at 85% (which btw is the Gimp default) I can't say the same. Today my wife uploaded a couple of photos to her flickr, and she noticed the same. http://www.flickr.com/photos/superdd/738669627/ Se only opened the image from the camera, adjusted the curves, and scaled it down (BTW, the downscale code should do oversamplig by default. It always breaks a little the edges). Until she saved, the image quality was good. Then she saved with CTRL+S, without changing the quality factor, and the picture turned out like that. Heavily compressed. Opinion. Y You should never work on a jpeg, take it in off your camera, save it as an xcf and when finished, recreate it as a jpeg if you want. Of course. I always do that. I use XCF (or PNG if the image is a single layer) for work. But usually I take the pictures from my digital camera and make a quick levels and color adjustment, and that's when the problem pops up. If you just want to adjust a bunch of pictures from your camera, it's not very handy to save the pictures as XCF. It takes more space and it's not a very popular format for viewers of other platforms. Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Mouse problems using Wacom tablets
Luis wrote: I tried to install Inkscape Fedora RPM, but for some reason the last repository version seems highly broken (at least with my package setup). I should compile it by myself when I have some time (lots of libraries and dependencies). There are autopackages available at the inkscape website. You can choose the latest stable version or svn compilations. It's not the cleanest way to install a package, but it will work for your tests. Anyway, your problem description is EXACTLY mine. Did you try disabling the eraser (not the stylus)? In that way, the mouse works (but not the eraser, of course). You should move the stylus to 'activate' the mouse. Is this also the behavior in Inkscape? My pen hasn't an eraser (it isn't a Wacom) so I can't tell. What I could see is the same in Gimp and in Inkscape. Once you've used the tablet, it seems to catch the pointer, and the mouse becomes unuseful for the app. But if you close the program, everything works as it should. I'm guessing it's a GTK problem because Gimp and Inkscape share the same menu for activating the tablet. But I really don't know if I'm right. Somebody pointed here that is a problem fixed in the newest versions of gtk+ and linuxwacom, but I'll have to wait those libraries to be in the Ubuntu repos, since I'm not so comfortable experimenting with that kind of libraries (GTK mostly, I don't want to break something if I don't know how to fix it - at least in my computer for work :-p). G. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Mouse problems using Wacom tablets (was 2.3.18 deletes exif...)
For a long time, nothing has changed in GIMP with respect to XInput devices. So the fact that an upgrade introduced this problem seems to be a strong indication that the problem is elsewhere. I have similar problems using a Genius tablet. Once I used the pen, mouse is no longer detected in the canvas. But I think is a GTK+xorg issue and not Gimp's one, because the same seems to happen in Inkscape. Luis, you should try with inkscape as well (remember to activate the tablet as an input device). Besides of that, the device driver for my Genius tablet seems to be completely broken for GTK apps under Ubuntu Feisty Fawn (it worked in the previous version). I think it's a GTK problem and not Xorg's one, because MyPaint works fine, but gimp and inkscape don't. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Autocrop Layer function behaviour
I'm using 2.3.18 and I noticed that if I apply the autocrop layer function twice, it crops the entire image to the layer dimensions. It's like if you apply autocrop layer on a layer that has been cropped it acts like the autocrop image feature (of the image menu). It didn't happen with 2.3.16. 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 Digest, Vol 57, Issue 11
Hi, I'm writing and testing the new ICC profile selection dialog box. Separate+ includes this dialog since 20070610 release. Please try it, and tell me any ideas. Separate+ plug-in is available at: http://cue.yellowmagic.info/softwares/separate.htm Wow! This is so interesting! Is there any chance to see this plugin and the Save for web plugin in Gimp 2.4 as part of the default installation? The separate+ plugin would be a great help for those who need CMYK until de GEGL integration. Gez ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] improving image scale: reduction
From the user perspective, the downscaling quality is very important. More if you consider using GIMP for web graphics production, where downscaling is one of the most frequent operations. It would be nice if this problem is addressed before 2.4 I understand the stability risk being so close to the release of the 2.4 version, but if someone has an improvement in this field and can be added, it well be welcome. I wouldn't say it's a critic item, but the current algorithms are right now quite sub-standard. Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] 2.3.17 crashes using levels or curves.
Hi. I'm working with Gimp 2.3.17 and having a persistent crash when using levels or curves. As far as I could test it, it happens on layers. If the file is a JPG or a PNG (with or without alpha) it works fine, but if you create a new file, place a layer using copy+paste or dragging a file (i.e. a transparent png) into a layer, if you use curves or levels, you get a crash. I've never had a crash like this in previous versions, and I have this all the time. Steps to reproduce the bug: 1) create a new image. 2) open a transparent PNG 3) copy the image into a new layer in the image you just created 4) scale it down to make it fit 5) adjust curves or levels. ... crash. Here's the debug output: *** glibc detected *** gimp-2.3: realloc(): invalid pointer: 0x094b8100 *** === Backtrace: = /lib/tls/i686/cmov/libc.so.6(realloc+0x392)[0xb7534322] /usr/lib/libglib-2.0.so.0(g_realloc+0x3b)[0xb765718b] /usr/lib/libgobject-2.0.so.0(g_object_weak_ref+0x91)[0xb76d0db1] /usr/lib/libgobject-2.0.so.0(g_object_add_weak_pointer+0x5d)[0xb76d0ead] /usr/lib/libgdk-x11-2.0.so.0[0xb7ad0aeb] /usr/lib/libgdk-x11-2.0.so.0(_gdk_windowing_window_queue_antiexpose+0x35)[0xb7ad0c65] /usr/lib/libgdk-x11-2.0.so.0[0xb7ab855f] /usr/lib/libgdk-x11-2.0.so.0(gdk_window_process_all_updates+0x97)[0xb7ab8887] /usr/lib/libgtk-x11-2.0.so.0[0xb7bbca52] /usr/lib/libglib-2.0.so.0[0xb764e091] /usr/lib/libglib-2.0.so.0(g_main_context_dispatch+0x182)[0xb764fdf2] /usr/lib/libglib-2.0.so.0[0xb7652dcf] /usr/lib/libglib-2.0.so.0(g_main_loop_run+0x1a9)[0xb7653179] gimp-2.3[0x80674d9] gimp-2.3[0x8068458] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xdc)[0xb74deebc] gimp-2.3[0x80671d1] === Memory map: 08048000-083b8000 r-xp 08:01 961912 /usr/local/bin/gimp-2.3 083b8000-083cc000 rw-p 0036f000 08:01 961912 /usr/local/bin/gimp-2.3 083cc000-09592000 rw-p 083cc000 00:00 0 [heap] b0dd6000-b0de1000 r-xp 08:01 260672 /lib/libgcc_s.so.1 b0de1000-b0de2000 rw-p a000 08:01 260672 /lib/libgcc_s.so.1 b0df4000-b0df8000 rw-p b0df4000 00:00 0 b0df8000-b0dfb000 r-xp 08:01 1307958 /usr/local/lib/gimp/2.0/modules/libcdisplay_lcms.so b0dfb000-b0dfc000 rw-p 3000 08:01 1307958 /usr/local/lib/gimp/2.0/modules/libcdisplay_lcms.so b0dfc000-b0dfe000 rw-p b0dfc000 00:00 0 b0dfe000-b0dff000 ---p b0dfe000 00:00 0 b0dff000-b15ff000 rw-p b0dff000 00:00 0 b15ff000-b160 ---p b15ff000 00:00 0 b160-b1e25000 rw-p b160 00:00 0 b1e25000-b1f0 ---p b1e25000 00:00 0 b1f01000-b1f1 r-xp 08:01 260646 /lib/libbz2.so.1.0.3 b1f1-b1f11000 rw-p f000 08:01 260646 /lib/libbz2.so.1.0.3 b1f11000-b1f1e000 rw-p b1f11000 00:00 0 b1f1e000-b1f23000 rw-p b2fcb000 00:00 0 b1f23000-b1f53000 r-xp 08:01 815810 /usr/lib/libcroco-0.6.so.3.0.1 b1f53000-b1f56000 rw-p 0002f000 08:01 815810 /usr/lib/libcroco-0.6.so.3.0.1 b1f56000-b1f82000 r-xp 08:01 816064 /usr/lib/libgsf-1.so.114.0.3 b1f82000-b1f85000 rw-p 0002b000 08:01 816064 /usr/lib/libgsf-1.so.114.0.3 b1f85000-b1f86000 rw-p b1f85000 00:00 0 b1f86000-b1fb5000 r-xp 08:01 816330 /usr/lib/librsvg-2.so.2.16.0 b1fb5000-b1fb6000 rw-p 0002f000 08:01 816330 /usr/lib/librsvg-2.so.2.16.0 b1fb6000-b1fb7000 ---p b1fb6000 00:00 0 b1fb7000-b27b7000 rw-p b1fb7000 00:00 0 b27b7000-b27b8000 ---p b27b7000 00:00 0 b27b8000-b2fb8000 rw-p b27b8000 00:00 0 b2fb8000-b2fbf000 r-xp 08:01 815776 /usr/lib/libfam.so.0.0.0 b2fbf000-b2fc rw-p 6000 08:01 815776 /usr/lib/libfam.so.0.0.0 b2fc-b2fc6000 r-xp 08:01 260635 /lib/libacl.so.1.1.0 b2fc6000-b2fc7000 rw-p 5000 08:01 260635 /lib/libacl.so.1.1.0 b2fc8000-b2fcf000 rw-p b2fc8000 00:00 0 b2fcf000-b2fd2000 r--p 08:01 1206606 /usr/share/locale-langpack/es/LC_MESSAGES/atk10.mo b2fd2000-b2fd9000 r--p 08:01 1206638 /usr/share/locale-langpack/es/LC_MESSAGES/libgnomeui-2.0.mo b2fd9000-b300f000 r-xp 08:01 260726 /lib/libsepol.so.1 b300f000-b301 rw-p 00035000 08:01 260726 /lib/libsepol.so.1 b301-b301a000 rw-p b301 00:00 0 b301a000-b301d000 r-xp 08:01 816046 /usr/lib/libgpg-error.so.0.3.0 b301d000-b301e000 rw-p 2000 08:01 816046 /usr/lib/libgpg-error.so.0.3.0 b301e000-b306d000 r-xp 08:01 815929 /usr/lib/libgcrypt.so.11.2.2 b306d000-b306f000 rw-p 0004e000 08:01 815929 /usr/lib/libgcrypt.so.11.2.2 b306f000-b3083000 r-xp 08:01 816386 /usr/lib/libtasn1.so.3.0.6 b3083000-b3084000 rw-p 00013000 08:01 816386 /usr/lib/libtasn1.so.3.0.6 b3084000-b3144000 r-xp 08:01 815151 /usr/lib/libasound.so.2.0.0 b3144000-b3149000 rw-p 000bf000 08:01 81515gimp-2.3: terminated: Cancelado [EMAIL PROTECTED]:~$ (script-fu:6309): LibGimpBase-WARNING **: script-fu: wire_read(): error [EMAIL PROTECTED]:~$ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU
Re: [Gimp-developer] xHTML+CSS importer plugin
/gg wrote: These are just assumptions you are making , not a standard of any kind. They are not just assumptions: a DIV without class or ID or style is impossible to be visually formatted. So a clean div is just for conceptual delimitation. A DIV with one of those attributes can be -or not- visually formatted, so it depends on which css styles are applied. If you read the css information you can easily realize which are visual blocks and which are not. And about the standard thing, just refer to the W3C's Visual Formatting Model. There you can get information on which css attributes should be considered or not. It is a good idea in itself but since there is no fixed way this will be implemented by any web designer it's far too vague to start writing a plug-on for. If most of the web designers out there don't follow the standards, it doesn't make my suggestion too vague. Is a standard procedure. If programs like dreamweaver or even NVU skip the standards trying to make a user friendly program doesn't mean that those standards don't exist. This seems firmly outside what gimp has decided to be as an image editor. That's why I suggest a plugin. It seems that many people asked for slicing (which isn't a standard or a fixed way to design either, because there is no fixed ways to make things in design in general) as a core function of Gimp. I'm aganist it. So I suggested that xHTML+CSS importer plugin as an interesting approach for a similar use, but as an external, optional function. I'm not saying it's a must-be and Gimp must have it by default. It's just an idea. Thank you for your comments. 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 Digest, Vol 56, Issue 31
Michael wrote: nitpick You can still reach it via adjacent sibling, child or descendant selectors, or - if it does have any other attribute - an attribute selector. /nitpick Ouch! Yes, you're right! It's not impossible :-) But even in that situation it would be readable in the css stylesheet. I'm trying to imagine a situation where it wouldn't be parseable. Good point, anyway. The plugin should parse every div in the document and use the css information to decide which div is used for visual formatting. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] lgm 07, top???5 GIMP user requests...
[EMAIL PROTECTED] wrote: A great tool for designers would be a CSS layout importer (able to import divs containers and place them as layers with guides in the right plces). Sort of CSS-to-template. But imo, it should be a plugin, not a core function. That would seem like a good idea for plugin. Could you point to some definative info on this use of CSS div containers? It would have to be a well defined structure in order to be able to formalise it as a plugin. /gg The correct way to design a webpage using XHTML+CSS is separating contents and presentation. Contents are divided in blocks (usually divs) and line elements that are styled in a separate stylesheet. The interfase wireframe is defined by those divs, following the W3C visual formatting model. My idea for that plugin consists in importing those divs (which have with, height and a relative or absolute position in the document structure, and background color), into solid color layers. Once the XHTML+CSS wireframe is designed, the design of graphic elements for incusion in the DIV (images, div backgrounds or dummy texts) would be very fast to achieve, letting the designer to create a mockup in a breeze. And that fast editable mockup would be ready for exporting the slices (I know, I said slices are a bad idea, but i mean slices as image blocks) for the final webpage. Slices as they are meant in Photoshop are bad because you tend to design the whole page using the incorrect application. A webpage isn't bitmap images sliced. Is hypertextual content with bitmap decorations. Photoshop makes unexperienced people think that anyone can design a website, when in reality that's not true. If we focus in the right way, we'll be focusing in creating the bitmap decorations for a specific html element instead of creating the whole mockup and automagically export it to a html page. It's ok to listen to users feature requests, but if Gimp is going to be a professional application, IMO the un-professional features shouldn't be included. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] lgm 07, top???5 GIMP user requests...
Thanks, I'm aware of the basic principals. But if something is to be formalised into a plugin there has to be some well defined way of working. Preferably a standard, not just a couple of jargon words like slices and wireframe. Oh, I'm sorry, I misunderstood you. I'm not a programmer. I was rather talking as a webdesigner and focusing on what would be really useful for webdesign. In this case, the image slicing process was mentioned as one of the top user requests, so I wanted to bring my point of view about it. Please let me know if this kind of oppinions are not appropriate for this mailing list. I know this list is for developers, but there are other topics discussed here, like program functionalities and interface related. Gez ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] xHTML+CSS importer plugin
/gg wrote: There's nothing wrong with your suggesting an idea to the list. Your input as a web designer could be relevant if you can be specific. Can you be more precise than wireframe? I still dont know what you are wishing to see implemented. Ah, Ok. Look, I said wireframe meaning the structure of divs (with their heights, widths and background colors and relative position beetwen them) in a xhtml+css document. My idea for a plugin is to parse (i don't know if this term is correct) that information creating a new document with layers with solid fill with the same dimensions and placement that the div blocks of the source document have. So, a plugin or script for this should read the document and its css, and place the new layers in a blank image template. As a xhtml is a text file, the order of the div blocks will be consecutive. The divs with their width, height, floating and other styles related to the visual formatting model will have a class, ID or style applied to read from. The divs with other purposes (conceptual delimitation) won't, so they can be skipped. I haven't a coder background, so I cannot say how (and if it can be easy to implement or not), but I think that it's, at least, an interest idea. And it sounds logical to me. Maybe it would be possible to use an external rendering engine (gecko or so) for translating the html elements into graphical blocks. Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] lgm 07, top???5 GIMP user requests...
Peter said: - by creating only one item in the windows list, grouping GIMP's windows, instead of one item for each panel (it's quite confusing) I say no item in the window list. inspectors do not match users' goals, image windows do. I meant the items in the tray bar / lower panel of the O.S. desktop. The applications listing. Just one item Gimp instead of toolbox, image, docker as it appears now. My intuition tells me that such 'ms outlook' approach would work against the goal of GIMP being a high-end expert tool. I am much more enthusiastic about having the tip of the day in the main window in a 'no image' situation. And to have all new tips there, that can bring experienced users to the next level. To be honest, I had that idea when I was looking Ardour and Jokosher, then I realized hey, that's the same that the latest Adobe apps have!. It doesn't look to be working against Adobe Premiere Pro, Adobe After Effects and Adobe Encore (almost in the exact way I suggested) and Photoshop and Illustrator (in a similar way). So I'm not sure if it's incompatible with a high end, pro application. The tip of the day could be in that window too, and you'd have a great one-window solution for the whole problem. I think I should make a mockup. :-) We are investigating in the same direction at the moment, but I cannot decide for one million users that by default they can have either the tool options, or the color specifier. So I need to look for different compromises. Then Thorsten said this: As far as I got it, this is all in line with what Peter has been proposing. Where MDI would be an _option_ that could be tackled _after_ floating panels have been adressed. And this: Fine if that works for you and nice to see docking put to work for a custom layout. But I shudder on the thought of having to move the pointer from one side of the screen to the other, for tweakink tool options after picking a tool. Good points. In the ideal world, Gimp would have MDI and floating as options, and presetable layouts by default. But we know that gimp hasn't enough developers, and this kind of features were never adopted because of that. I was myself one of the guys asking for optional MDI/Floating some time ago, and Sven replied that: every option in the preferences carry an important effort in coding as well as several changes in documentation. That's why I'm suggesting this layout chnge. It would gain much screen space without the need of much coding and documentation changes. I'm pretty sure that most of the user asking for MDI wouldn't have much problems with the layout I'm proposing. It's more photoshop-esque, and to be honest, users who ask for MDI so frequently are doing that because of Photoshop mostly (see the trend point in Peter's report). Most of the users got used to the default layout maybe because never knew that it could be changed. I'd like to know how they feel about getting a 15% more of work area. Maybe there should be a poll in the website, proposing a couple of tool layouts. Oh, and about semi-transparent toolbox and docker... it can be really tricky. IMO, Semi transparent windows in interfaces should be avoided because it's readability depends on the contrast between the foreground and background elements. Some combinations work great, some combinations simply don't. And when they don't, the new problem is worse than the problem that was intended to solve: a confusing mix with deficient contrast is worse than a slight obstruction. And why not to mention that semi-transparent windows are alien to the default GTK/gnome style guidelines. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] lgm 07, top???5 GIMP user requests...
Sven wrote: I would actually want to have toplevel image windows listed in the task bar. But I don't see a point of having a GIMP item there. Palettes like the toolbox don't show up in the task bar anyway when they are set as utility windows. You can already configure GIMP to behave this way. Oh, I didn't know that. That's much better, but if you set both toolbox and docker as utility windows, if you haven't any image open you don't have any window listed in the taskbar nor the task switcher (alt+tab). Default behaviour clutters the taskbar and the other setting makes the application almost invisible if you refreshed the desktop using the show destop applet. I think most users see the windows listed in the taskbar as applications running or minimized instead of windows. That's why I find this behaviour to be quite confusing. About the image slicing for webmasters subject... I'm against it. Save for web is a necessary tool because is a time saver and allows to see the balance between quality and filesize, which is a must-be for web design. But slicing is a horrible methodology created for home users. A real web designer designs a wireframe and the typographic structure before the graphic stage, then designs the elements needed, using the div placement and dimensions defined in the css layout. I mean: If you completed the wireframe stage and you defined the block elements with CSS, image slicing is not necessary anymore. And in that case, the current GIMP features are more than enough. A great tool for designers would be a CSS layout importer (able to import divs containers and place them as layers with guides in the right plces). Sort of CSS-to-template. But imo, it should be a plugin, not a core function. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] lgm 07, top???5 GIMP user requests...
Fist of all, I want to thank Peter for his excellent work. I'm glad to see that several problems of GIMP's GUI are being revisited and most of the solutions suggested will be welcome in future releases. I don't agree with #1 request, though. I know that this has been a frequent request for years, but I think it's just a matter of habit. I'm a Photoshop user, and a Gimp user, too. After a couple of days I could understand the power of floating windows. Switching between floating windows and fullscreen with F11 is fast and easy, and my workflow is far better this way. And when I connected a second monitor it was even better. Floating windows ROCK! Turning Gimp into a MDI application will make several users happy, but IMO it won't benefit Gimp at all. I think it would be better to improve the way those floating windows work: - by creating only one item in the windows list, grouping GIMP's windows, instead of one item for each panel (it's quite confusing) - by making toolbox and dockers dependant of the canvas window. As it was discussed before, this brings a new problem: where should the menu bar be placed. Of course, the document window is the most ovbious choice, but as we use floating windows, it won't be any document window when we open the program. Maybe the best option is to create a new kind of splashscreen, where we get as options: -Create a new image (if you choose this, the new image dialog appears, with dimensions, templates, color mode, etc.) -Open existing image/s (if you choose this, the filer appears, letting you pick an image or a group of images). Once you made your choice, the toolbox and dockers will appear along the document/s window/s. (I'm thinking about something like the latest Adobe Premiere Pro initial screen, for instance, but in the GTK/floating windows fashion) Another thing that was covered in your work is the use of the screen space. I agree that the current menu layout is a waste of pixels. But this is already possible to improve in Gimp using the small theme and putting the tool options panel in the docker window. This allows you to shrink the toolbox, gaining much window space. You can see a screenshot of my current tool layout in gimp using that idea here: http://www.ohweb.com.ar/screenshots/Gimp-Screenshot.jpg Well, just my two cents. Thanks again for your work! Gez ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Low resolution proxy for faster previewing.
Sven Neumann escribió: I think this is because the entire data is being redrawn regardless the zoom factor That is a wrong assumption, only the visible area is being redrawn. Thanks for your reply and clarifications. I meant when a large image is zoomed out. Sorry if I didn't explain myself more clearly. I wanted to say that the actual pixels are redrawn, not just the pixels showed on screen. So, the conclusion is that we have to wait until the GEGL porting for this, isn't it? Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Low resolution proxy for faster previewing.
I don't know if this was answered before, but I've been browsing the archives and didn't find anything (if there was a discussion about this, please point me the thread URL for me to follow it). I'm using Gimp 2.3.15 under Ubuntu Linux, with the tile memory set in 1 GB. Even though the overall speed of preview/redrawing was improved a lot in the last development versions, I still find that is difficult to work with large images, because of the slow redrawing when moving layers, switching on/off large layers and panning the canvas when zoom factor is under 100%. In small resolutions, I have an excellent performance, but when I work with high res compositions with several layers I find this problem when I zoom them out (the brush redrawing also seems to be affected in this situation) I think this is because the entire data is being redrawn regardless the zoom factor (and this is not critic when the zoom is at 100% because the only part that is redrawn is the visible area). I've read that other programs as Photoshop do this in a different way when zoom is 100%: using a low resolution proxy of the actual layer for the inmediate rendering, and rendering the final resolution in the background. Is there any solution for this issue being worked or planned? For me (and other graphic designers) and for photography enthusiasts it would be very welcome. Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] One-click binary downloads via the gimp website
Although I made the first suggestion of the direct download link in the home page alla Mozilla, I can see why it would be problematic. Maybe it would be better if the link with OS detection redirects to a better organized and minimalistic download page, based on the information of the browser and OS. Then, in that download page, the user will read the information about that specific package, and all the kinds of disclaimers needed. If the locale of the browser is also readed by a proper script, that page could show the download link of the localized help file, and could list the most appropriate mirrors for that location. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] One-click binary downloads via the gimp website
I think it's wise not to get too exited about browser sniffing. ... A typical problem is sites like google.com redirecting me to google.es just because I happen to be abroad. This is about as helpful as your mate switching your mobile phone to Russian while you're not looking. ... The number of platforms supported is not going to scroll down two pages so lets not overdo the geeky I can tell what browser you're using routine. /my2c. Well, that's your experience... I have no problems downloading a windows binary from mozilla (for instance) because the browser detection is accompanied by clear information about alternate procedures: right below the download button suggested by the browser sniffing, there is an other systems and languages link. It's not a matter of being too exited with an I can tell you routine: is about how smart you are using that routine, and if it gives a plus to your site or not. If it's used properly, it will give a benefit to the less experienced user, if it's used just because the hype, it will suck. Let's try to be smart then... :-) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Looking for GIMP developers
It would be a lot easier to give a meaningful response to your question if you could clarify what the simpler needs of your users are. Yes, it would be a great if you give further details on what your needs are. Maybe your ideas are compatible with current bug fixes or feature requests and could be addressed by the developers, and the whole Gimp project could receive the benefit of your company's funding. AFAIK Gimp has few active developers who do an outstanding work without economic backup. So giving monetary support to the official project instead of thinking in external forks would be much better. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
