Re: [Gimp-user] Change background colour with GIMP 2.10.22
Zoltán, I am eager to know what other users have to say, whether on the list or directly to you, Zoltán. I have a similar application (stamps for collectors). I have experimented with various "green screen" techniques for years, and using other programs as well, but I have never been able to find anything that can fully do what I need to do. The problem for me is that sometimes the printed design of the stamp (which can be various colors), or the cancellation/postmark on the stamp goes to/over the edge of the stamp paper. Thus at that point (near the edge) there are problems with selections "eating into" the stamp area, etc., such as the selection following the area of the postmark into the stamp. We have also not been able to completely eliminate all vestiges of background color right up to the edge of the stamp's paper (keep in mind that on old stamps, not all edges are absolutely clear cut as they are on a modern stamp) -- this may be similar to Zoltán's problems at the edges of coins if the edge of the coin is not perfectly smooth. Since we never found a satisfactory solution in "old" GIMP we did not attempt to automate it back then (as Zoltán did), thus we don't have the problem of the automation no longer working well or quickly. However, our original problem remains as much as ever. We can get "sort of close", but that's just not good enough. And we need something we can use for making tens of thousands of stamp images. I will watch this thread with interest. Zoltán, I welcome learning any advice you can give as you solve your problem. Jay Smith On 03/23/2021 07:15 PM, Zoltán Kluik via gimp-user-list wrote: Dear GIMP users, I would like to ask your help regarding removing background and change it to white. I'm dealing with coin pictures mainly medieval silver coins. I take the photo about coins with green / dark green background. In the past on Ubuntu I used the GIMP 2.8.16 version where I applied the foreground selection tool. Here I just simple rounded the coin, press enter and the program after some seconds selected my coin. I loved this method, because it takes only seconds to select the coin. Last year I have upgraded GIMP to version 2.10.22, but from this time I have a big problem with time consumption and also with the quality of the changing the background. Now in 2.10.22 I open a picture, using foreground selection tool, but in this version there is a motor feature where I can select Global- and Levin matting. I use both with iteration value 1. First Global is selected, coin is rounded, pressing enter, selecting the foreground with the mouse, again pressing enter. Here the problem is that under the coin where the green background’s colour was a little bit darker there are green dots. So after Global, I apply the Levin matting. With this the dots are deleted, good, but where it is not selected the coin, there the surface (mainly at the edge) is not the original, blurred or not as the original was. Here I can use the adding to background selection or adding to the background within extra zoom possibility to make sharper the edges. Finally after 10 minutes however it is the same result as in 2.8.16 was 30 seconds and automatically. So what did I wrong or how I should do to make this process easier and faster as it was in the earlier version? Thank You in advance for Your advice! Zoltan Zoltán Kluik ezt írta (időpont: 2021. márc. 23., K 14:10): Dear GIMP users, I would like to ask your help regarding removing background and change it to white. I'm dealing with coin pictures mainly medieval silver coins. I take the photo about coins with green / dark green background. In the past on Ubuntu I used the GIMP 2.8.16 version where I applied the foreground selection tool. Here I just simple rounded the coin, press enter and the program after some seconds selected my coin. I loved this method, because it takes only seconds to select the coin. Last year I have upgraded GIMP to version 2.10.22, but from this time I have a big problem with time consumption and also with the quality of the changing the background. Now in 2.10.22 I open a picture, using foreground selection tool, but in this version there is a motor feature where I can select Global- and Levin matting. I use both with iteration value 1. First Global is selected, coin is rounded, pressing enter, selecting the foreground with the mouse, again pressing enter. Here the problem is that under the coin where the green background’s colour was a little bit darker there are green dots. So after Global, I apply the Levin matting. With this the dots are deleted, good, but where it is not selected the coin, there the surface (mainly at the edge) is not the original, blurred or not as the original was. Here I can use the adding to background selection or adding to the background within extra zoom possibility to make sharper the edges. Finally after
Re: [Gimp-user] Resizing
In addition to ImageMagick which can do all sorts of great stuff, to do this kind of thing we had to resort to writing a Perl program. Our inputs are TIFFs and our outputs are JPEGs in four different pixel size-ranges. The output pixel size for some is fixed (i.e. for thumbnails) and for others is variable, but within a range, depending upon the input size. On one hand it is "simple" when you describe it in words, along with a little hand-waving. However, trying to do it programatically is a bit messy. Perl does have image handling modules that help a lot. (Disclaimer, I did not personally do any of the real work; I just did the talking and hand-waving.) We have a library of many tens of thousands of source images as TIFFs. We keep them as TIFFs for ultra-long-term purposes, also for print-on-paper use, and don't want any compression, etc., etc. New source images are dropped into the library at will. A command is run several times per week, or as needed, which compares all the sources to all the targets and makes/remakes any new targets where targets do not yet exist or any source's timestamp is newer than the target. It can be done. Jay On 02/03/2021 04:10 PM, Rick Strong wrote: You probably need a script that references each file in a folder and acts on them individually before closing it and moving on to the next file in the folder. I used to do that sort of scripting for Corel Draw and PageMaker but I'm not in that game any more. It should be straightforward for anyone who knows what they are doing. Rick S. -Original Message- From: Jo Kent via gimp-user-list Sent: Tuesday, January 26, 2021 6:18 AM To: gimp-user-list@gnome.org Subject: [Gimp-user] Resizing I have worked out how to batch resize which I’d great when all the images start of roughly the same size but I have a batch of images that vary from 300kb to 4500kb and I want them all to be approx 200kb is it possible to set a size rather than a percentage/pixel size that creates a variety of sizers, smaller but not what I require. To resize each image individually is very time consuming. Help! -- Jay Smith e-mail: j...@jaysmith.com mailto:j...@jaysmith.com website: http://www.JaySmith.com Jay Smith & Associates P.O. Box 650 Snow Camp, NC 27349 USA Phone: Int+US+336-376-9991 Toll-Free Phone in US & Canada: 1-800-447-8267 Fax: Int+US+336-376-6750 ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Ticket numbers
On 12/11/2019 11:57 AM, Epick wrote: Hello guys, I have made tickets for our party, but I'm having troubles with one thing. I need to print 360 of those tickets and each should have its number starting from 1 to 360. How can I efficiently number those tickets? > Epick Attachments: * https://www.gimpusers.com/system/attachments/1313/original/ticBlank.png This is not a task suitable for an image editing program. I would do it another way. Use a word processing program that has an auto-numbering function to develop the framework for the area of the ticket, with the number to appear (overlay) on the image you have made in an image editing program. The easiest way to accomplish that would be to print the tickets in one run through the printer and then print ON THEM them AGAIN from word processing program to add the number on top of the image. However, even this would be more work than simply hand-writing (oh no, not that) 360 numbers. You could write the numbers faster than it took you to even think about these emails. Jay Smith ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Printing
see. I just doubled one and it halved the resolution automatically. In any case, your goal is to get to the print size you want, with a resolution of approximately 300 dpi/ppi. Much more than 300 is completely wasted on most print devices that normal folks own. Also, though others may disagree with me, I strongly suggest that you work in a NON-LOSSY file format, such as .tif (TIFF). If you work in .jpg (JPEG), every time you save the image, data is LOST -- do it several times and you will end up with a fuzzy mess. I do everything in .tif (TIFF), including printing. Yes, TIFF files are huge. If the file size is causing you a problem, you can as a separate and last step, once your TIFF file is saved, do a SaveAs (to create a new copy/version) to .jpg (JPEG) file format. That is tremendously smaller file size and might print faster for you. We scan to TIFF, edit as TIFF, save as TIFF. We then use a different set of programs and scripts, some of which we developed, to automatically create a whole range of sizes of JPEG files for use on our website. We can always go back to the non-lossy TIFF version to change, fix, edit, etc. and then automagically re-create the JPEGs. We do this with tens of thousands of stamp images. What you want to do is a bit different, you said you want to PRINT, which involves different concepts and math than on-screen viewing use. Also, be aware that different publishing or word processing programs into which you might want to import images for printing (i.e. Word, PageMaker, FrameMaker, etc.), treat different image file formats differently. Some mess with them and re-interpret them and some don't, depending upon the program and the file format. That is a whole different subject. If you have GIMP related questions, please continue this discussion on the list/forum. If you need more stamp-related (i.e not necessarily Gimp), you are welcome to email me directly. Jay Smith ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] can't keep proportions
Mattia, You said: also, it's not clear to me why 400 x 200 and 420 x 220 is not keeping aspect ratio? the vertical increases exactly the same amount of the horizontal It sounds to me like the problem is that you are confusing "same amount" with "same proportion". They are _not_ the same thing. Increasing 200 to 220 is a proportional increase of 10%. If you increase 400 by 10%, that becomes 440, _not_ 420! Jay On 12/19/2016 03:18 PM, Mattia wrote: thank you for the help, much appreciated. this will cause the border to look uneven however, isn't there a work around to this? also, it's not clear to me why 400 x 200 and 420 x 220 is not keeping aspect ratio? the vertical increases exactly the same amount of the horizontal If you add the same number of pixels to both the width and the height the aspect ratio will change UNLESS the image is square (height = width) - this is a simple consequence of basic arithmetic. If you want the aspect ratio to be unaltered you will need to add more pixels on the shortest sides of the image than you do on the longest sides - how may more being determined by the aspect ratio of the original image. For example if the image was 400 x 200 pixels adding a 10 pixel border to all sides would give 420 x 220 - which alters the aspect ratio. Adding 10 pixels each side and 5 pixels top and bottom gives 420 x 210 which preserves the aspect ratio. -- Jay Smith e-mail: j...@jaysmith.com mailto:j...@jaysmith.com website: http://www.JaySmith.com Jay Smith & Associates P.O. Box 650 Snow Camp, NC 27349 USA Phone: Int+US+336-376-9991 Toll-Free Phone in US & Canada: 1-800-447-8267 Fax: Int+US+336-376-6750 ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Comments on GIMP
On 08/07/2015 05:28 PM, George Misdary wrote: I'm not certain if this is the right place for this, but here goes, A few weeks ago I was on a mission to find a simple, yet effective, image editing program for a project I'm working on.After several frustrating experiences with a bunch of 'complete duds' and 'nice trys', I finally came across the GIMP. Within a few minutes of using GIMP, my reaction was simply WOW! Over the few weeks since I've been using it, that reaction has only continued to flourish and expand.In every step, so far, I've found GIMP to be unbelievably intuitive, logical, stable, capable, powerful, and simply brilliant to use.It is far and away one of the best programs I've ever used, not only as a graphics program but period!For every function that I thought Hmm, it'd be nice if ..., within a few seconds/minutes of poking around on the hyper-intuitive interface; I've not only found exactly what I was looking for, but something-like a dozen other ways to expand upon what I was looking for. Rarely do I find this level of... maturity in a program and for a program that is released for free none-the-less, I'm simply blown away!!I'm not exaggerating when I say that on a practically daily basis, that I've used GIMP, I find myself saying I really love this program. I'm sure you hear things like this fairly regularly, but I still wanted to send this email to give a HUGE shout-out to the developers, contributors, and all involved with making this such a kick-a## product! Kudos and THANK YOU!!! Regards,GM George, If I did not know better, I would think you were a friend of one of the developers. :-) Seriously I do have a question: What other image editing program(s) do you have experience with? (Not just tried them, but actual significant use.) My reason for asking is that Gimp is sometimes more intuitive for people who don't have a lot of experience with another image program (because they are somewhat expecting things to be like that other program). You are a bit special -- in my experience, most people have a more difficult learning curve than you seem to have had. Jay ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
[Gimp-user] What causes random (in error) image color-inverting of TIFFs, over time? Is it correctable?
Greetings fellow Gimp Users, I make images using Gimp, but I assume that this question is not really Gimp specific. I have tens of thousands of images (postage stamps) on my site. Every now and then when I am looking at a page I discover that the image (a JPEG) has had is colors sort of inverted. The JPEGs were created in large batches by a script from UNcompressed TIFF images. When I go back and look at the the original TIFF, I discover that its colors are sort of inverted -- thus the JPEG is a correct rendition of the appearance of its TIFF source. Thus the problem is in the TIFF. But, the problem happens now and then, over the course of years. The TIFFs are _not_ being intentionally manipulated in that time. The images was originally okay, now its not. It seems to be completely random, just one image here and there. Somehow the TIFF is getting corrupted. I am assuming by a memory error or a disk/RAID controller error, or such. The images are still openable in Gimp. This is only happening to one out perhaps one out of five thousand images, every five years. (I am just *guessing* at the error rate because I only find out about them by randomly coming across them.) But, if I have 40,000 images, that is eight images destroyed every five years. (And often I am not able to replace the image because I no longer have the item.) This example image was originally created in 2006. I suspect (mostly guessing) that it was corrupted sometime since 2010. There is no reason that it would have been edited since that time and file modification information shows nothing since 2006. On Ubuntu Linux, using identify -verbose filename.tif I can read the header information. The only odd thing (to my eye) is that the create date is 2011 and the modification date is 2006: Properties: date:create: 2011-09-13T11:30:24-04:00 date:modify: 2006-12-21T00:53:03-05:00 I am guessing that means the corruption may have happened in 2011, even though the filesystems own file datestamp is 2006 and the lsattr command shows nothing unusual. Here is example of a) the resulting JPEG (just to illustrate the nature of the corruption); b) a similar JPEG to show generally what it is supposed to look like; c) the corrupted TIFF. Corrupted: http://jsa.viewimage.net/jsa/web/Lists/Denmark/AdPairs/Spec/re02-pair_used-vf-b_136468_r_l.jpg Correct image of a similar, but different item: http://jsa.viewimage.net/jsa/web/Lists/Denmark/AdPairs/Spec/re02-pair_used-vf-a_136467_r_l.jpg This is the TIFF file (corrupted, but viewable in Gimp; colors are sort-of-inverted) Size 496 KB: http://jsa.viewimage.net/temp/gimp/re02-pair_used-vf-b_136468.tif My primary question is whether there is a particular bit that is getting flipped that could be unflipped by some sort of non-visual editing of the source TIFF file? My secondary question is whether or not other people have seen this type of problem crop up in large image libraries and what the causes have been? Any thoughts appreciated. Jay ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] How to swap image colors
On 10/23/2014 01:51 PM, CoolB wrote: It depends on whether the words are dithered or not. If there are sharp edges and the image really only has two colors, try the following: Click on the eyedropper (or O (O not 0), then click on the words to make the color of the words the foreground color. Click on the color tool (or shiftO), then click on the words to select all of the color in the words. Don't use the magic wand, as it only selects colors which are contiguous. Invert the selection (Select/Invert or ctrlI). Click on the Bucket Fill tool (or shiftB). Look in the tool options to make sure the fill type is FG color fill. Click on the background area to turn it the color of the letters. The whole image should now be the same color. Invert the selection again. Click in the tool options to change the fill type to BG color fill. Click on the words to turn them the background color. If the words are dithered it's more difficult as you need to change all the in-between colors to an appropriate in-between color. If you need that let us know and we can go into more detail for that. Thanks for your reply. I'm not really sure how to tell whether the words are really dithered or not. There are no sharp edges around them or the logo though that I'm trying to swap the colors on. Attached is what I'm working on. Attachments: * http://www.gimpusers.com/system/attachments/161/original/Image.png Yes, the letters/logo are dithered. The edges are fuzzy. Since this is a very simple text-logo, if you know and can get access to the font used for the original, you could much more easily (and in higher quality and more quickly) recreate by using text in an image program of some sort -- actually probably better in a vector-based program (Inkscape, Illustrator, etc.) instead of a bit-map-based program (Gimp, Photoshop, etc.). Jay ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] logo
On 07/29/2014 12:23 PM, Jim Welch wrote: Have you ever seen a professional photographer take their logo and ghost it, then place it on one of their photos so no one will steal their photos off the net? I have a logo in various formats, including png, and want to place our logo on some of my pictures which are in a jpeg format.. I am not sure of the percentage, but I am guessing maybe 10% of the total. Is this possible with GIMP. Thanks, Jim Jim, This is quite easy to do in Gimp using manual methods, but if you have more than a few to do, then I use Imagemagick http://www.imagemagick.org/ and create a script that does this. Using the Imagemagick methods and other scripting techniques (perhaps Perl with the Imagemagick Perl module) one can, for example, vary the size of the watermark based on the size of the underlying image. I used to use these Imagemagick/scripting techniques to create JPEGs (in four different sizes of each, with the four resulting sizes constrained by the original size based on some very complex logic) and add watermark to _tens of thousands_ of original TIFF files (leaving the TIFF files unchanged, unwatermarked so that they are available to me for other uses). It is very powerful stuff, but it can take a bit of work to learn. Jay Smith ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Question about bump map location
On 09/02/2013 03:32 PM, Judy Wilson wrote: snipped My question: I would like to put a watermark of my logo on images, and I can do so with the Map, Bump Map Filter. However, the location of the bump map is a problem. At 0 on the X and Y Offset sliders, it goes into the upper left hand corner. OK. The problem is the sliders only move to -1000, and my images are often larger than that, and I want to put the bump map into the lower right hand corner, and the sliders will not allow that. Typing in the numbers doesn't work, and moving the bump map in the preview with the middle mouse button doesn't work. Of course if I make the images smaller I can get it into the right hand lower corner, but I want to use the larger image. Any solution for this, or do I have to just live with this ... defect(?) for now. Thank you! Judy Wilson Judy, Thanks for all your efforts to support The Movement. :-) I can't answer the question you are asking, however, I use a perl script that invokes ImageMagick to add watermarks to large quantities of images. http://www.imagemagick.org Since I do put my watermark in the upper left corner, I have not paid attention to whether ImageMagick can apply the watermark based on the position from the lower right corner, but I would guess that it can. And if the answer to that is no, there is another trick you could try, especially if you are using a script to batch process. First, make your watermark image upside down and backwards. Then rotate each image 180 degrees, apply the watermark, flatten the image, and rotate it back to upright. Last note: When I batch process to apply watermarks, I always only apply to _copies_ of the images as invariably I later need the original without watermark for some other use. (This also prevents destroying the original if your batch script does not do as expected.) Jay ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] suggestion for Gimp
On 08/08/2013 03:47 PM, maderios wrote: Hi This positive proposal could end the eternal discussion save vs. export, etc Developers could offer two versions of Gimp: - One version for amateurs with the gimp 2.8 behavior - One version for professionals with the gimp 2.6 behavior that allows to save files quickly and normally just like most free or commercial editors images. This would allow everyone to be satisfied Greetings I'm just a user, and do not speak for anybody other than myself, but... Your approach would mean maintaining *two* different programs which would continue to diverge over time. I very much doubt that the developers have the energy to do that -- sometimes it seems that they don't have enough energy to do all that they would like with just one version. It seems to me that the developer's point of view is that amateurs should use a simpler program and not use Gimp at all. This is open-source software. You are welcome to become a developer, fork the project, and do all this yourself or you can build a team to do it. Or you can hire people to do it for you. But asking the developers -- all volunteers -- to increase their workload (the divergence would keep widening over time) is not how things work in open-source software as I understand it. If my vote counted (which it does not because I am not in the target user group), I would vote against this export requirement also. However, I know better than to waste more energy on the subject. Jay ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] Is there a single bit that can accidentally flip an image to negative? (not Gimp specific)
On 07/28/2013 07:00 AM, Elle Stone wrote: I'm going to call the image that isn't inverted right.jpg and the image that is inverted (not really inverted, but certainly it's not right) wrong.jpg, to avoid typing really long file names. Right.jpg doesn't have an embedded ICC profile. Right.jpg was created using Gimp, according to the metadata. Upon selecting it to open it, Gimp displays a normal-looking thumbnail that resembles right.jpg. Upon opening it, Gimp automatically assigns the Gimp built-in sRGB profile and right.jpg looks like you'd expect. Wrong.jpg does have an embedded ICC profile with description sRGB IEC61966-2.1. From the embedded profile metadata it appears to be some version or another of the original sRGB profile created by Hewlett-Packard and Microsoft back in 1998. That profile or versions thereof has been used by almost all imaging software and operating systems, until V4 profiles started creeping in. Upon selecting wrong.jpg with Gimp to open it, the thumbnail looks more or less like the thumbnail for right.jpg, but not exactly (the colors are washed out, the blue looks purple, the green looks brown). But upon actually opening it, the colors go all wrong. However, assign the Gimp built-in sRGB profile in place of the embedded profile and wrong.jpg now looks very similar to the right.jpg, slightly washed out, purple instead of blue, brown instead of green, but not inverted. According to the metadata, wrong.jpg is a Photoshop thumbnail. Was the original image created by Photoshop? Was the thumbnail really created using Photoshop and extracted using some software? I've attached a spreadsheet with the embedded metadata for right.jpg, wrong,jpg, and the argyllcms version of the original MS/HP sRGB profile, lined up so the metadata fields match. There are very small differences in the metadata, not enough to explain why wrong.jpg looks wrong until the Gimp built-in sRGB profile is assigned.Attached is also a copy of wrong.jpg with the argyllcms version of sRGB embedded so you can see the color differences. I'm going to try to extract the embedded ICC profile in wrong.jpg to see what the tone curves look like. Ofnuts is right, the problem (or at least one problem) is the embedded profile. And the two images aren't the same to begin with. Elle Stone On 07/28/2013 07:21 AM, Elle Stone wrote: It turns out that the embedded profile in wrong.jpg does have an incorrect tone response curve. See the attached screenshot comparing the incorrect TRC to what it should look like. The embedded profile compresses the original sRGB 1024-point TRC range from 0 to 65535 down to about half the original range, then drops abrubtly to 0. Very odd. Never seen that before. So is there some software in your toolchain of softwares that handles your images, that is somehow embedding a corrupt version of the original sRGB ICC profile? Is there a timestamp that might let you know when the inverted images were last handled, which might let you know what software embedded the corrupt profile? Elle Stone Hi Elle Ofnuts, Thank you for your replies. However, I think I have wasted (at least some of) your time because my original information was incorrect. But, it has been a terrific learning process for me, so thank you! a) Yes, the two example images are different; they were not supposed to be the same. The correct/right one was just to generally show what the colors were generally supposed to look like. I should have posted copies of the exact same file (on my server vs on the hosting site), but it turns out that would not have helped (or actually would have shown up the real problem), because... b) I was INCORRECT (damn, my perfect record for the year has been ruined -- ha!) about the wrong/negative original TIFF being okay and the original (on my server) JPEG being okay. They are NOT okay. However, when I look at them using Linux file management and file viewer programs they look okay ... that must be because those programs are only looking at the preview and are not parsing the whole image file and/or looking at the color profile in the image file. The preview is okay, but the image (actually the color profile in the image file) is mucked up and looks wrong/negative. It did not occur to me that there there were _three_ components involved (preview component, profile component, and image itself). LESSON: Look at the precursor image files in Gimp, not in file managers or file viewers. c) Ofnuts: The wrong/negative image on the hosting provider is identical to the image on my server, when viewed by the exact same tools (and also filesize, etc.). I understand some image hosting sites mess with images. However, I am using a web hosting service that just gives me space and does not seem to mess with anything (thank goodness). Thanks for that idea, however. Okay... the rest of the story. The wrong/negative image dates from 2004 OR EARLIER. I think it really dates
[Gimp-user] Save vs export separate discussion forum needed
Though I don't like the new and improved methods, they are what they are and they are not going to be changed back to the old way. It is really tiring and frustrating to have to listen to all the same stuff over and over -- even though (and because) I agree with some of what is said and I prefer the old way myself. Maybe there could be a separate discussion forum just for that subject. I feel you pain about the new way, and the old way would work better for me. However, we need to move on. Jay ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] Post GIMP File Management, Organizing Viewing/Simpler Alternatives Options PLEASE READ HELP!!! How Make .JPG Files More Like Tiles or Icons. Once Moved They Stay Set
On 04/11/2013 03:27 AM, FriendlyBeginner wrote: Hello Everyone, Please Help Me! I am perplexed hungry for ideas. I have thousands of 3x5 inch index cards, all hand written cards. And I have learned how to use GIMP to scan 4 cards at a time, crop, guillotine the 4 cards to make 4 seperate .JPG files, and then import to my PC (XP). The cards will (I guess) be numbered like 001.jpg, 002.jpg like that. BUT this current batch of cards are basically just things to do index cards, so I will likely have 3 folders labeled by priority 1, 2, 3And inside these folders are all my .JPG files depending on the priority of each things to do card. And all these thousands of cards will be dragged and dropped or otherwise be constantly moved and/or deleted by me constantly from folder to folder, keep in mind each of these .JPG files is labeled/numbered. So when I move them from one folder to another, there is labeling/numbering conflicts, and the order and positioning will be lost. What I was hoping for was some sort of a program/file manager whereby I can treat the .JPG Files more like tiles or desktop icons, once moved they are just there and do not move unless I move them and they do not get automatically moved by my PC based on file name/number, yet still be able to move and/or delete them from folder to folder without conflict. I really need some thinking outside of the box options/ideas. Any alternative file folder experts out there? Any file management/organizing programs out there? Please Help! Thank You, FriendlyBeginner If I understand correctly -- that in the long run it is the information ON the cards that you want to preserve, not necessarily images of the cards themselves, then it seems to me that you should be using a database that can either _contain_ images or at least display images referenced by filenames in the database, as well as textual/data content. In such a database, every card would be referenced by some unique filename/number; it really does not matter much what that filename/number is. The card would be viewable either as an independent image by whatever methods, but more importantly, from withing the database's user interface. The data records in the database would be structured to _eventually_ replace the cards/images. Over time, you could type in the data from the cards (images) into the database (while being able to see both at the same time on screen). When the data is fully entered, then you can sort and organize it any thousand ways you want and you will always have immediate access to the image (if still needed). Jay ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] scanner works with linux
On Thu, Nov 29, 2012 at 7:15 AM, Gracia M. Littauer gra...@yadtel.net wrote: anyone recomend any newer good Epson scanner that work with linux? No, but I am using a couple Epson Perfection 4490 Photo, probably as old as what you have. They work great on Ubuntu Linux (with some tweaking of linux USB stuff due to the older Linux distribution we are still using). In any case, more importantly, we use the scanners through Hamrick's VueScan Professional scanning software and love it! http://www.hamrick.com/ I have had questions about our scanning workflow, color calibration questions, and selection of LARGE (11x17) format scanners. I have asked Ed Hamrick and he has always been quick to answer with very helpful information. For me, that alone is work the modest price of the program. [We ended up with a used/refurb Epson GT-1 large format scanner which is incredible (faster and better than the usual smaller scanners even though it is a lot older). Original price probably around $5000 back in the day, but I found a used one for $400 -- plus delivery by truck.] Very importantly, Hamrick has a huge supported scanners list http://www.hamrick.com/vuescan/vuescan.htm#supported that tells you (by specific scanner model if you want to check on one) if it is supposed to work on linux (generically, at least). I would not dream of doing the scanning work we do without VueScan. I also found it extremely useful for our particular scanning work to calibrate the scanners, using a 'target', which I obtained from a source in Germany. Targets can be very expensive, but this one was only about $30 as I recall -- the best and the best deal I was able to find. VueScan does support use of the generated calibration file that is created as result of calibration process. [Now I just need to get calibrating equipment for our monitors, but that is a lot more costly.] Jay ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] finding layers after file has been closed (.... so much for the new export/save methods)
On 11/18/2012 03:57 PM, jenn golden wrote: I totally understood what you both said - but I didn't know that I had to save it both ways - I only saved it, or exported it at a .jpg... Does that mean I can't recover the .xcf? On Sun, Nov 18, 2012 at 3:54 PM, Daniel Smith opened...@gmail.com mailto:opened...@gmail.com wrote: what he said. that's what i meant when i said before that you would still have the layers, that you had the .xcf file somewhere. :) dan I don't want to start anything, but this just points out what I said originally: It is not possible to always protect everybody from themselves. I am very sorry for Jenn's misfortune and I do not mean to be disrespectful. However, this is an excellent illustration that this controversial change in the save/export methods is not a perfect solution either. Jay ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] finding layers after file has been closed (.... so much for the new export/save methods)
On 11/18/2012 04:38 PM, Burnie West wrote: On 11/18/2012 01:13 PM, jenn golden wrote: However, this is an excellent illustration that this controversial change in the save/export methods is not a perfect solution either. On the good side, however, Jenn is happy to have learned the lesson -- and is fully up to speed with the difference between save and export. -- Burnie Yes, Jenn seems to be taking it well. Again, I am sorry that she had to go through that frustration. However, when I originally brought up my point that sometimes people (in general) have to learn a lesson the hard way in order to really learn, I was told, in various ways, with varying language, by several of the developer group, that I was a terrible excuse for a person -- if I was even a human being at all. Oh well. Fortunately, I found that reaction more amusing than anything else. The virulence of that reaction told more about them than anything else. I am just saddened that the most of the type of work my company does with Gimp is no longer (maybe it never was?) included in the target user/use definition. Because it does not make economic sense for a company to train and support users in two different graphics programs, there will eventually come a time (since I presume the goals of the program developers will continue to evolve away from our typical workflow), when we will have to switch to _one_ other program to do our graphics work. That's sad because Gimp has so much to offer. However, as the world changes, we all must move on. Complaining serves no purpose since the people who do the work, and thus own the program, are completely within their rights to do whatever they want. There is nothing wrong with that, however, the consequences are sometimes sad. Such is life. Jay ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] time saver?
On 11/15/2012 09:48 PM, rmooney wrote: I enjoy using GIMP, but I'm looking for some help to cut down on my time watermarking my photos. Currently I am opening a photo, adding text, rotating text, duplicating the text layer, then moving each layer to the top left and bottom right corners. Surely there must be a way to make this process quicker? Any help will be appreciated. A few years ago I was using Imagemagick for similar watermarking in an automated batch process. However, at that time there were some bugs (at least on our system) that prevented me from getting exactly what I wanted in terms of text appearance. However, it was _supposed_ to work and seemed to for other people. I suspect it does now (if not then also) and would work now on our more modern o/s. http://www.imagemagick.org/script/index.php When I was using it, it was part of a larger process I ran: making multiple scaled JPEGs from single TIFFs, and applying the watermark, all in the same process (without messing up the TIFFs). We still use Imagemagick for the sizing/scaling to process thousands of images. We use a Perl script wrapper to manage the process of running through hundreds of source directories/folders containing tens of thousands of images, processing only those that are newer in the source than the target, and pushing the results to a matching output directory/folder structure. (Thus any changed image will get reprocessed.) We use a complicated algorithm in the Perl script to decided the min / max size for each output, with max limitations on width and/or height (but maintaining original scale), based on the four target uses and on the physical size of the input object TIFFs (the TIFFs are all scanned at 100% of size (said from a printing perspective) at 300 dpi. The original source objects range from 1x1 inch to 20x20 inches (flatbed scans). The output sizes need to be sane to fit in a web page that is sane and yet takes advantage of whatever size is available without making the page too wide. The logic and math of this hurts my head; among other things, the differences input and output dpi really warps the math, while you are scaling differently depending upon various rules. Anyway, it works great and runs like cat with a bell tied to its tail. (I'm a cat person, but that would be fun.) The more RAM and the more processors the better and if you can control (increase) the number of simultaneous processes on your machine, you can make it scream. If we were to go back to watermarking, of course the watermark needs to be applied _after_ the sizing/scaling, but before saving the JPEG. You could also set up a watched folder type of system into which you could drop the source images and have a 'cron' job that checks and processes the folder however often you want. Jay ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] time saver?
On 11/15/2012 10:13 PM, Jay Smith wrote: On 11/15/2012 09:48 PM, rmooney wrote: I enjoy using GIMP, but I'm looking for some help to cut down on my time watermarking my photos. Currently I am opening a photo, adding text, rotating text, duplicating the text layer, then moving each layer to the top left and bottom right corners. Surely there must be a way to make this process quicker? Any help will be appreciated. A few years ago I was using Imagemagick for similar watermarking in an automated batch process. However, at that time there were some bugs (at least on our system) that prevented me from getting exactly what I wanted in terms of text appearance. However, it was _supposed_ to work and seemed to for other people. I suspect it does now (if not then also) and would work now on our more modern o/s. http://www.imagemagick.org/script/index.php When I was using it, it was part of a larger process I ran: making multiple scaled JPEGs from single TIFFs, and applying the watermark, all in the same process (without messing up the TIFFs). We still use Imagemagick for the sizing/scaling to process thousands of images. We use a Perl script wrapper to manage the process of running through hundreds of source directories/folders containing tens of thousands of images, processing only those that are newer in the source than the target, and pushing the results to a matching output directory/folder structure. (Thus any changed image will get reprocessed.) We use a complicated algorithm in the Perl script to decided the min / max size for each output, with max limitations on width and/or height (but maintaining original scale), based on the four target uses and on the physical size of the input object TIFFs (the TIFFs are all scanned at 100% of size (said from a printing perspective) at 300 dpi. The original source objects range from 1x1 inch to 20x20 inches (flatbed scans). The output sizes need to be sane to fit in a web page that is sane and yet takes advantage of whatever size is available without making the page too wide. The logic and math of this hurts my head; among other things, the differences input and output dpi really warps the math, while you are scaling differently depending upon various rules. Anyway, it works great and runs like cat with a bell tied to its tail. (I'm a cat person, but that would be fun.) The more RAM and the more processors the better and if you can control (increase) the number of simultaneous processes on your machine, you can make it scream. If we were to go back to watermarking, of course the watermark needs to be applied _after_ the sizing/scaling, but before saving the JPEG. You could also set up a watched folder type of system into which you could drop the source images and have a 'cron' job that checks and processes the folder however often you want. Jay One added note: By maintaining separate source (input) and target (output) directory structures you - Will never damage your source files. - If you want to change the watermark on the existing target files for any reason, you simply change the script doing the watermarking, use 'touch' (or similar) to change the dates of either the source or target files so that the process [a Perl wrapper script] will think the source files are newer, and run it again. All your target files will be recreated with the new improved watermark. Suggestion: Never delete your target files as a way to tell the process to recreate them. (Instead, move them aside.) I say this because every year I find one or two source files (out of tens of thousands) that have mysteriously been corrupted (though not accessed according to the file internals), the favorite corruption is that the image turns negative. Stray neutrinos?? Anyway, as long as you have your target files, you can at least have something usable even if your source has become bad. [And another good reason for progressive, non-destructive backups stored off premises.] Jay ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] HATE the new save vs. export behavior
On 08/07/2012 04:59 PM, Anoko wrote: On Tue, Aug 7, 2012 at 10:49 PM, Anoko wrote: The explanation page says In other words, GIMP used to assume that you don't mind accidental loss of unrecoverable project data and bothered you with confirmation dialogs. It was a convoluted logic, but people got used to it. I do not see why this is solved. Yes, you don't see it :) I understand that you are bored of the discussion, but by suggesting that it is my problem alone of seeing it wrong, I think that's a bit insulting and really unnecessary. I was at least trying to be constructive. I suspect though that you have misunderstood my use case. User: lets say he wants so save image with transparance as jpg, clicks save Gimp: you have to use export User: Export to jpg Gimp: ok! (no message that transparance got lost) User: click exit Gimp: Sure? not saved! User: uh, I just exported it, oh yeah right exporting is not saving. But it's exported, so my changes are safe. Agree! Transparancy lost. This is something I already encountered once, so it is a realistic use case (whether it is a probable is something else, but whether the previous problem was much larger is to be seen as well). Since in the old workflow, everyone who used to use save for exporting to png/jpg etc., will with some annoyance now use export, but no longer get flatten layers? messages, and he/she has to remember that indeed unsaved changes are unrelated to exporting. Since such people will always get a you have unsaved changes message when exitting the GIMP, this message becomes useless for this workflow. Thus, the only way to use GIMP without major annoyance, is to follow the forced xcf route. Hi Anoko, I am just another user like you. I also don't like the new save/export model. I wish that a mechanism could be found that solves these save/export issues for _both_ types of workflows. However, the answer to that from the developers seems to have been that it is too hard and causes too much potential confusion / logic branching in the code, thus making future coding more difficult. (So instead the users of one workflow type or the other have to do the work instead of the computer doing the work.) However, IMHO the developers have _not_ misunderstood your use case and are _not_ overlooking the use case you describe. Instead, IMHO they are not concerned about that use case. It is all very strange to me. On one hand, they developers were trying to avoid accidental loss of data by making the change that they made. However, the use case you describe (which I can see happening to many people) does not, IMHO, seem to concern the developers because they _may_ be thinking that only an amateur would make that mistake and thus that is not of concern for Gimp because Gimp is really not an appropriate tool for amateurs and amateurs are not in the target user group that the developers are making Gimp for. So, on one hand, the developers make a change to prevent users from losing data as a result of their own lack of knowledge or bad procedures. On the other hand, the developers seem to ignore a situation (that you have described) which has the same result. Either Gimp is for advanced users who won't have these problems (and don't need to be protected from themselves) or it is for a broader group of users that do need to have some protection from themselves. Pick one. IMHO, the loss of data situation that the developers were trying to prevent with this change was not serious problem for the Gimp target user group (advanced users). I doubt those advanced users were having a problem before this change. I suspect that the people who were having the problem is the very group that are still going to have a problem in the use case you described. When all the arguments about this got loud, I expressed my opinion that protecting users from their own ignorance and bad procedures just enabled users to be ignorant and use bad procedures. My opinion was/is that learning is (along with many other factors) a result of making errors, paying the price and thus learning. We evolve by learning. We learn as the result of experiences. Take away some of the bad experiences and you reduce the opportunities for learning. The developers jumped on me like I had five horns growing out of my head. I got emails that called me bad names and suggested that I was a terrible person because I would allow somebody to suffer just so that they would learn something. (In response, I say that a person will suffer a whole lifetime if they don't learn some hard lessons -- the faster they do that learning, the sooner their life will get easier.) In the end, however, I wish that a mechanism could be found that solves these save/export issues for _both_ types of workflows. 99% of my use is open TIFF, edit TIFF, save TIFF, close TIFF. 99% of the time, I have absolutely no need for retaining any data that
Re: [Gimp-user] HATE the new save vs. export behavior
On 08/07/2012 05:52 PM, Alexandre Prokoudine wrote: snip The usability team spent quite a while writing all the reasoning down at gui.gimp.org. I don't really understand why we need yet another long thread to go through all these things yet again. Alexandre Prokoudine Alexandre, IMHO the answers to your (probably rhetorical) statement (which I take as more of a question) are fairly obvious... Either the writing process was not complete and/or the needs and preferences of some users/workflows were either not considered, were considered and ignored as unimportant, or viewed as outside the target group of users. As many husbands have taken decades to learn (or else they are no longer married), sometimes writing all the reasoning down won't make the wife feel better. Right now, the developers are responding to an emotional situation by saying something like but we did what was logical, we even wrote it down first. In the recorded history of human relations, I doubt that response has worked on a regular, consistent basis. Users become very attached to the software they use. They start to think of it as theirs. They have made a very real investment in time, energy, learning, etc. to use the software. Users also develop a brand attachment that is deeper than most product makers comprehend (users of products will often stick by a product that even they themselves complain about as being inferior -- sort of a Stockholm Syndrome in a different kind of way). Software must evolve over time. If the users need the features in the new software versions, then the users must evolve with it. (Otherwise, the users have to set up Vmware and run old software on old operating systems -- I am still running one such program that I obtained in 1984 because I still have not been able to find anything better for the very specialized task I use it for.) When software evolves in a direction different from that user/workflow, the user experiences *very personal* feelings of *loss*. The strong feelings expressed in all these yet another long threads are users expressing their feelings of _loss_. And it is not just their _feelings_. Some of them will decide that they will have to migrate to other software which does include them it its target user group. That migration comes at a very real cost of time, effort, learning, and perhaps money. Every product, probably especially including software, must over time re-evaluate who its target user group is. In doing so, if changes are made, then some previous _loyal_ users will be excluded. Those users have done nothing wrong -- they just woke up one morning and found that they now live outside the walls of the city and there is nothing they can do about it. If the developers have made a mistake, it was possibly overlooking these feelings issues and not expecting such a strong reaction. That is not to say that the developers did not have to do what they did. However, they should not have been surprised by the reaction. *If* I recall correctly, for a short period of time before you (Alexandre) took on your current role of attempting to soften and humanize the communication, there was some rather harsh communication from the developer side that just poured salt in users' wounds. Your involvement has made things better, though it seems that you are (understandably) getting tired. shoutTHANK YOU FOR WHAT YOU HAVE BEEN DOING!/shout I just wish the developers would be open to conversation of how both types of workflows could be accommodated efficiently (both efficient for users and in the code). Closing off that possibility of conversation is perhaps what hurts most of all. I wish I had enough knowledge to contribute ideas of how to accomplish this while meeting the needs of all. Jay ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] Definition of project data .... vs image data vs workspace data
On 08/07/2012 05:32 PM, Alexandre Prokoudine wrote: On Wed, Aug 8, 2012 at 1:10 AM, Rob Antonishen wrote: And this is where your use case is wrong! The whole point of separating save and export is that ONLY save is safe. An export is NOT guaranteed to be either safe or lossless. It may be, depending on the source image. Your example exactly demonstrates the purpose of the new paradigm. The main problem I see with the suggested use case is here: Transparancy lost. This is something I already encountered once, so it is a realistic use case. Excuse me, Anoko, but there's no way I'm going to believe that a mistake that is only ever done once is going to completely ruin everything. Especially since GIMP asks to save project data. Alexandre Prokoudine Splitting off to a different thread. I have seen the term project data used in regard to XCF file format, as Alexandre has above. However, to me, the XCF does not _currently_ really save what I consider to be the _project_ data. Gimp does not save, to my knowledge (please excuse any errors), the following (and more, I am sure): - window positions or sizes - visible dialogs - viewing magnification magnification - active tool - most recently applied filter - most recently used settings in dialogs (such as Image Size settings such as inch vs mm etc.) etc., etc. Maybe these things are on the horizon, which would be great. Still, when I think of a project, I usually think of multiple images open at the same time, etc. I don't know that project is a good word in this situation. I would prefer workspace. But even if it is to be project it is more than just one image. What I hope to see in the years to come is: - Saving image includes saving the items listed above (and others) for a single image. - Saving workspace (or project) saves all image stuff mentioned above, for multiple images and whatever else is going on in Gimp at that moment. Opening workspace [name] would open multiple images and everything would look exactly like it did when the workspace was saved. (Or maybe project and workspace are completely different things??) Jay ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] HATE the new save vs. export behavior
On 08/07/2012 06:53 PM, Alexandre Prokoudine wrote: On Wed, Aug 8, 2012 at 2:28 AM, Jay Smith wrote: As many husbands have taken decades to learn (or else they are no longer married), sometimes writing all the reasoning down won't make the wife feel better. Right now, the developers are responding to an emotional situation by saying something like but we did what was logical, we even wrote it down first. In the recorded history of human relations, I doubt that response has worked on a regular, consistent basis. Jay, Let's not try fooling each other. The only thing the former community is really going to accept is Sorry, we screwed up, and you were right all the time. We are going to revert, sorry again. The former community will probably also accept OK, we are going to make this optional, except no two people so far agreed on how exactly this should be done, and noone so far seems to have understood how badly it would affect usability and code maintenance. People just want the old stuff back at any cost. Not gonna happen. Users become very attached to the software they use. You make it sound like there are generations of people who passed the habit of Ctrl+S for saving to PNG from father to son, whereas personal digital image editing is barely 30 years old :) When software evolves in a direction different from that user/workflow, the user experiences *very personal* feelings of *loss*. The strong feelings expressed in all these yet another long threads are users expressing their feelings of _loss_. And it is not just their _feelings_. Some of them will decide that they will have to migrate to other software which does include them it its target user group. That migration comes at a very real cost of time, effort, learning, and perhaps money. Excuse me, but what is wrong with that picture? Human civilization always needs time to adapt to new things. It was ever so. Would you tell Wright brothers that they shouldn't have had come up with their Flyer, because, ye gods, a hundred years later people still got to spend some time to learn how to get the bloody thing take off? :) If the developers have made a mistake, it was possibly overlooking these feelings issues and not expecting such a strong reaction. That is not to say that the developers did not have to do what they did. However, they should not have been surprised by the reaction. We knew it was going to be crying and moaning all over the place. We had early warnings of that, too. And actually we made few adjustments to the new model to clarify things, e.g. http://git.gnome.org/browse/gimp/commit/?h=gimp-2-8id=f4ce57aa9709e492666c16259e81625a3e4a7796 http://git.gnome.org/browse/gimp/commit/?h=gimp-2-8id=c3e904fab1b29224b7dd55bb5b4af49f34c3b335 Alexandre Prokoudine Alexandre, You made a very specific statement: I don't really understand why we need yet another long thread to go through all these things yet again. I attempted to explain my opinion of the situation, specifically in regard to what you claimed you did not understand. In return, I got back a dismissive reply that IMHO completely ignored the intent of what I was trying to say. Your response has seriously tested my respect for you -- I tried very hard to show my respect for you. I was not trying to say that users _should or should not_ do/think/feel this or that for whatever reason. I was giving my opinion of the dynamics behind **WHY** they DO think/feel this or that. Either you read my words too quickly without taking time to understand what I was getting at or you completely misunderstood what I was saying. Your response does not jive with the intent of what I was writing. In fact, you just got out a bigger hammer to try and pound the problem down. From this I am starting to get the idea that you don't actually _want_ to understand the problem; you just want the problem to go away. If that is the case, and as long as that is the case, the problem will not go away. The users are writing from their feelings. Until you respond to those feelings, you will get nowhere. In summary, IF nearly every one of the developers responses included some version of the following statement, nearly half of your long threads would vanish and life would be good: We understand _ presents a difficult situation for some users and we regret the impact that this has had on you. Unfortunately, we had to make difficult choices in the subject of ___ and the result is that the program will no longer fit the workflow of some users. We feel that the changes we have made will be to the benefit of the majority of the user community and we are dedicated to continuing the improvement of Gimp for the target user community. We appreciate your loyalty to Gimp and hope that you will find a way to adjust your workflows so that Gimp's new behavior will work well for you. Thank you for expressing your concern. Please know
Re: [Gimp-user] Reply via List Headers [was: Re: Calm and rational Save/Export workflow report ; )]
On 05/11/2012 09:39 AM, Michael Schumacher wrote: Von: Richard Gitschlagstrata_ran...@hotmail.com Then the real question is why every time I hit Reply, Hotmail prefills my form with the individual user's email instead of the mailing list's, and I have to change it every time before hitting Send. GIMP or otherwise, minor impediments like these are quite annoying. That probably happens because Hotmail doesn't handle the List headers that are part of each message, e.g.: List-Id: GIMP Developer Listgimp-developer-list.gnome.org List-Unsubscribe:http://mail.gnome.org/mailman/options/gimp-developer-list,mailto:gimp-developer-list-requ...@gnome.org?subject=unsubscribe List-Archive:http://mail.gnome.org/archives/gimp-developer-list/ List-Post:mailto:gimp-developer-l...@gnome.org List-Help:mailto:gimp-developer-list-requ...@gnome.org?subject=help List-Subscribe:http://mail.gnome.org/mailman/listinfo/gimp-developer-list,mailto:gimp-developer-list-requ...@gnome.org?subject=subscribe It should be rather easy for Hotmail's developers with their near limitless resources to implement a List Reply feature (or make Reply behave differently for list mails, although this may break other users' expectations). Additional features like links to the archive, unsubscribe or subscribe would be possible as well. HTH, Michael Michael, I use Thunderbird 3.1.10 -- not the latest version, but quite happy with it. This version of Thunderbird does the same thing (replies to the individual poster, instead of the list). In the last few years, the Gimp lists are the _only_ lists I receive that result in this behavior. Jay ___ gimp-user-list mailing list gimp-user-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] HATE the new save vs. export behavior
On 05/05/2012 10:30 AM, Alexandre Prokoudine wrote: On Sat, May 5, 2012 at 12:21 PM, Ken Warner wrote: but many posts calling for civility have come from people who want to divide the user base into two groups where one group is somehow more entitled to use GIMP than the other because of the things they do with GIMP. You know, it's quite frustrating that after all the explanations people still seem to get this wrong. So let's try again. We are not separating people into better of worse users, or the deserving and non-deserving, or entitled and not entitled. This would not be a constructive approach. What we _are_ doing is _focusing_ on a group of users who are underloved by free software. We are building workflows around their needs. We are _targeting_ those users. Maybe not everyone can see the difference, but it's right there. Hence attributing any kind of discrimination to us would be utterly wrong. I wish people really stopped doing that. Alexandre Prokoudine http://libregraphicsworld.org Alexandre, Please allow me a few words... a) The users whose workflow has been made more difficult are _understandably_ upset. They were using a program in a certain way that worked well for them. However, either unknown to them (maybe they should have been paying more attention?) the focus of the developers changed/evolved over time in a way that is not helpful to those users AND/OR those users simply did not realize (months and years ago) that they were using a program that was going to move away from the way in which they were using it. Part of what seems to be missing here is humility and respect on the part of the developers ... would it be too hard to simply say We are sorry ... even though we are the ones doing the work and we have chosen to go in a particular direction, WE ARE SORRY! Sometimes those simple words can go a very long way. It is like saying I am sorry for your loss... there is not a darn thing that I can do about the fact that Uncle Harold has died, but I _am_ sorry that it has happened and that your life will change as a result. On the other side, however, the upset users have not, IMHO, shown adequate understanding or appreciation for what the developers have GIVEN to them over the years. Maybe it is a case of a good thing that must come to an end for certain users. b) The users could have paid more attention to the conversations the developers were having ... I am an ordinary user and *I* knew this was coming because I monitor the developer list. c) The developers UTTERLY FAILED to manage public relations on this. It was completely obvious to me (from monitoring the discussions on the developer list) that this subject was going to touch of an enormous storm of anger among some users. If the developers don't like the angry reaction they have received, perhaps the developers should examine how they could have done a better job of communication ON THE USER LISTS to warn people of what was coming. I am not saying ask, I am saying warn. In what I have observed over the years as rather typical attitude by open-source developers, the developers did not seem to think about (and certainly did not execute) good ADVANCE public relations on this subject. The attitude of we did it, like it or leave it is just not well received in this day and age. At the same time, users must understand that the developers are (despite what the developers might think), only human. They are fallible. They screw up. They make bad decisions. However, the developers are the ones doing the work Anybody that does not like the direction that an open-source program is going can branch off and do their own work. I know that 99.99% of users, like me, do not have the skills to do that, but that is the price we users pay for using free software. Users of open-software have an extremely high loyalty and commitment to the particular software they use. They feel that it is theirs. That they own it. That is all well and good until the software goes in a direction that is different from where the user wants it to go -- when that happens, there is great anger because there is great emotional loss. Developers have a responsibility to at least understand this concept and to attempt to mitigate users' feelings of loss and to prepare them in advance for inevitable changes. If developers don't feel that they have such a responsibility -- which would be a reasonable opinion on a developer's part -- the developer must accept the anger that will come. It is inevitable; thinking otherwise is unsound. d) As I said, I monitored, and participated a bit, in the developer discussion about save/export when implementation was being discussed. I described my workflow and how the proposed change would negatively affect me and users like me. At that time export may have been part of the goals for the program, but it seemed that
Re: [Gimp-user] Problem with the Newsprint filter?
On 01/09/2012 10:00 AM, Zweibaby wrote: So, yesterday I was trying to halftone an image. Everything was working fine, but I couldn't figure out how to use it the way I wanted to. So I found a tutorial. I read it, figured out what I was doing wrong, went on my way. Everything seemed fine. Then I went to use my newfound knowledge, and lo and behold, the Newsprint filter stopped working. No matter what I tried, the preview image looked just like the original. And when I tried applying the filter anyway, figuring maybe something was just up with the preview panel, nothing happened. The filter pauses to load when I change something, acting like it's working, but nothing happens. The closest thing I've been able to get was the image completely disappearing when I change a certain setting (switch to intensity, in case you were wondering). I tried googling my problem, but all that gets me is tutorials and the how-to-use guide. I was hoping someone here would know what's wrong and how to fix it. Thanks in advance! Well, I got it to sort-of work now. It's not exactly how I want it, and I still haven't figured out how it suddenly switched the way it wanted to work, but I pieced something together. I'd still like to know why it did what it did, though. Is it possible that your image has multiple layers and that (unknowingly) you were trying to use the filter on a layer for which the filter would have no effect? Jay ___ gimp-user-list mailing list gimp-user-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] Fix Orientation ?
On 01/09/2012 04:10 PM, Ronald F. Guilmette wrote: What is the proper way, using gimp, to correct the orientation of an image? For example, I just took a shot with one of my cameras where I was holding the camera in a vertical (portrait) orientation. But when I transfer the .JPG to my PeeCee and view it with gimp (or ImageMagick) it is laying over on its sid, in landscape orientation. To fix this, should I be using Tools-Transform Tools-Rotate or is there a better way? (Actually, I did try doing it that way using gimp, and the results were distinctly unacceptable... some parts of the image got cropped out, and some new transparent parts were added. Bummer. This is not at all what I had in mind.) Regards, rfg P.S. Before asking here, I did try googling around for gimp and orientation and/or gimp and rotate but didn't find anything enlightening. I also checked the Gimp FAQ and again came up empty. Ron, When I started using Gimp, rotation (arbitrary) was a big problem for me. If you wanting to rotate in 90 degree increments, then use (as others have already posted) Image, Transform, [and select the operation you want] That will take care of the problem you are having. On the other hand if you want to do arbitrary or automatically calculated degrees of rotation, the method you used is correct, HOWEVER, you first must expand the canvas: a) In some cases you may wish to set the background color. That is in the Toolbox (Windows, Toolbox) ... you can set foreground/background colors and/or reverse them, etc. When you expand the canvas, it will automatically fill with the background color you have specified, thus the potential importance of this step. b) To expand canvas: Image, Canvas Size FIRST AT THE BOTTOM IN Layers: Resize Layers CHANGE TO ALL LAYERS (That is a major Gimp Annoyance.) Then enter your desired new canvas size and then move out of that field for it to take affect. NOTE that once you have entered the new canvas size but are still in that dialog, you can drag the preview image around in the canvas to put it roughly where you want it. c) Then do your Tools-Transform Tools-Rotate. Learning to use the Arbitrary or Automatically Calculated Rotation tool takes some experimentation (at the bottom your Toolbox there should be a variety of options for its behavior). Once you figure it out, it is extremely powerful. Jay ___ gimp-user-list mailing list gimp-user-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-user-list
