Re: [Gimp-user] Windows XP - Service Pack?
On 01/30/2011 02:11 PM, Chris Mohler wrote: On Sun, Jan 30, 2011 at 12:54 PM, jack whitejbw9...@hotmail.com wrote: Thank you, but that's not installing it with no SP's installed though (as the question was). I'm not sure why you would want to skip the service packs - I use an XP VM for legacy apps and testing, but the first thing I did when setting it up was to install SP3. Why not install SP2 (or SP3)? Just curious. Anyway - maybe the portable version would work? Just a guess - I have no way of testing it: http://portableapps.com/apps/graphics_pictures/gimp_portable Chris I am new to this thread... There is a lot of stuff that must have SP2 to run and I have not heard of any significant problems with SP2. However, SP2 is the last version before M$ added phone home. A lot of people don't trust M$. It is not an issue of whether the copy of Windoze is legal or not (which, of course it always should be), but it is an issue that it's none of M$ business what you use the Windoze for. Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Windows XP - Service Pack?
On 01/30/2011 05:17 PM, jc wrote: On Sun, 30 Jan 2011 14:57:14 -0500, Jay Smithj...@jaysmith.com wrote: I'm not sure why you would want to skip the service packs - I use an XP VM for legacy apps and testing, but the first thing I did when setting it up was to install SP3. Why not install SP2 (or SP3)? Just curious. However, SP2 is the last version before M$ added phone home. A lot of people don't trust M$. It is not an issue of whether the copy of Windoze is legal or not (which, of course it always should be), but it is an issue that it's none of M$ business what you use the Windoze for. I don't disagree with you about Microsoft's high-handed tactics, but being unpatched puts your system at risk, as well as others when your system is compromised or botted. There are better alternatives (Linux, Mac) to what you're doing. I agree completely with JC. Though giving M$ access is the definition of compromised as far as I am concerned. We run Linux for 98% of our work. We only run one XP SP2 for specific applications that are not available in any more satisfactory form. It is behind three levels of firewalls with communication both in and out clamped down to the point that it can be hard to use. It is NEVER, EVER used for browsing or email or anything like that and it is only running when one of the needed applications is being used. Still, it is worrisome. Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] LZW Compression - Image rendition advice
On 01/22/2011 01:04 PM, Chris Mohler wrote: On Sat, Jan 22, 2011 at 11:15 AM, Ralph Zerbonia ra...@universecentral.com wrote: My question is whether or not anyone knows of any image disadvantages, is there anything about LZW that would allow a loss of any visual fidelity? LZW is indeed lossless. I just did a quick test[0] to be sure that GIMP's implementation is lossless and it turned out OK[1]. PNG is a lossless format as well, and may give a slightly smaller file size than TIFF. Chris [0] I did the following in GIMP 2.6.10: - Open an uncompressed TIFF file - Save a copy with LZW - Close all files - Open original - Open As Layers LZW copy - Change LZW layer mode to Difference - Move the cursor about in the image while looking in the 'Pointer' dialog - All RGB values are 0% (black) throughout the image (could also flatten the image at this point and use levels or curves to verify that there are no anomalies) [1] In an older version of Photoshop (5? 6?) I did the above and came out with a very slight shift or loss. It could have been a mistake on my part, but at the time we figured it was a bug in Adobe's LZW handling. I can't reproduce this any more in Photoshop - so whether or not it was pilot error or a bug, it's no longer relevant - except it's the reason I remember the above procedure ;) I have always wondered about this. Thanks, Chris for the information. However, a couple related questions about LZW-compressed TIFF files a) For images under (for example) 50 MB in size, and on systems that are modern, fast, and with lots of memory, is there an approximate rule of thumb regarding how much longer opening and saving operations will take? b) (Though not a Gimp issue) Are there any implications using LZW-compressed TIFF images in other applications? Specifically, I use Perl scripts and ImageMagick to create four different sizes of JPEGs from each TIFF file. Do such operations care whether or not a TIFF file has been LZW compressed? c) Other than saving disk space and/or reducing file transmission time in the case of uploading/downloading, are there any particular reasons to use (or not to use) LZW compression? Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] OT - Having Problems Displaying Image Thumbnails
On 10/23/2010 02:27 PM, Frank Gore wrote: On Sat, Oct 23, 2010 at 2:11 PM, Mark Phillips m...@phillipsmarketing.biz wrote: My apologies for this OT post, but I need some help from an image expert, and I thought the Gimp list might have one or two. When I upload images from a friend's digital camera, a Java web app is not able to create thumbnails (they appear black with the title of the image in the image area). However, clicking on the missing thumbnail renders the full image. When I upload images from a different camera, the same app generates the thumbnail and also renders the full image. Is there a special setting that camera's have to have set to allow thumbnails to be created? Both file types are jpeg. I am not seeing any error messages from the app. Yep, definitely off-topic :p Those applications you mentioned probably aren't generating thumbnails. They're just using the existing thumbnail that's embedded in the file. Most cameras embed a thumbnail in the JPG file, some do not. Your friend's camera probably just doesn't have those thumbnails embedded. To keep this on-topic: Gimp and most other image editors have an option to include a thumbnail when saving a JPG file. I typically disable this option for web graphics to make the file size smaller. -- Frank Gore One caution that should be mentioned if the OP decides to use the Gimp option Frank mentioned to generate thumbnails when saving JPG files. If the JPG is opened in gimp and then saved (even though no changes are made), the JPG will suffer some amount of quality loss even if the highest quality level is selected when saving. I run into a _lot_ of people who are simply not aware that _every_ time a JPG is saved, the quality is reduced. BTW, to accomplish the addition of the preview in Gimp in this circumstance you need to use Save As (probably on top of the same name) and tick the checkbox about preview images. Make sure the quality slider is all the way to maximum. Test this all first by copying one or more images to a different directory/folder and working on the copy. Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Printing Problem
On 10/15/2010 09:30 AM, John Culleton wrote: On Thursday 14 October 2010 18:09:18 ChadBJX wrote: Chad, Can you print _anything_ from Gimp? If you can print a very tiny image, maybe it is a printer memory problem. Sorry, I can't help further. I don't have Vista and I am sitting here happily emailing from Ubuntu. ;-) I will have to get Vista soon (for certain software we will be required to use), but I will run that under Vmware on the Ubuntu (as I do with XP, W2K, Win95, and RedHat Linux, and Unixware!). Jay Hi Jay, Thanks for the idea. I was trying to print a fairly large graphic file size. Will try a small simple graphic and will also try saving as a .jpg instead of Gimp's default format and see if that works for me. I'll let you know but it may be a few days until I can get back to the forum to let you know. Thanks again. I love forums -- You usually get the best answers there. :) Chad John Culleton wrote: I don't try to use the print capabilities of Gimp, of Inkscape, of Krita, of Scribus or whatever. It is easier to save a file (PDF anyone?) and print that file out using e.g., Acrobat Reader. And now a question. Why are you upgrading to the effectively abandoned product Vista? Would not Windows 7 make more sense? CHAD: .jpg is a _lossy_ image file format (even at the highest quality setting). It is probably not an issue if you are printing to a low-quality printer, but be aware that _every_ time you save a .jpg, the image quality is lessened. If for some reason you must save/export to .jpg keep the original image and always do all editing in the original image. I don't have any problems printing from Gimp, even to a cheap, low-memory ink-jet, but then I am on Ubuntu Linux. JOHN: IMHO, the idea of having go through yet another file format (PDF) and program (Acrobat) just to print is not an acceptable long-term solution. I have had images that I needed to print to a cheap ink-jet printer (because that was the only printer available at the time due to service problems) and simply had to have a print right now. Due to the printer's lack of calibration, I had to tweak a _copy_ of the image to get colors to come out as needed -- I had to print about 12 times to dial it in. If I had to make a PDF each time, it would have taken much, much longer. Regarding Vista vs Windows 7, etc., I did not write clearly. I will have to install whatever version of Windoze the required software demands. But it will be installed under Vmware Workstation and run under Vmware Player, allowing that single Windoze instance to be run from any physical workstation on the network. Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] fuzzy around text
On 09/28/2010 05:11 PM, John Mills wrote: Finally - one I may be able to answer .. Try scaling the image close to the size and resolution you expect to print _before_ you add the text. I believe the text is essentially bitmapped onto your image when you add it. If your printing implies a substantial enlargement you may be looking at the edges of the text as it was rendered. Just a guess, but I had a similar problem when I started out and that was the reason for ragged edges and fuzzy characters on my text. You may even want to create your image at higher resolution than you will print it -- at least once or twice as experiments. HTH. - Mills On Tue, 28 Sep 2010, for...@gimpusers.com wrote: I'm new to Gimp and graphic design. I was able to create a logo with a transparent background. However, when I convert to jpg gif or png and then upload to my server (or insert into Word or PDF) it's fuzzy around the letters. Any idea what to do to keep it looking sharp and get rid of the fuzziness? Thanks, dev19 (via gimpusers.com) I agree completely with Mills and a previous poster. I find that 99% of the time logos have been created at too low a resolution. Because the target size of a logo can vary tremendously (from business cards to the side of a 40-foot-long truck) it is extremely important to do the creation (and to maintain the original file) at very high resolution. You might think it absurd to create logo artwork at 2000 dpi, until next year when you need to put it on a 8-foot-wide banner or the side of a building. Save the original at that high resolution -- and be sure to save multiple copies in multiple physical locations; that logo might be in use for 20 years or more (mine is almost at 30 years) and they have a way of getting misplaced. Then when you need to make a new target, COPY the original file to target-specific name. Then, after copying, size it down and *simultaneously* reduce the resolution to the appropriate resolution for the output device (i.e. laser printer probably 300 or 600 dpi). Also, depending upon the type of artwork, consider using a vector-based image program instead of a bitmap-based program such as Gimp. A vector-based image is supposed (?) to scale up and down without any of these issues, but it is not appropriate for all types of images. Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] batch script help
On 09/13/2010 11:47 AM, jeremy jozwik wrote: hello list, just added my self so i hope this is an active list. im am attempting to batch compress OSM tile images. they are of png format, otherwise i would have used cjpeg. anyhow the script need only open the images in a folder and save them out with a different compression level [9] snip Jeremy, It seems to me that using Gimp for this task is perhaps not the best use of Gimp or of your time. I do not know the specific answer to your question about the problem you are encountering, but perhaps a program such as ImageMagick http://www.imagemagick.org/script/index.php would be more suitable. ImageMagick is specifically designed to do the kind of batch tasks that I believe I understand you wish to accomplish. We use it to process tens of thousands of images (making multiple sizes of JPEGs from TIFFs), but I don't have any specific experience with the task you are attempting. Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Rear page of scanned image visible when printing
On 09/12/2010 05:41 AM, Andreas Moroder wrote: Hello, I have scanned page from a book. On the screen all looks ok. Near the images I wanted to scan I see only light shades on the white background, but when I print the page this shades becomes much darker and visible and show the back side of the page. Can anyone please tell me a way to get rid of this shades without impact on the rest of the image. I uploaded one page here: http://rapidshare.com/files/418578196/seite1.tif Thanks Andreas Andreas, I am not going to wait that long for rapid share. It has been a minute and counting, still no image. However, the answer to your problem may be scanning with a BLACK background behind that page. This negates the black/white differences. Because 99% of our scanning involves this problem, we have taped black paper over the lid of the scanner (which is typically white) and the problem is solved. Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
[Gimp-user] Create From Clipboard -- Pasted Layer -- Problems Printing
Hi, Gimp 2.6.6 on Ubuntu 8.04 Linux. Minimum 2GB of memory. Used to editing (but not printing) images to 200 MB. I am running into some strangeness that I don't know is a an error in my actions, a general workflow problem, or a bug (or feature) in Gimp. Starting with a (color) JPEG image from a digital camera. Looks fine on screen, but when I try to print it, the printer chokes (which is extremely unusual for this printer, but does happen now and then; it is a big Kyocera b/w laser with maximum memory and maximum hard drive) -- after several minutes of processing still nothing coming out. OKAY that is NOT the problem -- I can understand that the image may be too large and/or the color to b/w conversion on the printer is not efficient on that printer. So, I created a new image by doing the following. Select All in original image. Copy File, Create, From Clipboard Creates a new image that looks like the previous. I change the size (scale) to something more suitable for printing. AT THIS POINT I HAVE **NOT** SAVED THIS NEWLY CREATED IMAGE. THAT IS IMPORTANT. When I HOVER OVER AND look in the bottom status bar of the window containing the newly created image, it says Pasted Layer and gives a size in MB, about 20 MB. I say to myself Self, that does not look right. I do Flatten Image, I do Merge Layers, etc. The Pasted Layer text remains, but the size keeps increasing in roughly 20 MB jumps. When I look in the layer dialog, it only shows one layer. However, when I click the eyeball the picture disappears and I get a gray checkerboard, so there is something more present than just that one layer. (I _have_ double-clicked both on and off the image (I had to make the window larger first to click off the image) to try to anchor the layer or finalize the pasting or whatever you want to call it. However, if that did anything, it increased the above stated MB size.) When I try to print this (still NOT saved) image, I can't get it to print. I even have trouble getting the print dialog to appear sometimes. Something is strange. So, to get a SaveAs dialog, I start to Close the image (I know, that is a strange way to do it) and select Save, getting the SaveAs dialog. I save it to .jpg and accept the current defaults. Thus it is now closed and has an actual image name. I reopen the image. Now when I HOVER OVER AND look in the bottom status bar of the window containing the image, it now says Background and has a 3.9 MB size (completely reasonable). Everything is normal. It prints perfectly fine and quickly. So, why do I have to save the image to a file... - before I can print it? - before the Pasted Layer text goes away (and becomes Background)? - before the size is stated more reasonably Is this a problem with my (fairly elderly) printer vs Gimp's native while-in-editing file format? Am I doing something wrong? It is no big deal to save and close the image to a file and then re-open it in order to print. It is not going to ruin my day. But, it seems very strange to have to do that (and has not been necessary in some other image editing programs I have used), thus my query. Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] logo manipulation
Hi Leon, A few thoughts / questions for you to consider and experiment with. a) When you take about placing it in Indesign, can I assume that this is for PRINT use? If that is the case, then 1) It should be CREATED in Gimp with a resolution of AT LEAST 300 dpi (that is enough, but less than that is too little for PRINT use). b) The file format should NOT be JPEG (.jpg) or GIF (.gif). Too many people try and use those types of WEB formats for PRINT work. I either use TIFF (.tif) or EPS (.eps). You will have to experiment with what your program likes. c) NEVER resize a graphic in some other application such as Indesign or whatever. Always CREATE your graphic in a graphic program such as Gimp. Test printing it from the graphic program. Then place it, without any size or scaling change in the other program. If you look on my website, I have a Viking logo. I have created at least 10 different ORIGINAL sizes and formats (.tif vs .jpg, etc.) for all the different uses of it in print, on the web, etc., etc. This is a critical point which most people overlook. There are lots of other things that can go wrong, but these are starting points. If you are still having the problem, then we need to exact details of your process of creation, import into other program, use, etc., etc., including links to examples of the actual image files, etc. On 08/29/2010 12:55 PM, Leon wrote: Hello All, I am a complete beginner and I have to be honestI'm struggling. I created a logo for my new business, but when I try to place the logo in a box on indesign or such like, the logo comes out looking blurry or smudged. I think it's to do with it being resized. Can anyone please advise me (in very simple terms)how to manipulate the image without it ending up looking so poor? Many thanks Leon -- 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 mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Standard text in picture.
On 07/28/2010 10:27 AM, Jimmi L. Hansen wrote: Is it possible to make a standard text in every picture feks. ©Jimmi L. Hansen? So i dont have to make it manual every time. Sincerely jimmi Jimmi, In the past I have used ImageMagick for this, processing thousands of image files at a time (the largest run was on about 30,000 images). http://www.imagemagick.org/script/index.php 3-4 years ago, this ImageMagick method had some bugs with size and position of the overprint/watermark, but I think that has all been fixed now. More to the story... Normally you would not want to apply this overprint/watermark to original/source images. And, if you apply it to already existing distribution images (such as JPEGs) you degrade the quality of the existing JPEG. So what we were doing in ImageMagick was: For each source/TIFF image open TIFF image apply watermark/overprint SaveAs image in a different directory AS JPEG (with desired quality level) close TIFF image without saving Thus the original/source is not contaminated. Frankly, even this approach is not completely safe in my opinion because the manipulation of the open TIFF image creates a risk in case your hardware develops memory problems, etc. [We had physical memory go bad in the middle of processing and destroyed several thousand images -- fortunately we had backups.] Thus, if I were designing the workflow, I would rsync/copy the source images to a temporary directory, create the JPEGs and then discard the copies. Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] obscure portions of images automatically?
On 05/16/2010 05:52 AM, Dave wrote: Hi, I take a lot of photos at car shows and the like, but it's a pain going through them manually afterwards and pixellating the number plates. Is there a way I can define a mask or something that I can then apply to a folder of images, which will pixellate/blank out the registration plates of the cars? Thanks in advance for any hints/tips! I have no idea how they do it, but Google does it on a huge scale. If you look a Google Maps, Street View, in a residential neighborhood, you will see that virtually all the license plates have been blurred-out. And they are doing it to something a lot more complicated than individual stand-alone still images. Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] A sequence of actions
On 03/30/2010 01:22 PM, Michael J. Hammel wrote: On Tue, 2010-03-30 at 22:31 +0530, Tarun Samvedi wrote: Is there any way of defining a sequence of actions that could be used later? for instance, if I apply auto-color, auto-contrast and cartoon filter to a lot of images, is there a way of defining this sequence so it can be done in a single step? Current version does not support recording actions directly. Instead you need to write a plugin using one of the supported languages: Python, Script-Fu or C. For something simple like this python is probably the easiest to learn. For more complex plugins I write C plugins, but then I'm more comfortable with C than Python. I am glad that Tarun brought this up. Question: Has somebody written a generic large script or set of scripts or library of script components that would allow an ordinary user with only the most basic programming skills to grab the bits they need for their particular sequence of actions? Something that a basic user could edit down to what they need or cut/paste out the bits they need? I know one could study existing scripts and try to learn from them, but that is different than a script that is fully commented and designed for the purpose of taking the modular bits you need to build your own modular script. IMHO, the lack of a recording actions function, is the weakest aspect of Gimp. Photoshop 5 had this (though it was somewhat limited) along with batch-running operations and that was released in May 1998, 12 years ago. I appreciate that such a recording actions feature will become available when somebody steps up to create it. (And no, I do not have the skills to do so.) I am sure that Sven will rip me a new one for saying so though I have the utmost respect for the folks that have the skills and time to do such programing, but I want to use Gimp, not learn a program language. Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Open a file r/o
On 03/25/2010 04:33 PM, Programmer In Training wrote: snip P.S. More importantly, please let's be sure that all the file create PERMISSIONS are being created correctly. I already posted a bug on this, but I sure am getting tired of files being created with rw- r-- r-- even though the umask, directory perms, etc., and everything else Um, that is. You'll find every file you save will by default rw-r--r-- From my own $HOME directory: -rw-r--r-- 1 user1 user1 2492 Feb 2 09:32 .vimrc Or even better, a file that's recently been created: -rw-r--r-- 1 user1 user1 8336 Mar 25 11:28 .xscreensaver Those perms give user1 (user, group) read and write permissions and everyone else read permissions (which is how it should be by default). The only time you need execute (x) permissions are on executables and if you want someone else to be able to read them without copying the file to them, just add them to your group. snip [I may not have this 101% exactly worded properly, but I am 99.99% sure I have the concept correct.] The examples you just gave are appropriate for what they are specifically because they are in your own $HOME. Notice that in your example, both user and group are user1. That is appropriate for $HOME, but it is *NOT* appropriate for a wider-access data area in which all images are often edited by multiple staff members. More appropriate to this discussion would be /somedir/images directories, containing myimage.tif drwsrws--- 1 user1 mygroup 4096 Mar 25 11:28 somedir containing drwsrws--- 1 user1 mygroup 4096 Mar 25 11:28 images containing -rw-rw 1 user1 mygroup 35123 Mar 25 11:28 myimage.tif On *nix Create-file perms should be set by the creating program based on umask / directory perms. If the perms of the directory /somedir/images look like drwsrws--- user me group mygroup then if files are created BY A MEMBER of the group mygroup, files created in /somedir/images should look likerw-rw (actually on my system they end up rw-rw-r-- for some reason). I am speaking simply of file creation, for example, by doing touch junk.txt However, Gimp 2.6.6 on Ubuntu 2.04 refuses to create files using the same methods that every other *nix programs use. This bug WAS CONFIRMED as a bug. This is very important in a multi-user work environment. Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Open a file r/o
On 03/25/2010 05:39 PM, Sven Neumann wrote: Hi, On Thu, 2010-03-25 at 16:57 -0400, Jay Smith wrote: However, Gimp 2.6.6 on Ubuntu 2.04 refuses to create files using the same methods that every other *nix programs use. This can hardly be true in the general sense that you are putting it. Files are created by GIMP plug-ins and how the files are created depends on the implementation of the plug-in. For many formats the actual creation of the file is performed by a library that deals with this particular format. So can you point out the particular file formats that are problematic for you? Sven I finally found the bug report I made: https://bugzilla.gnome.org/show_bug.cgi?id=578630 It was FIXED 2009-06-15 which means that if I can get my Gimp upgraded, then it should work. Unfortunately, I have to depend upon somebody else for that (and get trained on doing it myself, but it is a mission-critical application in our company, so breaking something is not an option). But, to answer your question The problem I am (on 2.6.6) having is with TIF files. Martin N. confirmed this on April 10, 2009 and said === This happens to me as well and from looking at the code it also happens for gbr, gih, pat, pnm and raw which opens a file for writing like this: fd = g_open (filename, O_CREAT | O_TRUNC | O_WRONLY | _O_BINARY, 0644); E.g png instead uses fp = g_fopen (filename, wb); This inconsistency doesn't make any sense, feel free to open a bug report. The latter is identical to the former apart from the permissions, so we probably want to use the latter for all plug-ins. - Martin === ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Removing Matte Texture
On 03/10/2010 08:48 AM, Sandi P. wrote: I appreciate you having a look at these. They are unedited, right from the scanner. You can see them at: http://www.flickr.com/photos/37318...@n04/ Img137 is a sample of matte finish processing that even with Gaussian Blur and Unsharpening can't remove the texture look. Img138 is an example of portrait texture that I'm having problems removing/minimizing. Thanks again. Sandi Could you show us an example of what you get? Sandi, On Img137 (four people), is the shadow behind the people, especially their heads, in the actual photograph or is that an artifact of scanning? If the latter, then there is some other problem. However, I am impressed that they look as good as they do. My wife just scanned a couple hundred pictures of the same era as yours on all sorts of photographic papers, including matte and textured. Your results are in the 97% percentile as far as I am concerned. When you start with crap -- which most old family photos are -- you can't really improve upon them much. You may be able to minimize further degradation, but you can't create quality where it does not exist. Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] ?? Status of remembering Layers setting for Canvas Resizing -- in most recent version
On 03/10/2010 03:27 PM, yahvuu wrote: Martin Nordholts wrote: 2010/3/10 yahvuu yah...@gmail.com: Each of these dialog options points at a potential interaction problem. If the dialog remembers an option, the user also has to remember that option. In general, this amounts to additional cognitive burden to keep the mental model in sync with the application state. Hmm I don't understand, how would there be additional cognitive burden on users if a dialog remembers a setting across invocations? You are right, that was an invalid generalisation. I was thinking of the 'New Layer' dialog where the 'fill' option tends to get in the way. (If i leave that option to a fixed value -- like a prefs item -- there's no problem, i can just hit enter to create the new layer. If i, however, do change this value, i'd better remember this the next time i create a new layer.) The more options we can get rid of, the better. yep, that's what i was after regards, peter I am not convinced that the 'New Layer' example given presents a better situation as described. In my mind, what is being overlooked is that there IS always a state (setting value). The question is a) whether the program always forces the state back to some constant or b) whether the program remembers what the user last set it to. I think there is more cognitive burden _and_ real physical burden in having to always know that the program will always force a setting to a certain value and that the user might always have to change that value. In the 'New Layer' example given, if I am doing a certain repetitive task, it is *highly* likely that I will want the new layer to have the same fill every time I do that function. There is a significant burden in having to change this setting _every_ time. (And to make it worse, some of these settings are not so easily accessible via keyboard, thus wrecking my shoulder from mousing too much.) So, which is better: a) Knowing that the program will always force a default value and having to change it much of the time (in my case for Canvas Resizing, ALL the time). b) Knowing that the user is responsible to paying attention to what the value says when they get to the dialog and if it is correct for the task (which it will then be, once the user has set it, until later changed by the user). There is another option, but a bit more complicated: 1) Make the force to a default vs use last setting a configurable preference. AND 2) Make the value of the default a configurable preference. Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
[Gimp-user] Can the Curves dialog be reversed?
The Color Curves dialog has the black in the lower left corner and the white in the upper right corner. This is the opposite of another program that I also have to use. Is there a way to reverse this default? I am using Gimp 2.6.6 on Linux, Ubuntu 8.04 Hardy. Thanks. Jay -- 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 mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
[Gimp-user] ?? Status of remembering Layers setting for Canvas Resizing -- in most recent version
If this issue has not been addressed yet and if I can't find anything in Bugzilla on it, I want to make an Enhancement Suggestion, first on the Gimp-Developer list, then Bugzilla. However, I don't have the quick or convenient ability to check the current status of this issue in the most recent Gimp version. (I am a user only and am not involved in installing such programs.) I am hoping that somebody who has the most recent version can check this for me. Thanks in advance. Image Canvas Size in the Set Image Canvas Size dialog in the Layers section at the bottom there are five different possible settings, including None, All Layers, etc. etc. In Gimp 2.6.6 (Ubuntu Linux 8.04) this defaults to None and ALWAYS remains none EVERY time I go to the dialog, even if I had it changed to something else on this image or a previous image. I believe that this setting should be remembered a) during the session of editing an image; b) during all sessions editing all images; and c) between sessions of shutting down and restarting Gimp. ?? Can somebody let me know if this has been changed (and is now remembered) since 2.6.6 ? ?? Does anybody think this should not be remembered ? Thanks. Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] ?? Status of remembering Layers setting for Canvas Resizing -- in most recent version
On Tue, Mar 9, 2010 at 4:10 PM, Jay Smith j...@jaysmith.com mailto:j...@jaysmith.com wrote: If this issue has not been addressed yet and if I can't find anything in Bugzilla on it, I want to make an Enhancement Suggestion, first on the Gimp-Developer list, then Bugzilla. However, I don't have the quick or convenient ability to check the current status of this issue in the most recent Gimp version. (I am a user only and am not involved in installing such programs.) I am hoping that somebody who has the most recent version can check this for me. Thanks in advance. Image Canvas Size in the Set Image Canvas Size dialog in the Layers section at the bottom there are five different possible settings, including None, All Layers, etc. etc. In Gimp 2.6.6 (Ubuntu Linux 8.04) this defaults to None and ALWAYS remains none EVERY time I go to the dialog, even if I had it changed to something else on this image or a previous image. I believe that this setting should be remembered a) during the session of editing an image; b) during all sessions editing all images; and c) between sessions of shutting down and restarting Gimp. ?? Can somebody let me know if this has been changed (and is now remembered) since 2.6.6 ? ?? Does anybody think this should not be remembered ? Thanks. Jay On 03/09/2010 05:01 PM, Dick Smith wrote: The behavior is the same on mine. I don't believe that it is a bug, but rather a design issue. That's not an answer to your question, but it looks like it was designed to do that. If it stayed the way you set it up, then every image you'd edit would exhibit the same behavior...is that what you really are looking for? Dick Hi Dick, Based on the way you worded what you said, I am not exactly sure we are speaking of the same behavior. I agree that what I am seeing is a design issue, not a bug. But to a user it has six legs and runs around on the floor. ;-) What I want is that type of setting to default to what I last used. So, yes, I want it to do the same action every time I do that task, until I tell it to do a different action. What it is doing now IS remembering a setting (always the same one no matter what I do) -- what it is remembering happens to be _never_ what I want to do. :-( It seems to me to be more useful to remember what the user does rather than some setting that the user never uses. Imagine if you had to sharpen a pencil EVERY time you wanted to use it. And every time you set it back down on the desk the point completely disappeared. ;-) Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
[Gimp-user] Use of tifftopnm and pnmtotiff to strip images -- ?? meaning of
I hope it's okay to ask this here. The use of tifftopnm and pnmtotiff was suggested in an earlier thread about stripping color profiles from TIFF images. Below I show tiffinfo before and after processing, as well as the tifftopnm and the pnmtotiff processes. ?? On the pnmtotiff, it said: pnmtotiff: computing colormap... pnmtotiff: Too many colors - proceeding to write a 24-bit RGB file. pnmtotiff: If you want an 8-bit palette file, try doing a 'ppmquant 256'. What does this mean Too many colors?? And of what significance might this be to me? I was previously told that this process clips colors but that Gimp does too so there would really be about the same result. What I don't understand is what colors it is getting rid of. (When I look at the before and after images, they look the same to me.) ?? This process also got rid of the Photoshop Data in this old file. I have no idea what that extra data was. Any idea what Photoshop might have added -- I don't put comments into my images. Does it leave empty space for comments even though you did not use comments? The process did cut the file size from 2,850,625 to 2,844,590 which change is LESS than the total of the ICC Profile and the Photoshop Data that were present in the original. It got rid of them, but did not quite reclaim all the space. == tiffinfo BEFORE processing #: /q/images/jsa/source$ tiffinfo 00*tif 0001a_1st-issue_110001.tif: Warning, incorrect count for field MinSampleValue (1, expecting 3); tag ignored. 0001a_1st-issue_110001.tif: Warning, incorrect count for field MaxSampleValue (1, expecting 3); tag ignored. TIFF Directory at offset 0x8 (8) Subfile Type: (0 = 0x0) Image Width: 877 Image Length: 1080 Resolution: 300, 300 pixels/inch Bits/Sample: 8 Compression Scheme: None Photometric Interpretation: RGB color Samples/Pixel: 3 Rows/Strip: 1080 Planar Configuration: single image plane Photoshop Data: present, 5748 bytes ICC Profile: present, 3144 bytes == tifftopnm #: /q/images/jsa/source$ tifftopnm 0001* stuff.pnm 0001a_1st-issue_110001.tif: Warning, incorrect count for field MinSampleValue (1, expecting 3); tag ignored. 0001a_1st-issue_110001.tif: Warning, incorrect count for field MaxSampleValue (1, expecting 3); tag ignored. tifftopnm: writing PPM file === pnnmtotiff #: /q/images/jsa/source$ pnmtotiff stuff.pnm stuff-after-pnm.tif pnmtotiff: computing colormap... pnmtotiff: Too many colors - proceeding to write a 24-bit RGB file. pnmtotiff: If you want an 8-bit palette file, try doing a 'ppmquant 256'. == tiffinfo AFTER processing #: /q/images/jsa/source$ tiffinfo stuff*tif TIFF Directory at offset 0x2b5b90 (2841488) Image Width: 877 Image Length: 1080 Bits/Sample: 8 Compression Scheme: None Photometric Interpretation: RGB color FillOrder: msb-to-lsb Orientation: row 0 top, col 0 lhs Samples/Pixel: 3 Rows/Strip: 3 Planar Configuration: single image plane DocumentName: stuff.pnm ImageDescription: converted PNM file ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] how to select copy a circular part of photo
On 02/10/2010 03:33 PM, Deniz Dogan wrote: 2010/2/10 Donna B. for...@gimpusers.com: I need help with a newbie question (ver 2.6). I need to select a circular part of a photo - the goal is to create a web page with circular photos arranged in a circle. The only way I've found is to draw a circular selection, display the QuickMask to show the outline of the circle and use the bezier tool to click around the circle then select to Path and copy that to a new file. There must be a better way; can anyone describe it? I may very well have misunderstood your question, but can't you just make a circular selection, copy the selection and then paste into a new image? Deniz ... What you understood is what I understood. But allow me to add: 1) Use the ellipse selection tool (immediately to the right of the usual rectangular selection tool in my Gimp). 2) For that tool, in the preferences (which on my Gimp is right below the tools), turn on Fixed for Aspect Ratio. That will get you a circle instead of a random ellipse. You can also specify exact size, etc., etc. 3) Set the background color selector to White (or whatever you want). Do the selection. Invert the selection. [Selection..., Invert] Hit Delete. Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Complaint
On 01/22/2010 09:58 AM, Alexandre Prokoudine wrote: On 1/22/10, BGP wrote: I'm sure you folks are all experts at GIMP but I've found it to be a very hard to learn how to use. But how many hundreds of hours did it take you to learn how to use it? Learning is something you never stop to do. If you stopped learning, you are dead and the coffin with your body is about to be put six feet underground. For example- the tutorials are mostly out of date Did you read *all* tutorials on GIMP? Really? I'm sorry, but I don't believe you. Alexandre While the responses to the original poster are surely technically correct, the original poster _does_ have a legitimate point. It might actually be easier for a person to learn Gimp if they have never used another image editing program. However, for people who grew up on Photoshop, it is a particular challenge to learn Gimp because one must learn substantially new techniques, methods, terminology, concepts, and workflows. And the OP is correct that there is some out-of-date documentation being presented as if it were current. This is especially a problem because many aspects of the UI have changed in the last couple years. And this problem is only going to be much _worse_ when the single-window possibility is available -- the docs will really be behind. The first step in increasing broad acceptance, support, and development of Gimp is to _accept_ its shortcomings and to honestly recognize the challenges that new users face. While long-time users and the developers of Gimp may not feel like Gimp should be treated as a product, the reality is that any new user looking at Gimp is going to make choices and decisions that are product choice decisions. Denial of that fact is complete denial of reality. It is my opinion that many in the open source / free software (OS/FS) arena have long ago forgotten that truism. In my experience the OS/FS world pretty much tells new users that if they are not patient enough or smart enough to figure out the secrets of whatever software, they don't deserve to use it. I feel that is completely backward. The OS/FS community should focus on (as much as software development) the education of new users and bringing them into the community. As an example, while I have not looked for it, I am sure that there must at least be some book or maybe a website here or there that specifically addresses How to smoothly migrate from using Photoshop to using Gimp -- the benefits, challenges, and differences of using Gimp. Such content should be right up front in the whole Gimp documentation, Gimp websites, etc., etc. Every successful organization (and the Gimp community IS an organization of a sort) gets new users/customers by telling potential users/customers how/why their product is better -- and then making the conversion to using/buying their product as easy as possible. The Gimp community could do a lot better at this. And if somebody says we don't care about getting more users, I would ask them then, why make Gimp at all? How about this as an answer to the OP: It took me twice as long to learn to use Gimp as it took me to learn to use Photoshop. I agree that the documentation is behind the curve and needs to be improved. There are a great many things that I still do not know how to do in Gimp and a great many things about Gimp that annoy me to the point of being incredibly frustrated. While Gimp has many incredibly wonderful features, there are still major features missing that significantly hamper my own productivity. However, when I add up and try to balance out all the pluses and minuses, I have come to the conclusion that I would rather use Gimp than Photoshop and that I would rather support Gimp's development than to fund the arrogance of Adobe's/Microsoft's management. When a new user complains, I would rather we say ... Gee, there is a lot of truth in what you are saying and I understand that _has_ been your experience so far. However, there are many great resources available and I hope that you will pursue using those resources so that you can fully benefit from what Gimp has to offer. As an aside, I really think that the documentation issue is going to become critical in the next couple of years. As I understand it (and please correct me if I am wrong), anybody can contribute to the documentation effort, but it takes significant training and skills in the special process involved with maintaining documentation versioning, etc., etc., etc. I don't begin to understand all of that and I DON'T WANT TO have to become an expert in all that stuff -- I just want to help improve the documentation. What I DO want to do is be able to contribute if I see a small problem or have a suggestion as a better way to provide a bit of information, etc. I think it is time to seriously think about putting the documentation in a real Wiki environment where we don't have to worry
[Gimp-user] Gimp Documentation in the future... (from Re: Complaint)
On 01/22/2010 10:57 AM, Alexandre Prokoudine wrote: On 1/22/10, Jay Smith wrote: SNIP As an aside, I really think that the documentation issue is going to become critical in the next couple of years. As I understand it (and please correct me if I am wrong), anybody can contribute to the documentation effort, but it takes significant training and skills in the special process involved with maintaining documentation versioning, etc., etc., etc. I don't begin to understand all of that and I DON'T WANT TO have to become an expert in all that stuff -- I just want to help improve the documentation. SNIP I understand your feelings, but GIMP documentation is a single-source effort that isn't well supported by current wiki engines. Alexandre On 01/22/2010 10:44 AM, Alexandre Prokoudine wrote: On 1/22/10, Jay Smith wrote: SNIP It has been said by GIMP developers in public several times that tutorials at gimp.org are out of date and need reworking. There is no problem accepting the fact, see? There is a problem of people not having spare time to work on that. It's really *that* simple. There's no conspiracy. Alexandre I'm breaking this out into a new thread. In a couple of his responses Alexandre said: but GIMP documentation is a single-source effort that isn't well supported by current wiki engines. and There is a problem of people not having spare time to work on [updating documentation]. Alexandre's second point can be solved by a Wiki. A Wiki would allow and encourage more people to become involved. However, I am ignorant of exactly what the input / output requirements of the single-source effort are exactly. If possible, can somebody point me to a reference which describes how the documentation project/work itself is being done and what the inputs/outputs are and where they live? For example, are the docs such as http://docs.gimp.org/2.6/en/gimp-concepts-usage.html buried inside Gimp itself as comments (as some programs do)? For example, are the multiple languages offered here http://docs.gimp.org/ all maintained in single multi-language documents or database records (for each respective topic page)? And how are they kept in sync and annotated as to what new/changed/removed text needs translating, etc. Sorry if this is a newbie kind of question, but I have not previously run into a discussion of it. I agree that Wikis are _not_ good at: - Multi-language versions maintenance of the same subject page - Output to print - Output to structured documents - Databases as Wikis (but I don't think that applies here, but it is a subject of extreme interest to me if anybody else is interested) Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Pixelation of text
At one point, the OP said something about it printing out too small but it was an okay size on screen, just pixilated. Did I understand that correctly. It sounds like the OP simply has an image that is too small in terms of X by Y pixels. You can blow something up on screen, and increase the resolution to 300 dpi whatever for printing purposes, but if the image pixel size is only 200 x 200 pixels (or whatever) then you are going to have jaggy text. We needed to see the image. ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
[Gimp-user] Is this a bug? Setting image w/corrupted icc profile to sRGB; plugin dies
Hi, GIMP 2.6.6 running on Ubuntu 8.04 Hardy Linux. In the archives I found information that to delete a color profile, you just set the color space (Image, Mode, Assign Color Profile...) to sRGB which apparently is a color space without color profile. There were three TIFF images which PhotoShop 5.x on Windoze would not open due to corrupted color space. These images are believed to have been corrupted years ago when a server had bad RAM and wrecked a couple thousand images being transferred to a particular external hard drive; most were easy to identify as corrupted (i.e. reported, not real, size grew to over 2GB ea; but we still find a few that generally work okay, but have corruption in the profile). I was trying to fix them for another person so that they could open them in PhotoShop. Using the above mentioned technique in GIMP, I fixed one of them just fine. Its corruption (and on-open error message) was different than the other two. However, two others were not fixable by this method. ??? Is this a bug? This is what happened... In the Open File dialog, upon just clicking on the filename (prior to actual opening, but resulting in seeing a preview), Gimp put out error messages: lcms: Error #12288; Corrupted memory profile However, the file _could_ be opened in Gimp. Upon attempting to assign the sRGB to the image (Image, Mode, Assign Color Profile...) just clicking on the last part (Assign Color Profile...) resulted in a) the dialog did not open for doing that task; b) the menu collapsed back to normal state; c) the error message appeared lcms: Error #12288; Corrupted memory profile and d) in the Message Console (sorry, I lost the exact text) it says that the dying plugin... may have left Gimp... unstable state or something like that. So, just clicking to get the dialog to change to sRGB killed the plugin that was do to that task. (In the end I solved my problem by literally copying pasting the image into a new window and then saving that as the same filename.) I _do_ have a saved sample corrupted image file if anybody needs this for testing purposes. Is this a bug? Is it known? Should I post on the developer list? Should I put it in bugzilla? Lastly is there a command-line bulk/batch method to remove color profile (i.e. set to sRGB) on hundreds of image files (TIFF) at a time? Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
[Gimp-user] Image - Flatten Image not available on newly created image with pasted in layer (floating selection)
GIMP 2.6.6 running on Ubuntu 8.04 Hardy Linux. Is this a bug? Should I post this on the developer list instead? Am I doing this incorrectly? At a minimum, I think there is some GUI confusion... at least it is not logical to my way of thinking. This is a little complicated, so please read through before jumping to assumptions. Thank you. I need to make a new image that looks the same as an existing image. The reason for this is not important but I cannot use SaveAs because there is serious ICC profile corruption (it kills the plugin that attempts to assign sRGB profile) and I actually have to copy and paste the image into a new image to get a clean image. So, for whatever inane reason, I need to make a new image with the visual contents of the old image. Procedure: - Select all in old image - Copy - New Image (set to fill background with black). This method gives the new image the exact correct pixel size as the old image -- that's important. (I also want to fill background with black as my default because _sometimes_ I want to make the canvas larger and paste in multiple bits of other images.) - Paste into the new image. This now results in a Background and a Floating Selection. It says Floating Selection it does *NOT* say ... Layer - At this point I want to flatten the image to a single layer with no selection. However 1) Tool set to rectangular marque only acts as a Move tool. 2) Double clicking ON THE IMAGE has NO effect. 3) In the New Image process above, the window size created is the size of the image itself -- there is *NO* outside the canvas background visible. HOWEVER, if I now drag the window larger so that I do have outside the canvas background area and double click in the outside the canvas area, it DOES anchor the image whereas double clicking on the image itself does not have an effect. * I think that is either a bug or a poorly implemented feature * * that the user is forced to drag the window larger, etc. * 4) ALTERNATIVELY, I can go to the menu and do Layer, Anchor Layer. That works just fine. *** BUT, PLEASE NOTE here it says Layer. It says nothing about anchoring a Floating Selection. There is an inconsistency in terminology. If I am working with a Floating Selection I would first think to look in the Select menu items for an action to take. Or perhaps the Image menu items (where Flatten Image is grayed out). 5) Furthermore, what I think I want to do is what I would call Flatten the image. In the docs... http://docs.gimp.org/en/gimp-image-flatten.html it discusses the Image, Flatten Image command. That is what I think I wanted to do all along. (And in PhotoShop 5.x, that is exactly the terminology for what one would do in this case -- but I know this is Gimp, not PS.) *** HOWEVER in this scenario, Flatten Image is grayed out and unavailable. I do not know if, under the hood, making a floating selection merge into the background by anchoring a layer is all the same thing as flatten image, or if they are different tasks. But, at a minimum, there is a terminology problem do something (?what?) with Floating Selection vs Flatten Image vs Anchor Layer To a newbie, this would be more than a little confusing. I do not claim to know the right answer, but at a minimum: 1) The New Image, Paste, Anchor Floating Selection process should be much, much smoother without having to either drag the window larger or even have some way to have it automatically anchored. !!! Perhaps in the New dialog (Advanced section), there could be a method to simply create the new image with the contents of the clipboard so that you don't have to either paste or anchor 2) Sort out the conflicting terminology and menu items / menu locations. Feedback welcomed. Sorry for yammering on. Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Image - Flatten Image not available on newly created image with pasted in layer (floating selection)
On 12/18/2009 01:03 PM, Michael J. Hammel wrote: On Fri, 2009-12-18 at 12:26 -0500, Jay Smith wrote: Procedure: - Select all in old image - Copy - Paste into the new image. This now results in a Background and a Floating Selection. It says Floating Selection it does *NOT* say ... Layer A Floating Selection is a selection that has been pasted into the image but not given a final disposition for integration with the image. You must either make it a new layer or apply it to the current layer/layer mask. Until you make that choice the floating selection is not a layer yet which is why you can't flatten the image. A faster way of doing what you want (assuming I understood it correctly) and skipping the floating selection is to drag the layer from the old image into the toolbox. This will create a new image window with the same dimensions as the original with a single layer in it. You can then add a new layer that is black, drag it below the current layer in the Layers dialog and then flatten the image. Michael, Thank you very much for the procedure suggestion. Really Cool!! I will experiment with that. How would I have known that? Maybe I should RTFM? But. However, regarding your first paragraph, I understand what you are saying and do not argue with it. My point is that you are saying is NOT what the program says because in order to flatten it using the menu system (other than dragging the window larger and double clicking) I have to go to LAYER, ANCHOR LAYER. See the terminology confusion? Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Is this a bug? Setting image w/corrupted icc profile to sRGB; plugin dies
On 12/18/2009 02:02 PM, Sven Neumann wrote: On Fri, 2009-12-18 at 11:56 -0500, Jay Smith wrote: I _do_ have a saved sample corrupted image file if anybody needs this for testing purposes. Is this a bug? Is it known? Should I post on the developer list? Should I put it in bugzilla? Your files are corrupt. You can't possibly expect GIMP to fix them. Of course if you really care, you could probably write some code that is capable of dealing with your broken files and that may even be able to fix them. But don't expect this work to be done by someone else for you. Sven Sven, Yes, the file is corrupted. And, no, I didn't and don't expect Gimp to automagically fix it for me -- though sometimes (as in one of the three files) it does fix it; maybe that functionality should be removed? So, when there is a problem with a file, Gimp is one of the tools I reach for first, just in case Gimp can help. I think my point was somewhat misunderstood and I feel that the tone of part of your response is less than friendly. I was trying to point out something that could perhaps be _helpful_ but instead I feel a bit slapped down. There is a reason that new users often feel unwelcome in such arenas. My point is that the *error/reporting messages say* that (because of the corrupted file) the plugin has died and potentially left Gimp in an unstable state. If I were a developer, with the necessary skills, I would be curious about what was killing off the plugin and why the plugin dieing (especially when it was just trying to open a dialog and had not actually attempted to take action on the image yet) would leave the whole program in a potentially unstable state. Perhaps that's just me. The file is okay enough to display a preview, to be opened, to be edited, and to be saved, etc., in Gimp (but it can't even be opened in PhotoShop 5.x). So already Gimp is more robust. That robustness surely came by design, intent, and application of considerable skill. My _intent_ was that somebody with the proper skills might be interested and might want to look at the plugin to see what about it is not as robust as the rest of the program environment. By sharing my experience and making sure I have available a sample of such a corrupted file, I make such exploration possible for anybody with the skills and interest who is curious about it. If nobody is curious about it, then fine -- not a problem. At NO point do I recall asking anybody to do any work for me. I was attempting to contribute and share and experience and information. I infer from your response that I have been instructed to think twice before trying to get involved again. I apologize for wasting your time and some electrons. Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Image - Flatten Image not available on newly created image with pasted in layer (floating selection)
On 12/18/2009 01:41 PM, Michael J. Hammel wrote: On Fri, 2009-12-18 at 13:15 -0500, Jay Smith wrote: Thank you very much for the procedure suggestion. Really Cool!! I will experiment with that. How would I have known that? Maybe I should RTFM? But. Maybe the manual mentions this. Maybe not. That's the way of documentation (even with commercial apps). There are always tricks to doing things with software. You learn by doing. Experimentation is king. 'Course, asking on mailing lists and forums doesn't hurt. However, regarding your first paragraph, I understand what you are saying and do not argue with it. My point is that you are saying is NOT what the program says because in order to flatten it using the menu system (other than dragging the window larger and double clicking) I have to go to LAYER, ANCHOR LAYER. Actually, you can also use the Layers menu in the Layers dialog - right click on the floating selection (or any layer) to see it. See the terminology confusion? Sure. But I ignore it. They say tomaeto, I say tomahto. Doesn't change what you have to do to make it work. Don't get too hung up on terminology. Spoils the fun. ;-) I suppose they could say Anchor To Layer instead. Feel free to suggest it to the developers or the documentation project. Or maybe the floating selection should be referred to as a floating layer instead. I often refer to the image window as the canvas window in my articles and books. I believe the term image is highly overused and a potential source of confusion too. All you have to do is convince everyone to say the same thing every time the reference something. Good luck. :-) Hi Michael, I am left wondering if I have still failed to communicate the basic point I was trying to make. I will give it one more short go, but at the risk of annoying Sven any further and wasting everybody's time, I should stop there. However, I must *extremely strongly* disagree with you regarding use of terminology. It is all we have to communicate clearly about such things. To a new user, it is absolutely critical -- I know that this is a professional level program, etc., but even a highly skilled new user is bombarded with new different terminology in Gimp compared to other programs they may have used and they are dealing with a user interface which may not be familiar. I have only been using high-level image editing programs for production work for 15 years but I struggled with Gimp for the first few months I used it -- a lot of that struggle was due to terminology and the quirks of the user interface. I remember, back in the day, when I was a newbie starting to use PhotoShop -- I felt no such sense of struggle; everything just flowed and seemed natural. Maybe that experience (and use of non-Gimp terminology, etc.) ruined me for Gimp -- BUT, I would guess that most Gimp new users are going to now come from other programs and they will not be image-program virgins. I am pushing my company hard toward linux as desktop. (I know that Gimp is NOT a linux program, per se, but it is a leading application for linux users and its challenges in the linux desktop parallels some of the other linux desktop challenges due in part to the methods by which it is developed.) This push is a struggle because there are still large number of linux apps that are just (still!) not yet ready for the mainstream desktop. And these issues have everything to do with mundane and tedious-for-some-developers things like user interface and consistency of menu terminology, consistency of style in open file dialogs, etc., etc. Working on this stuff is probably neither fun nor sexy. However, IMHO, it is an extremely important step toward wider adaption of linux as desktop and toward ever-increasing success for Gimp. a) *You* originally made the point out that a Floating Selection is a Floating Selection and is *not* really a Layer. I am much more in agreement with your more recent statement that perhaps there could be more consistency in calling it a selection vs a layer, etc. There are two, or maybe three, places in the menu that it could be. Layer, Anchor Layer was the least obvious *to me.* b) *You* also originally made the point that until the Floating Selection is anchored, the image cannot be flattened. Here I disagree -- from a USER's rather limited point of view. The user does not much care what is under the hood, the user just wants the newly pasted in content flattened into the layer onto which it was pasted -- by whatever means or terminology it takes. Yet the menu system (whether top bar or right click) makes you anchor it first before you can flatten it -- BUT and this is a big point -- in this situation anchoring it DOES flatten it. I understand that there certainly could be many layers, so one probably does not want to flatten the entire image into a single layer. However, this is still quite awkward and does not seem
Re: [Gimp-user] Is this a bug? Setting image w/corrupted icc profile to sRGB; plugin dies
On 12/18/2009 03:16 PM, Sven Neumann wrote: Hi, On Fri, 2009-12-18 at 14:33 -0500, Jay Smith wrote: If I were a developer, with the necessary skills, I would be curious about what was killing off the plugin and why the plugin dieing (especially when it was just trying to open a dialog and had not actually attempted to take action on the image yet) would leave the whole program in a potentially unstable state. The message that tells you about the dying plug-in is just a general dialog. It says that GIMP 'might' have been left in an unstable state. In general this is not the case and there's nothing to worry about here. I have written the plug-in that crashed, and I can tell what's most likely going wrong, without having a look at the code or your broken image. The assumption that the plug-in would not have accessed the image before it opens the dialog is wrong, since the plug-in needs to read the color profile from the image in order to present information about the current color profile to the user. If the attached profile is corrupt, then it may crash at this point. I don't really care about fixing this for all sorts of corrupt input data. Such a fix would most likely introduce regressions and would make the code much more difficult to read and maintain. You can probably get the plug-in to do its job of removing the attached color profile by calling the plug-in procedure non-interactively. Or you could simply remove the icc-profile parasite from the image. Sven Sven, Thank you very much for this information. It is very helpful. When I originally searched for information about how to do this, before I posted, I came across a discussion of the subject -- and you were a participant. But, what I have _not_ found information about how to do is: a) Call the plug-in procedure non-interactively b) Use gimp_image_parasite_detach -- I am not sure in what environment this is used, etc. I found http://authors.phptr.com/essential/gimp/appE/gimp_image_parasite_detach.html but can't figure out how to run it (from the command line does not work). c) simply remove the icc-profile parasite from the image as you suggest. This is what I wanted to do all along, from the very start, but somehow my searching is not finding instructions. I must not be searching with the correct search terms. Any advice would be appreciated. By the way, if possible, I would like to do this parasite removal on tens of thousands of files. Perhaps as the 'exec' of a 'find' command. Thanks! Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Is this a bug? Setting image w/corrupted icc profile to sRGB; plugin dies
On 12/18/2009 05:48 PM, Sven Neumann wrote: Hi, On Fri, 2009-12-18 at 15:39 -0500, Jay Smith wrote: By the way, if possible, I would like to do this parasite removal on tens of thousands of files. Perhaps as the 'exec' of a 'find' command. I don't understand why you are even considering to use GIMP then. If all you care about is the image data, then a simple tifftopnm | pnmtotiff will probably do the trick. Sven Hi Sven, I am afraid I am not 100% following what you are saying. Perhaps I miscommunicated. Or perhaps I am just not filling in assumed knowledge well enough. I want to use Gimp as an image editor. However, there are thousands of images that have been created over the years on different versions of various programs, some of which have varying ICC profiles embedded. And, then, importantly, there are apparently some that have corrupted ICC profiles which were caused by a major data corruption event years ago. So, I was asking about how to get to sRGB for all them (i.e. remove the color profile). You had mentioned some methods, but I don't have enough information on how to use those methods. Perhaps I am really missing something -- in Gimp is there a method / command to (one at a time) remove the color profile parasite? That question was never answered in the archived newsgroup messages I have read. Instead there is reference to changing it to sRGB which apparently accomplishes the same thing as removing the color profile parasite. I thought that I had once done some method/command in Gimp to remove the color profile parasite, but perhaps I am mis-remembering. My goals are two-fold: a) When I find an individual image with a corrupted profile, I wish to remove the color profile parasite. (Changing to sRGB is not an option due to the previously discussed problem that it is a corrupted file and of course the plug-in is not always going to be happy with it.) I am no farther along in understanding whether Gimp has a tool to do this. b) I would like to find a method to remove color profile parasites on thousands of images, via the command line. You have suggested trying tifftopnm | pnmtotiff do to this. I will experiment with that, but I have a concern as noted below. Based on your most recent recommendation, I looked at http://netpbm.sourceforge.net/doc/tifftopnm.html and I am not sure how this helps me, unless you are suggesting to ROUNDTRIP using these two programs. However, I noted it said [below] that theoretically you can lose information in certain cases. I have no idea if my images would be affected by that. The PNM output has the same maxval as the Tiff input, except that if the Tiff input is colormapped (which implies a maxval of 65535) the PNM output has a maxval of 255. Though this may result in lost information, such input images hardly ever actually have more color resolution than a maxval of 255 provides and people often cannot deal with PNM files that have maxval 255. By contrast, a non-colormapped Tiff image that doesn't need a maxval 255 doesn't have a maxval 255, so when tifftopnm sees a non-colormapped maxval 255, it takes it seriously and produces a matching output maxval. Another exception is where the TIFF maxval is greater than 65535, which is the maximum allowed by the Netpbm formats. In that case, tifftopnm uses a maxval of 65535, and you lose some information in the conversion. Thanks. Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Gimp Users - getting colors to match.
If you don't like absolutely on-point discussion, please delete this email now. Sometimes there is more to the situation than can be said in 20 words. Thank you. I am glad to see some mention of this subject: color Background: We are on an extended migration from Windows with mixed platforms (Win95, Win95, W2K Pro, and XP Pro) to Ubuntu Linux. We have always used Unix and then Linux servers, but with Windows workstations -- which in turn, for some apps, ran Linux under Cygwin. We are now using Ubuntu Linux workstations and are trying (with only partial success) to migrate our workflow and applications usage to the equivalent Linux apps. Unfortunately, there are a lot of things that I could do on Win95 that I still cannot do efficiently/effectively on Linux. I wish that more Linux developers would get down in the work-a-day trenches with us humble users and see how difficult some simple things are under Linux, compared to older Windows. Don't get me wrong ... I strongly dislike Microsoft and I want _off_ of Windows! Regarding color: We had previously been scanning large volumes (nearing 50,000 now) of images (postage stamps) using Photoshop 5.5 on Win98 (yeah, right ... blue screens and all). We have been using Epson Perfection 4490 Photo scanners, which I highly recommend for this task. The color was terrific. We have spent months experimenting with scanning, using the same exact scanners and the exact same monitors. We have scanned from inside gimp and with standalone scanning products. However, we have been editing (rotating, cropping, etc.) in Gimp. For scanning, we have used Xsane, VueScan Pro, and anything else we could find. We simply have not been able to get the color to come anywhere near an acceptable, accurate range. We have fiddled and fiddled and fiddled, but we just can't seem to get there. The situation is so important that we are going to have to buy another Windows XP and run it under VMware from inside the Linux, and within that, run Photoshop and use the scanner manufacturer's TWAIN driver. (Unfortunately, we can't use our existing W2K which we run under VMware because, apparently, to get the scanner's USB to work, you have to use W2K's Service Pack 4 ... and anything after SP2 let's the elephant's trunk under the edge of the tent. I would not be surprised if MS someday intentionally kills those SP3 SP4 W2K systems with an upgrade.) I know that some of this is not a Gimp-specific problem, but some of it may be. The larger point is that for Linux to really become mainstream, everything running on it has to work at least as well as Win98 ... and that is not saying much! This is really frustrating because I _want_ a Linux/Gimp solution to work, but I can't spend any more months in failed experiments. If I can do the task using the exact same physical monitor, computer box, and scanner... using XP under VMware on Linux... why should I not be able to do it natively in Linux with at least the same, if not better, color quality. More holistic attention needs to be paid attention to this subject in my opinion. Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Scaling a foto
On 08/17/2009 11:33 AM, Monika Himpelmann wrote: Dear all, I have a question and maybe it is easy to answer and has been answered before although I didn't find it in the FAQ's. When I try to scale a foto in order to get it passport photo size it looses quality. The fotos I want to scale are of good quality but too large and are showing not only the head and upper chest of people but often more and so I have to cut them which is possible without any problem and then scale them in the format I need. I would understand the loss in quality if I would try to enlarge the fotos but making them smaller in size should not make them loose quality??? Any hints from you out there? Thank you in advance for any answer. Best wishes Monika Monika, I agree that it does not make sense to loose quality when scaling smaller. The only thing I can think of is that if the photos are JPEG / JPG (or some other lossy format then, *EVERY* time a photo is saved it looses quality. If somehow in the process you are saving it multiple times, then you might loose quite a bit of quality. With JPEG (that you want to keep as JPEG) that best method is probably to make a copy of the file and then open the copy in Gimp. Do all your work on it (scaling, cropping, etc.) WITHOUT doing any saving until you are DONE. Then save it. When you do that save, select the highest possible quality setting. If in the future you have to open the file for some reason (for example, printing) do NOT save it again in the process of closing it (unless you have specifically made some change that you really intend to save -- but understand you will lose some quality. If that is not the problem, then the situation really does sound odd. Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Scaling a foto
On 08/17/2009 06:38 PM, Patrick Horgan wrote: Jay Smith wrote: Monika, I agree that it does not make sense to loose quality when scaling smaller. I'm confused I think. Isn't scaling smaller an inherently lossy process? If there's information in a section that's 20 bits across and it gets reduced to 5 bits across it isn't possible to still contain the same information, is it? Patrick As you state it, my understanding is, yes. Scaling smaller is a lossy process. But at higher compression (more lossy) settings, JPEGs can be extremely lossy. Hopefully, however, when scaling smaller, there is adequate data in the image to not result in actual visible loss of quality in the image (other than it is smaller, etc.). However, my point was that if the user is one who, perhaps simply out of habit, saves every time they do anything, a JPEG can be turned from sharp and clear into visual mush after just a few saves. Back in the days when I was using Photoshop on Windows 95 on a 128 MB memory machine, I _did_ save every time I did anything simply because Windoze was going to crash -- it was not a question of IF it was going to crash, it was only a matter of WHEN. (But... I was editing TIFFs, not JPEGs, so there was no lossyness.) Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Please ,check this image
On 08/01/2009 08:37 AM, Martin Nordholts wrote: On 08/01/2009 01:05 PM, photocomix wrote: i never noticed a similar bug, even if i used Gimp to save as copy thousands of jpeg, and i would never believed this possible, but i have to face evidence to the point image dimensions: 90x116 Size: 547KB And what is really weird is that seems impossible , re-saving from gimp as jpg reduce the file size...even at quality 1 ( !!) i can't shrink it The JPEG has an embedded ICC color profile which GIMP ignores since it's a CMYK profile, but it keeps it around anyway and writes it to the JPEG if you resave it. To see the size of the attached color profile, first extract it: $ exiftool -icc_profile -b -w icc lightbulb.jpg Then look at how big it (and the image) is: $ du -hb lightbulb.* which gives the output 557168 lightbulb.icc 560484 lightbulb.jpg / Martin Martin, Very enlightening. In normal use of the program, how would the user known that there was such an embedded ICC color profile and thus to use the technique you outlined? Or is this just one of those you have to know kind of situations? Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] batch mode in gimp, add alpha, change color
On 07/27/2009 11:10 AM, Marc T. wrote: On Mon, 2009-07-27 at 16:30 +0200, Marc T. wrote: i am on a similar problem, i have to build a batch script that slices over 6000 images very big images into seven pieces. David's Batch Processor should be able to do the job, not by slicing but by cropping each slice out of the image one at a time. Not the most efficient technique, but it should work. -- David thanx for the quick reply, but i really need to start the process from command line, to integrate it into a bigger workflow. and efficensy is a big isssue also, otherwise i could just stick to imagemagick i basically just need to know how i can start python batch scripts from commandline, can't find anything via google... maybe it's too simple.. Mark, I am speaking _without_ much experience here, and I am not the one who wrote the scripts, but we process thousands of images in large small batches using ImageMagick. We use Perl, which has a ImageMagick module (or whatever you call it). We have one Perl script that does the actual work. However, we use an outer wrapper Perl script to do the finding of the files that need to be worked on. We run from the command line. As far as I know, we are starting ImageMagick only once. The process looks at about 40,000 potential source tiff images and makes sure that none are newer than the about 160,000 target jpeg images. If any tiffs are newer (or the jpegs don't exist), from each tiff, we make 4 jpegs of different output pixel dimensions, based on a complicated algorithm determining/scaling output pixel dimensions based on input image size (physical dimension as 300 dpi tiff). If no images need to be made, then the whole thing runs in about 3 minutes or so. (This is on a fairly old RedHat 8 linux server -- if it was running on my new workstation and if the files themselves were on my new workstation, it would at least double the speed.) When images do need to be made, if the source tiffs are small (i.e. 300 KB), then they only take a couple seconds each. If the source tiffs are large (i.e. for us 10-20 MB), then they take maybe 6-10 seconds each depending upon what else is happening on the system. Again, these speeds could surely be at least doubled on better hardware. Regarding your really big images 1 GB, if you are working with stuff like than, then you need to be working with hardware that has enough memory. Images that large (perhaps these are satellite photos?) are surely important, thus get a system that can do the job. Even my lowly workstation has 4 GB of RAM and two 1 TB hard disks and dual quad-core (2 GB I think?) processors. I think I spent $700 on it, not including the monitor. The hardware cost is NOT the problem. The problem is the skilled time to configure this kind of stuff to _really_ work. Look at Perl with ImageMagick. Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Gimp Manual format.
-Original Message- From: gimp-user-boun...@lists.xcf.berkeley.edu [mailto:gimp-user-boun...@lists.xcf.berkeley.edu] On Behalf Of John Culleton Sent: Thursday, 18 June 2009 11:36 PM To: Gimp-user@lists.xcf.berkeley.edu Subject: [Gimp-user] Gimp Manual format. Is the Gimp online manual also available in another format? Currently I am printing out the html pages a small batch at a time. That's a tedious process. A printed version or even a version in a single electronic file would save a lot of time. A printed and bound version would be handier to use than a ring binder of 8.5 x 11 pages. Once I printed out the 880 pages of the Kylander Manual but that dated back to version 1 or thereabouts. That was as I recall in a single file. Therefore I could print it out using poor man's duplexing, (even pages first, then reload the paper stack and print odds.) On 06/18/2009 10:40 AM, Michaela Baulderstone wrote: I agree! A PDF version would be fantastic Anyone interested in the job? I know nothing of the workflow that results in the current HTML manual format. It would seem to me that producing one or more other formats should come out of that same workflow. I cannot imagine the labor would be justified to do a one-time-only current-state PDF version that would be almost instantly out of date. That probably means that the authoring workflow and environment needs to be considered. This type of documentation is one of the prime beneficiaries of single-source, multiple-output authoring tools. I have not kept up on the current state of those tools and I am especially not aware of their status and capabilities in the open-source arena. However, I do know that there are a variety of approaches, each with their strengths and weaknesses. Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] How do I effectively use a blue screen scanning method with gimp
On 06/13/2009 02:46 PM, Chris Mohler wrote: On Sat, Jun 13, 2009 at 1:08 PM, Jay Smithj...@jaysmith.com wrote: [big snip] So I am hoping for suggestions as to a) how to avoid the color shadow of using a colored background and b) if it cannot be avoided, how to fix it in gimp without a lot of messing around and/or other color distortion problems. Have you tried putting something heavy on the colored background (I tend to use a thick book)? This may reduce or eliminate the shadow. Have you tried reducing the wand (or select by color) tool's threshold when selecting the black background? I would guess that the postmark color and the background color differ at least slightly. A couple of the raw scans of the stamps might be useful for analysis. Chris Yes, we have weighted the item on the scanning bed. The scanner is able to pick up the thickness of the postage stamp paper (the shadow caused thereby) because from either the leading or trailing direction, the light source causes a very slight shadow that the scanner detects. And, yes, we have played extensively with the selection tool's threshold. Doing so solves problems in some spots, but creates problems in others. The shades of black are quite variable. === Using a blue screen method in which I would use a background of some outrageous color that is not present anywhere in the items to be scanned, what would the best tool/method to use to select and eliminate ALL of that color? Again, the problem is that the background itself can be removed, but at the above described shadow edge, there is a gradation of color. Of course the catch is that there is no background color will work all the time. I can't simply delete all reds or all blues or all ...whatever. Ideas? Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
[Gimp-user] How do I effectively use a blue screen scanning method with gimp
Using Gimp 2.6.6 on Ubuntu 8.04 (Hardy) Linux. (Working great, NO crashes as some people complain of.) The answer to this question is not as straight-forward as it sounds. Problem: - Scanning (xsane from within gimp) images of canceled postage stamps. (Also tried with Photoshop/Windows using various scanner drivers.) Usually there are 10-30 stamps in each scan (for productivity) which are then cut apart into individual images. We scan up to hundreds per week, thus this is an ongoing issue. - The stamps' designs are of varying colors, though their paper is usually white-ish and the designs of the stamps usually does _not_ reach the edge of the paper. - However, the _postmarks_ (usually black) DO reach the edge of the stamps' paper. - The desired end result is the stamp on a black background, like this: http://jsa.viewimage.net/jsa/web/Lists/Finland/SpecStamps/Regular/sc0197_used-fvf-superb-pm_142761_r_m.jpg - We usually scan against a black background and this works well unless the postmark reaches the edge of the stamp paper as in the above image. Even though we are scanning against a black background, it is never 100% black and we consider it _critical_ to make it 100% black. Thus we select the black background/surrounding area and fill it with black. However, in the process of selecting the background/surrounding area, it is almost impossible for the selection to avoid eating into (and following) the postmark into the design. We thus have to manually, tediously exclude the postmark from the selection before filling with black. Experiments so far: We have tried using TV's equivalent of a blue screen by which the stamps are against a colored background that is intended to be replaced with a different color. We have tried using backgrounds of various colors (physically putting colored paper on the scanner back), but invariably, we run into the problem of a shadow of whatever the background color is along the stamps' perforations on one or more sides. The result is different from one model of scanner to another, but they all seem to have a direction of light travel and thus at least one side has a shadow of whatever color. This seems to be the nature of flatbed scanners. Removing that color shadow is even more problematic than deselecting the postmark problem areas. Using a digital camera has not produced the desired results, both from a productivity standpoint and a quality standpoint. Clarity and focus of image quality is absolutely critical. Good enough is not good enough. There are lighting problems, distortion (curvature, plane, depth of field) problems, etc, etc., etc. to say nothing of the need to keep the object flat and digital cameras don't like shooting through glass (we have purchased heavy optical glass, but end up seeing the second side of the glass). And that is all before the issue of background color which still remains! So I am hoping for suggestions as to a) how to avoid the color shadow of using a colored background and b) if it cannot be avoided, how to fix it in gimp without a lot of messing around and/or other color distortion problems. Thanks. Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
[Gimp-user] How do I use measure tool in mm
Using Gimp 2.6.6 on Ubuntu 8.04 (Hardy) Linux. I can't seem to figure out how to get the measure tool to show results in mm. So far the only way I have been able to figure out how to measure in mm is to: select the region I wish to measure, copy, create from clipboard, and then use one of the print size or scale dialogs and change the units in that dialog to mm. There has to be a better way. Thanks. Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] How do I use measure tool in mm
On 05/28/2009 10:59 AM, Olivier Lecarme wrote: On Thu, May 28, 2009 at 11:59 PM, Jay Smith j...@jaysmith.com wrote: Using Gimp 2.6.6 on Ubuntu 8.04 (Hardy) Linux. I can't seem to figure out how to get the measure tool to show results in mm. So far the only way I have been able to figure out how to measure in mm is to: select the region I wish to measure, copy, create from clipboard, and then use one of the print size or scale dialogs and change the units in that dialog to mm. There has to be a better way. David Gowers wrote: It's a bit too late in the day for me to check here -- however, I thought that the Measure tool typically used image units -- so if that's set to mm, so should the measure tool give mm. I'm pretty sure this happened for me with inches, it was quite annoying in my case. On 05/28/2009 10:59 AM, Olivier Lecarme wrote: The measure tool uses whatever unit is specified in the bottom of the image window. Aha! Thank you Olivier! What I was missing was that the default at the bottom of the image window seems to be px. I did the measure and was seeing px in the info dialog. I _did_ then change to mm at the bottom of the image window, but the info in the info dialog did not change dynamically when the setting at the bottom of the image window was changed. However, now that you have mentioned this, I tried again and RE-measured after changing the bottom of the image window to mm and now, yes, the mm info is additional in the info dialog. !! It would be nice if the info dialog would refresh dynamically when the setting at the bottom of the image window changes. Otherwise I still don't know how to change the _default_ to mm. Can that be done? I don't see anything in Edit Preferences or Edit Units that sets a default. In general, IMHO one of the weaker areas of gimp is the seeming lack of ability to set/save/remember default units in quite a few dialogs. Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Are these bugs? Missing/duped menu mnemonics non-working keystrokes (per menus)
On 05/06/2009 12:01 PM, Nathan Lane wrote: As an update, I don't see that any keyboard shortcuts are set to Alt+E in my keyboard shortcuts default list. Naturally because the Edit menu has the mnemonic E and Alt refers directly to the menu system in Windows (I don't know what OS you are using), I expect Alt+E to open the Edit menu. In the Edit menu, I do see that three items have P underlined, but Alt+P does not affect them, and both Paste and Paste As sub items have their keyboard shortcuts. Preferences does not have a keyboard shortcut listed next to it, but I can just as easily use my arrow buttons or mouse to open that item. I don't understand the complaint fully. 2009/5/6 Nathan Lane nathamberl...@gmail.com mailto:nathamberl...@gmail.com Uhm, you can change your mnemonics or keyboard shortcuts Edit Preferences Interface Configure Keyboard Shortcuts... and just take care of it for yourself. There's not really a reason for that to be a bug when it's fully configurable. 2009/5/6 Jernej Simončič jernej.listso...@ena.si mailto:jernej.listso...@ena.si On Tue, 05 May 2009 18:36:00 -0700, bgw wrote: In my system, ALT E followed by a letter seems to select an entry whose first character is that letter: Paste, Paste as, and Preferences. IMHO, this should count as a bug - mnemonics should be unique, and every item should have a mnemonic (which isn't necessarily the first letter). -- Jernej Simon+AQ0-i+AQ0- http://eternallybored.org/ Nathan, 1) Edit, Preferences does have a mnemonic of p (the p is underlined). While not a keyboard shortcut, it is in the category of a productivity enhancer because one goal is to avoid having to use a mouse. Mice just slow down most things -- and cause health problems. 2) The problem is that ALT+e p (hold ALT while typing e, then type a p by itself) results in ONE of THREE different things happening depending upon whether or not you have done that action previously or not (it cycles through the three possibilities) in that session of editing that image. The way that this is supposed to work is that one should be able to do such actions *without looking* at the monitor to see what the status is. In other words, one should be able to type ALT+e p and *every* time get the exact same result without regard to whether or not you have done that action previously in that session of editing that image. Have to look watch be careful is not productive and causes lots of errors. 3) As to your comment that because you can configure something to correct undesired behavior it is not a bug... I do *not* accept that. That would be like saying though a program crashes without special configuration, if you do some special configuration it won't crash, thus the crashing is not a bug. While my comparison is extreme, I respectfully submit that this not a bug because... approach to thinking about it is a *huge* reason why non-technical folks find so much open-source software to be not ready for the desktop. We, who are interested in moving forward the spread of open-source software, should be paying very close attention to the ORDINARY USER EXPERIENCE and we should be doing everything we can to make things work extremely smoothly right out of the box. We should not dumb down software, but we sure should try everything possible to make it work smoothly and in an expected, repeatable manner. Just my opinion! Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
[Gimp-user] Are these bugs? Missing/duped menu mnemonics non-working keystrokes (per menus)
Using Gimp 2.6.6 on Ubuntu 8.04 (Hardy) Linux. on K Desktop Environment 3.5.10 I would like to check with others whether or not these issues are unique to me, my installation, or my desktop environment If they are bugs, I will report them or others are welcome to do so (but please tell me if you do). 1) Missing mnemonics on menus. For example, under FILE, Create has no labeled mnemonic. 2) Duplicated mnemonics on menus. For example, under EDIT, the letter p is used ***THREE*** times, making it useless in a production environment. As long as the same image is open, doing ALT e p cycles through the the three occurrences of the p mnemonic. If it is the first time with the image, then it always goes to the first occurrence. Very obnoxious! 3) Misdirected mnemonics. (This one may be a lack of understanding of menu mnemonics on my part.) ALT e p [!!! may have to hit p multiple times to arrive at the correct desired location of PASTE AS] to get to PASTE AS. This exposes the fly-out/sub-menu. The sub-menu includes NEW IMAGE with a mnemonic of n. However, typing an n at this moment does not utilize the fly-out menu, it goes to UNITS on the main EDIT menu. What is the point of having a mnemonic on the flyout/sub-menu if you can't access them without using the arrow keys to get into the flyout/sub-menu by which time you are focused on the desired item anyway and can just hit return. 4) Non-functioning keystrokes / keyboard shortcut listed on the menus. Specifically for me at the moment, CTRL SHIFT V is supposed to create a new file from the clipboard contents. This set of keystrokes is stated in TWO places: FILE, CREATE, FROM CLIPBOARD and EDIT, PASTE AS, NEW IMAGE Both should accomplish the same thing, but on my system, it does nothing at all. This is really annoying because tomorrow I have to have a staff member use this functionality 297 times. Argh! (Yes, I know that as long as we use keystrokes to get to the menu, we can walk though it using the arrow keys. It is just annoying.) Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Are these bugs? Missing/duped menu mnemonics non-working keystrokes (per menus)
On 05/05/2009 09:35 PM, Owen wrote: Using Gimp 2.6.6 on Ubuntu 8.04 (Hardy) Linux. on K Desktop Environment 3.5.10 I would like to check with others whether or not these issues are unique to me, my installation, or my desktop environment If they are bugs, I will report them or others are welcome to do so (but please tell me if you do). 1) Missing mnemonics on menus. For example, under FILE, Create has no labeled mnemonic. 2) Duplicated mnemonics on menus. For example, under EDIT, the letter p is used ***THREE*** times, making it useless in a production environment. As long as the same image is open, doing ALT e p cycles through the the three occurrences of the p mnemonic. If it is the first time with the image, then it always goes to the first occurrence. Very obnoxious! 3) Misdirected mnemonics. (This one may be a lack of understanding of menu mnemonics on my part.) ALT e p [!!! may have to hit p multiple times to arrive at the correct desired location of PASTE AS] to get to PASTE AS. This exposes the fly-out/sub-menu. The sub-menu includes NEW IMAGE with a mnemonic of n. However, typing an n at this moment does not utilize the fly-out menu, it goes to UNITS on the main EDIT menu. What is the point of having a mnemonic on the flyout/sub-menu if you can't access them without using the arrow keys to get into the flyout/sub-menu by which time you are focused on the desired item anyway and can just hit return. 4) Non-functioning keystrokes / keyboard shortcut listed on the menus. Specifically for me at the moment, CTRL SHIFT V is supposed to create a new file from the clipboard contents. This set of keystrokes is stated in TWO places: FILE, CREATE, FROM CLIPBOARD and EDIT, PASTE AS, NEW IMAGE Both should accomplish the same thing, but on my system, it does nothing at all. This is really annoying because tomorrow I have to have a staff member use this functionality 297 times. Argh! (Yes, I know that as long as we use keystrokes to get to the menu, we can walk though it using the arrow keys. It is just annoying.) OWEN SAID Hi, Let's start off saying that the problem is yours. There is something seriously wrong with your installation. I don't know how far your Ubuntu Hardy 8.04 has been upgraded, but you cannot install 2.6.6 without two major libraries that were not in the 8.04 distribution, and as well, GTK (and GLIB) need to be updated for 2.6.6 to work So perhaps you can explain how you got 2.6.6 onto your 8.04 or, just go the 9.04 route where you won't have these problems. Hi Owen, Thanks. I had no idea that it did not work because other than a couple little niggling things like this it has been working great. We have been keeping the Ubuntu Hardy 8.04 up to date every 5-15 days and have been doing so since about November 2008. I can only assume that the dependency checking stuff grabbed the additional libraries needed if we did not already have them. We run a lot of stuff, and run it hard, on 8.04 and so far everything is working, except for the occasional odd items like I have described. I will inquire further with my guy who maintains the Ubuntu. Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Are these bugs? Missing/duped menu mnemonics non-working keystrokes (per menus)
On 05/05/2009 09:36 PM, bgw wrote: I'm using Fedora 10; GIMP 2.6.6. Jay Smith wrote: Using Gimp 2.6.6 on Ubuntu 8.04 (Hardy) Linux. on K Desktop Environment 3.5.10 I would like to check with others whether or not these issues are unique to me, my installation, or my desktop environment If they are bugs, I will report them or others are welcome to do so (but please tell me if you do). 1) Missing mnemonics on menus. For example, under FILE, Create has no labeled mnemonic. I don't understand this problem. Hi BGW, In the main menu, under File one of the items is Create. There is no underlined letter in the entry for Create. Thus I can't do something _like_ alt f t (or whatever) to get to the Sub-menu. 2) Duplicated mnemonics on menus. For example, under EDIT, the letter p is used ***THREE*** times, making it useless in a production environment. As long as the same image is open, doing ALT e p cycles through the the three occurrences of the p mnemonic. If it is the first time with the image, then it always goes to the first occurrence. Very obnoxious! In my system, ALT E followed by a letter seems to select an entry whose first character is that letter: Paste, Paste as, and Preferences. It is not selecting the first character. It is selecting the defined mnemonic which is represented by the underlined character. It may be that in your installation the underlining has been turned off under Edit, Preferences, Interface, Keyboard Shortcuts... This may not be the best way to choose an action, so I guess it's useless. But what are you trying to accomplish with ALT e p I agree that having more than one action defined with the same mnemonic is close to useless. In this instance, it is not so much what I am trying to accomplish as it is that I am inquiring if others feel that this is a bug. But, what I am trying to accomplish is a quick way to create a new file using the contents (including SIZE) of a selection in the paste buffer. As addressed below. 3) Misdirected mnemonics. (This one may be a lack of understanding of menu mnemonics on my part.) ALT e p [!!! may have to hit p multiple times to arrive at the correct desired location of PASTE AS] to get to PASTE AS. This exposes the fly-out/sub-menu. The sub-menu includes NEW IMAGE with a mnemonic of n. However, typing an n at this moment does not utilize the fly-out menu, it goes to UNITS on the main EDIT menu. What is the point of having a mnemonic on the flyout/sub-menu if you can't access them without using the arrow keys to get into the flyout/sub-menu by which time you are focused on the desired item anyway and can just hit return. When I execute select copy SHIFT+CTRL+p I get a new image with the selection that was on the clipboard. There seems to be no need to index through the various submenus to get there. The keyboard mnemonic is unique. I don't. What I get is the PATTERNS showing up in the window with the Layers, Channels, Brushes, etc., etc. I am glad that (CTRL+SHIFT+p) works for you, but the menu system specifically, in two places says it is CTRL+SHIFT+V. And that does NOT work for me. 4) Non-functioning keystrokes / keyboard shortcut listed on the menus. Specifically for me at the moment, CTRL SHIFT V is supposed to create a new file from the clipboard contents. This set of keystrokes is stated in TWO places: FILE, CREATE, FROM CLIPBOARD and EDIT, PASTE AS, NEW IMAGE Both should accomplish the same thing, but on my system, it does nothing at all. In my installation, SHIFT+CTRL+V creates a new image with the clipboard contents, as expected. Not sure how you are getting there from the discussion above. Perhaps you have misread some of what I have written above. Or perhaps there is something broken (as Owen suggests) about my installation. This is really annoying because tomorrow I have to have a staff member use this functionality 297 times. Argh! (Yes, I know that as long as we use keystrokes to get to the menu, we can walk though it using the arrow keys. It is just annoying.) Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
[Gimp-user] How do I avoid error message _windows_ when opening tif files created in Photoshop? (MaxSampleValue, MinSampleValue)
I am using Gimp 2.6.6 on Ubuntu 8.04 (Hardy) Linux. We have recently started using Gimp. We have to edit many (thousands) of TIF image files originally created with Photoshop 5.0.2 or 5.5.x on Windows. These files open just fine in Gimp, though Gimp does not seem to utilize the embedded preview image that Photoshop created (that would be helpful). However, _every_ time such a file is opened for the first time (until it has been modified in Gimp), we get an error message window with multiple error messages: == Window Title: GIMP Message TIFF image Message incorrect count for field MinSampleValue (1, expecting 3): tag ignored TIFF image Message incorrect count for field MaxSampleValue (1, expecting 3): tag ignored TIFF image Message incorrect count for field MinSampleValue (1, expecting 3): tag ignored Too many error messages! Messages are redirected to stderr. == Then, in stderr (the terminal window from which I started Gimp), I get one more that would not fit in the above message window: dcraw -i '/q/images/jsa/source/Topics/Slania/Monaco/Proofs/085_127791.tif' Cannot decode file /q/images/jsa/source/Topics/Slania/Monaco/Proofs/085_127791.tif TIFF image: incorrect count for field MaxSampleValue (1, expecting 3); tag ignored How can I tell Gimp to suppress reporting such errors and/or direct all such errors to stderr instead of Gimp opening up a GIMP Message window that has to be dismissed every darn time I open one of these old image files? Also, a minor irritant: The GIMP Message window is not shown in the various lists of windows in my desktop's task bar. My desktop is KDE 3.5.10. Thus if I don't dismiss each such window as they come up, they end up hanging around under other windows and one could easily end up with lots and lots of them present. And I can't get at them by using the task bar lists. Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] How do I avoid error message _windows_ when opening tif files created in Photoshop? (MaxSampleValue, MinSampleValue)
On 04/23/2009 10:04 AM, David Gowers wrote: Hi Jay, On Thu, Apr 23, 2009 at 11:27 PM, Jay Smith j...@jaysmith.com wrote: I am using Gimp 2.6.6 on Ubuntu 8.04 (Hardy) Linux. ... How can I tell Gimp to suppress reporting such errors and/or direct all such errors to stderr instead of Gimp opening up a GIMP Message window that has to be dismissed every darn time I open one of these old image files? Also, a minor irritant: The GIMP Message window is not shown in the various lists of windows in my desktop's task bar. My desktop is KDE 3.5.10. Thus if I don't dismiss each such window as they come up, they end up hanging around under other windows and one could easily end up with lots and lots of them present. And I can't get at them by using the task bar lists. Have you tried creating an 'Error Console' dockable? It normally catches such messages which would otherwise cause popups. David Thanks David, That did the trick. But... a) Now I have yet another window on my desktop whenever I run Gimp. Is there any way to hide it? b) Is there any way to simply tell gimp to ignore these particular error messages? c) Are these really proper error messages? What exactly is it complaining about and why? Are the files that Photoshop created defective in some way? Or have the standards changed? Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Annoying Windows Layering
On 04/10/2009 05:14 PM, Brian Weese wrote: I have the latest build of GIMP 2.6.6 ad running Windows XP. The Toolbox dialog and any dockable dialogs are ALWAYS in front of the file I am working on. I usually have the layers and brush dialogs open while I'm working on a file. I could increase the screen resolution but it makes the text so tiny... I have been able to work around it for now, but it is really annoying. Is this happening to anybody else? I'm not a programmer but this seems to be only something that can be fixed by adjusting the application code...maybe by the next release 2.6.7 hopefully? Unless of course this is only happening to me... Thanks, D. Brian Weese I am using Gimp 2.6.6 on Ubuntu 8.04 (Hardy) Linux. A lot of what we do starts with acquiring a scan using Xsane from inside Gimp (Create... Xsane...) [I guess many people would not have Xsane installed]. When the scanned image comes in, as the above poster says, it is behind, underneath, etc. I have to go fishing for it. It is mildly annoying the first hundred times. By the 20,000th time (a realistic figure for us) I think it will be _really_ annoying. Jay Smith ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] On Close, the Save / Don't Save dialog is not paying attention to keyboard
On 04/08/2009 12:36 AM, Owen wrote: Using Gimp 2.6.6 on Ubuntu 8.04 (Hardy) Linux. If I have a newly created untitled image and I Close it, I naturally, and correctly, get a dialog asking me if I wish to save it or not save it. In that dialog, pneumonic letters are underlined, meaning that I _should_ simply be able to type that letter and the action will be taken -- at least that is the way it would work on Windows (but I don't have Gimp on Windows). I _can_ access those pneumonics if I do an ALT first, as one would normally do when using pneumonics to get to menus. However, I think I should be able to simply type the single pneumonic/letter that is underlined. a) Is this behavior (that I can't just type the letter, I have to also hit the ALT key) correct for this type of dialog box? b) Is this the way Gimp acts in Windows? c) Is this problem an Ubuntu / KDE standard way of doing things (or a known problem)? OWEN REPLIED Here on Ubuntu-8.10, Alt+F then N brings up a new dialog, and randomly checking a number of others, it worked as expected On Windows there is a windows theme (name forgotten) that can upset all manner of keyboard actions, but AFAIK, a standard installation of windows should allow keyboard control Hi Owen, Thanks for your reply, but I think you may have missed the point of my question. To demonstrate: 1) Create a new image (by any means you wish). Edit the image in some way so it is different than the initial default empty created image. 2) Attempt to close the image. 3) On my system you will see a dialog box with the choices of: Save doN't save Cancel The capital letter I have used above is actually the underlined letter in the dialog. 4) On my system, I believe I should be able to simply type that capitalized letter to select and execute one of those three choices. However, on my system, that dialog box is not paying attention to my keyboard when I type just the letter (s, n, or c). Instead, I have to press the ALT key and then type (s, n, or c). In other programs on my system, such as Thunderbird Mail, the behavior I desire and expect does work. Again, I am using: Gimp 2.6.6 on Ubuntu 8.04 (Hardy) Linux. I think this is a bug, but I am seeking confirmation from others before I report it. Thanks, Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] On Close, the Save / Don't Save dialog is not paying attention to keyboard
On 04/08/2009 05:57 AM, David Gowers wrote: On Wed, Apr 8, 2009 at 1:32 PM, Jay Smith j...@jaysmith.com wrote: Using Gimp 2.6.6 on Ubuntu 8.04 (Hardy) Linux. If I have a newly created untitled image and I Close it, I naturally, and correctly, get a dialog asking me if I wish to save it or not save it. In that dialog, pneumonic letters are underlined, meaning that I _should_ simply be able to type that letter and the action will be taken -- at least that is the way it would work on Windows (but I don't have Gimp on Windows). I _can_ access those pneumonics if I do an ALT first, as one would normally do when using pneumonics to get to menus. However, I think I should be able to simply type the single pneumonic/letter that is underlined. I have to say that I don't recall ever encountering such a behaviour on Windows. I've always had to use ALT both on Windows and Linux, that I recall. a) Is this behavior (that I can't just type the letter, I have to also hit the ALT key) correct for this type of dialog box? See below. Also, I think a decision was made against this kind of behaviour as it can make it quite easy to accidentally choose one of these options (if eg. you think you're typing in IRC but actually your gimp 'Close images' dialog is focused). I remember tripping over this in old DOS programs. b) Is this the way Gimp acts in Windows? Yes, as far as I know. c) Is this problem an Ubuntu / KDE standard way of doing things (or a known problem)? GTK+ standard way of doing things, AFAIK. David Thanks David, But... I am not sure we are speaking of the same behavior / application. I _am_ speaking of the pneumonics in dialogs that open as the result of some action. I am _not_ speaking of accessing the main menus of programs (for which you _do_ need to use the ALT key). Every Windows program I have ever used, from Win311 to Win95* to Win98* to WinME* to W2Kpro* to WinXPpro* [The * o/s are currently installed and available to me in virtualized form for testing and verification] did as I expect they DO accept the use of single letter pneumonics in those types of dialogs. The same has been true for RedHat Linux and SCO Unixware that I have used. I have only a few months of using Ubuntu 8.04 (Hardy) Linux / KDE , it also seems to be true there and in the program I am using right now, Thunderbird Mail, it is true. This is on the very same system on which I am using Gimp. (If I try to close the message I am currently writing without first saving it, it will present a dialog and allow me to use single character pnuemonics without having to use the ALT key -- except that of the three choices, only two of them have pneumonics; a bug I need to report.) What does your Gimp do and what are you running it on? 1) Create a new image (by any means you wish). Edit the image in some way so it is different than the initial default empty created image. 2) Attempt to close the image. 3) On my system you will see a dialog box with the choices of: Save doN't save Cancel The capital letter I have used above is actually the underlined letter in the dialog. 4) On my system, I believe I should be able to simply type that capitalized letter to select and execute one of those three choices. Thanks, Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Snap to Guides by default
On 04/08/2009 10:04 AM, malefico wrote: David Gowers wrote: On Wed, Apr 8, 2009 at 9:52 PM, malefico malef...@malefico3d.org wrote: Hi, two rather noob questions here: I wonder if there is any way to turn off the Snap to Guides option which is on by default (Gimp 2.4), I look in configuration windows but couldn't find how to turn it off. is View-Snap to guides what you want? (in the menus on the image windows, not in GIMP preferences) David Thank you David, I know where the option is, but it is always on by default. Is there any way to turn it off by default ? So when Gimp starts it is unchecked ? Regards malefico. I posted a similar question a few days ago and got no from the group/list. My question was about the various defaults in the dialog Image, Canvas Size. Is there a way to control _all_ these various defaults? I can't find an 'rc' file or anything in Preferences that does this. Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] pixels to dpi
Norman, I hope I have not misconstrued your question / wording. You used the word scan in conjunction with your camera. Your camera is not a scanner. It has a very different dpi/ppi than a scanner. Scanners use A x B dots/pixels maximum per square inch. However, what you get from your scanner (up to that maximum) is what you tell it to give you, for example 600 x 600 dots/pixels per square inch. On scanners, most humans have little use for their so-called maximum resolution. However, one practical application for using higher resolution settings is if you want to scan a small object, such as a postage stamp, and blow it up to a wall-sized poster. Scanners scan at 100% of actual object size, so a 1x1-inch object at 600 x 600 is going to show up in your image software as 600 x 600 pixels/dots. The resolution of your computer monitor and the zoom/magnification (for viewing purposes only) setting in your image program will affect how large it appears on your computer screen. However, if you PRINT that image on a 600 dpi/lpi/ppi PRINTER, then it will come out 1x1-inch on the paper (unless you make it larger, i.e. more pixels/dots, in your image program). (I find it nearly impossible to explain to folks the difference between viewing and printing in regard to resolution. It takes a while to get it.) So, to scan that postage stamp that you want to turn into a wall poster, you might scan it at a very high 2400 x 2400 resolution. Then, in your image program, change the size from 1x1-inch up to 20x20 inches AT THE VERY SAME TIME AS YOU _reduce_ the resolution to 300x300 dots/pixels per inch. My understanding is that you have to do it at the same time for best results. You thus are SPREADING the 2400 x 2400 pixels over an area of 6000 x 6000 pixels (20 x 300). The result won't be crisp and clear when printed, but then it is a wall poster meant to be viewed from some distance. Good luck finding a printer that can print it (a 36,000,000 pixel/dot, 20x20 inch image). ;-) Cameras use a different C x D maximum dots/pixels per square inch than scanners. You might have to find the info buried in the manual. Scanners and cameras are two completely different animals in several ways. But more to the point, it is my understanding that they use a maximum total image/data size for the picture. However, again, what you actually get is what you tell it to give you, up to that maximum. You probably got 729 x 729 (i.e. 531,441 dots/pixels or half megabyte) because you told it to use a particular size/quality. I don't have a lot of experience with cameras seem to use words to describe the image size or quality, or speed, such as good, better, best. If good is 729 x 729 and you use the setting of good, then whatever is in the picture is 729 x 729. If that is not enough detail, then the picture must be taken zoomed in so that whatever it is you want in the picture is taking up more of the image area. I suggest if you have further questions about this, you find a mailing list or forum about cameras, scanners, and computer graphics, etc. The Gimp list is meant to be most about GIMP. BTW, You got a LOT more action on this than I get when I ask a GIMP question. Nobody seems to want to answer my GIMP questions. :-( Jay On 04/07/2009 10:48 AM, Michaela Baulderstone wrote: I'm 36 with a post grad degree I can't figure out how to get an image to specific size Cheers M -Original Message- From: gimp-user-boun...@lists.xcf.berkeley.edu [mailto:gimp-user-boun...@lists.xcf.berkeley.edu] On Behalf Of norman Sent: Wednesday, 8 April 2009 12:08 AM To: gimp-user@lists.XCF.Berkeley.EDU Subject: Re: [Gimp-user] pixels to dpi snip As for your original question. if you have 4800x9600 ppi, and you scan an inch square of material, you will end up with 4800x9600 pixels. Thus the question if you are having a laugh, as your question seemed trivial. I am really sorry you see my questions as trivial, they are not meant to be. Much of my difficulty is one of understanding the terminology used. For example and, assuming I understand correctly, if I scan a photograph which is, say, 5 inches square and then display that scan on my monitor, it will measure 24,000 pixels X 48,000 pixels. To test this on my rather cheap Canon LIDE20 I scanned a picture which is 5 inches square saved the file, opened the file in GIMP, cropped so that only the picture was there and GIMP said it was 729 pixels X 729 pixels. Please explain and, just in case you think I am some youngster trying to get his homework done, I was 81 years old last birthday. Norman ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
[Gimp-user] On Close, the Save / Don't Save dialog is not paying attention to keyboard
Using Gimp 2.6.6 on Ubuntu 8.04 (Hardy) Linux. If I have a newly created untitled image and I Close it, I naturally, and correctly, get a dialog asking me if I wish to save it or not save it. In that dialog, pneumonic letters are underlined, meaning that I _should_ simply be able to type that letter and the action will be taken -- at least that is the way it would work on Windows (but I don't have Gimp on Windows). I _can_ access those pneumonics if I do an ALT first, as one would normally do when using pneumonics to get to menus. However, I think I should be able to simply type the single pneumonic/letter that is underlined. a) Is this behavior (that I can't just type the letter, I have to also hit the ALT key) correct for this type of dialog box? b) Is this the way Gimp acts in Windows? c) Is this problem an Ubuntu / KDE standard way of doing things (or a known problem)? Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] How to rotate part of an image without getting white triangles at the corners ?
David, Thanks for the bug number. Regarding the float method, I beg to differ. Unless I am missing something, what we are doing for Floating before rotating is ... get selection tool (must be done anyway) draw selection (must be done anyway) Ctrl-Shift-L(the only additional work) get rotation tool (must be done anyway) do rotation (must be done anyway) get selection tool (must be done anyway) click to anchor floating selection (must be done anyway) Just one simple step per rotation. Ctrl-Shift-L. No adding alpha channel No adding layer No moving layer to bottom No flattening layers You asked about quantity: 50,000 scans, each scan of which contain from one to 20 stamp images, some of which will end up as single-stamp images and others of which will end up as multi-stamp images. So 50,000 of the add-layer method. Probably up to 150,000 (?? maybe more) rotations, but still I think the ctrl-shift-l is a lot faster. Thanks very much for your help! Jay On 04/01/2009 09:03 PM, David Gowers wrote: Hi Jay, On Thu, Apr 2, 2009 at 12:58 AM, Jay Smith j...@jaysmith.com wrote: Hi David, If convenient, please advise me of the bug number on this so that I can track it. Thank you very much. http://bugzilla.gnome.org/show_bug.cgi?id=577575 Related to the bug, I hope you also noted the problem that there is no Preferences option of using black as the default for newly created images. You said... BTW, floating before rotating is NOT how I would do this. Please share your reasons why you would not do that. Because it's far far far far far far slower and more laborious than the method I went on to describe. There is no comparison. (All the other mucking around [alpha channel, add layer, etc.] may seem simple to Gimpers, but please do it 10,000 times and then tell me how you feel about it -- We have so far scanned edited over 50,000 such images in Photoshop and have more than double that number yet to go.) 50,000 images? or 50,000 stamps? The procedure I described would only need to be done once for each image, not for each stamp-rotation. It is far more streamlined, if you typically rotate several stamps out of every single image that you open. David ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Gimp Printouts
Walter, There are multiple issues involved. For example: - Since you did not mention anything about calibration, consider that the scanner, the monitor, and the printer are three different devices, each of which has to be properly calibrated (starting at the beginning with the scanner, then the monitor, and then the printer) using known source colors. This is the bane of color work. The subject is enormous and has very little to do with Gimp itself. The process of calibration can result in the creation of ICC color profiles which each piece of hardware uses (or I should say the programs on your computer uses when talking to each piece of hardware) to adjust for the color variations of the respective hardware. - The printer, even when properly calibrated, is subject to all sorts of variations including temperature and humidity -- to say nothing of the paper -- at any given moment. We had a big color printer that we had to calibrate every few hours of operation. - What you get from the scanner will vary over the life of the scanner. As it gets older, you will see changes in the color that it puts out. Thus it needs to be recalibrated from time to time. - What you see -- or think you see -- on the monitor, even when properly calibrated, will vary greatly just be changing the lighting in the room where you use the monitor. - The RGB to CMYK conversion depends greatly on many issues, including where the conversion occurs (in image and/or color management software on your computer, in the printer driver software, or in software resident on the printer itself. The subject is huge and always gives me an enormous headache. I suggest Googling on color calibration and such subjects for more useful information that you can apply to your environment. Keep in mind that what you have been seeing/editing/tweaking on your monitor may actually not be reality. I have five identical monitor (same brand and model), all configured the same way, but without any specific calibration to a color target. All five of them show the same image a little differently -- but one of them is massively different (whites come out very yellowish); that one needs to be repaired. Good luck. Jay On 04/02/2009 12:40 PM, Walter S. wrote: Hi there. Thanks for allowing me to join this forum. I have been using Gimp for some time, but now that I have got as far as printing out some of my work I have come across a snag. I could not understand why the print was so much darker than the image on the monitor. Having scanned the help files in Gimp, I find the information, that this is because the monitor is showing the image in RGB,but the actual printout is in CMYK. I am wrestling with the logic of this and failing to comprehend why it should be. I am hoping that there is a way of resolving this tremendous mis-match. Is there any Gimp knowledgeable member out there who could fill me in on the way to overcome this difference? I sure hope so. Many thanks. cypher000 ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
[Gimp-user] How to cause Image... Canvas Size... Layers... to _always_ be All Layers instead of None ?
Using Gimp 2.6.6 on Ubuntu 8.04 (Hardy) Linux. For the vast majority of my work, every time I enlarge the canvas (which I have to do a _lot_ ), I want _all_ the Layers to enlarge as well. However, the dialog box Image... Canvas Size... Layers... _always_ seems to default to None instead of All Layers. While I have a difficult time understanding why None is a better default setting than All Layers, I suppose that there are some very good reasons that are beyond my grasp. However, certainly there must be a way to change this default for a particular Gimp installation or at the very least, for a particular user session of running Gimp. Am I missing something? Does this require a plug-in? Is there one that will do it? Is there a plug-in that will allow the user control over _all_ the defaults? (The model that comes to mind is the firefox/thunderbird about:config setting methods.) Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] How to rotate part of an image without getting white triangles at the corners ?
Hi David, If convenient, please advise me of the bug number on this so that I can track it. Thank you very much. Related to the bug, I hope you also noted the problem that there is no Preferences option of using black as the default for newly created images. You said... BTW, floating before rotating is NOT how I would do this. Please share your reasons why you would not do that. It seems perfectly logical now that I know it is possible, and it seems to be _exactly_ the method/result I wanted without all the other mucking around. (All the other mucking around [alpha channel, add layer, etc.] may seem simple to Gimpers, but please do it 10,000 times and then tell me how you feel about it -- We have so far scanned edited over 50,000 such images in Photoshop and have more than double that number yet to go.) I _really_ appreciate your mention of Select...Float -- that is exactly the needed answer IMHO. Jay On 04/01/2009 12:07 AM, David Gowers wrote: Hi Jay, snip I can confirm this -- except that I always get black, rather than always getting white. I've just filed a bug report for it. In the meantime, you should be able to work around this by floating the area (select-Float) before rotating. No complex procedures are required, nor any particular redundancy. This should be pretty easy to fix -- pretty high chances of seeing it in the next 2.6.x release. BTW, floating before rotating is NOT how I would do this. Instead, I would snip Hope this helps! David ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] How to cause Image... Canvas Size... Layers... to _always_ be All Layers instead of None ?
I have just discovered an additional -- but exactly the same basic subject -- problem with this dialog box: The 'link' symbol at the top, between the two pixel sizes, reverts every single time to linked status. It seems that it has to be unlinked every time if you wish to change only one of the dimensions of the canvas. Again, is there a way to get Gimp to remember this setting (either permanently or per-session)? I would have assumed that there is an rc file(s) somewhere that contains every conceivable dialog box setting/value. Jay On 04/01/2009 12:27 PM, Jay Smith wrote: Using Gimp 2.6.6 on Ubuntu 8.04 (Hardy) Linux. For the vast majority of my work, every time I enlarge the canvas (which I have to do a _lot_ ), I want _all_ the Layers to enlarge as well. However, the dialog box Image... Canvas Size... Layers... _always_ seems to default to None instead of All Layers. While I have a difficult time understanding why None is a better default setting than All Layers, I suppose that there are some very good reasons that are beyond my grasp. However, certainly there must be a way to change this default for a particular Gimp installation or at the very least, for a particular user session of running Gimp. Am I missing something? Does this require a plug-in? Is there one that will do it? Is there a plug-in that will allow the user control over _all_ the defaults? (The model that comes to mind is the firefox/thunderbird about:config setting methods.) Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
[Gimp-user] File Creation Permission Problem ONLY for TIF files: Creating as 644 (rw-r--r--) when should be 664 (rw-rw-r--)
Using Gimp 2.6.6 on Ubuntu 8.04 (Hardy) Linux. TIFF ONLY This problem seems *only* to be happening when creating/saving TIFF (.tif) files. If the filetype is something else, then the problem is not happening. On two different workstations, being run by two different login users, creating files in various different directories, Gimp is creating the files with permissions that are incorrectly too restrictive: Gimp is making as 644: -rw-r--r-- 1 jay jsa 1919194 2009-03-31 12:10 tmp.tif When it should be making as 664: -rw-rw-r-- 1 jay jsa 1919194 2009-03-31 12:10 tmp.tif ONLY Gimp is doing this. Creating files in the exact same manner and saving them to test.png or test.jpg results in _correct_ permissions. It only is a problem with .tif files (so far in my testing). a) The directories that the files are being created in have perms of 6775: drwsrwsr-x 3 jay jsa 4096 2007-05-28 15:57 testdir Files created in a directory with those perms are _supposed_ to be created as 664 which is rw-rw-r--. b) When any other program, such as vi or touch, makes a file in the very same directory, it is making the perms correctly. c) I have double checked the user's umask which is correctly 0002 which would result in file creation as 664. d) We have never had this problem with any other program (when the directory perms are correct, which they are in this case). e) An associate on a completely different, but virtually identically configured Ubuntu linux system (all same versions). has been able to replicate the exact same problem. ??? 1) Is this a (known?) bug? 2) Is this configurable somewhere in Gimp? I can't find it if it is. 3) Is this configurable somehow in the .gimp* rc files and/or from the command line? Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
[Gimp-user] How to rotate part of an image without getting white triangles at the corners ?
Using Gimp 2.6.6 on Ubuntu 8.04 (Hardy) Linux. We are testing using Gimp to replace Photoshop on Windoze. However, we are hitting one problem/feature we have not been able to resolve. We scan images of postage stamps (using xsane from inside gimp). There are multiple postage stamps are on a black background. Some of them are a little crooked and need to be rotated. We CAN rotate them as desired, but are ending up with unwanted white triangles at the corners. We have set the background color to black (and tried changing foreground too). Then reselecting and rotating. No difference. In the preferences on file creation, for background, there are setting choices for white, transparent, foreground color, or background color -- but NOT black (unlike Photoshop). Not sure if this is the problem. When the image is created, coming in from xsane, there is only one layer. Method: - Scanned using xsane from inside gimp: multiple postage stamps on a black background. - Set background color to black. - Draw selection around ONE stamp and use rotate tool by dragging the grid around. Direction = corrective; grid on -- works as desired (but gets white triangles) Transform (in the rotate tool palette) - tried Layer (works but gets white triangles) - tried Selection (just rotates the selection box and not any part of the picture -- that is very odd!!! -- does this not work or do I not understand what it is supposed to do??) Clipping -- is set to Adjust, but also tried the other settings all of which still end up with white areas. I understand that I could draw selections around the various unwanted white parts and fill with black, but that is a big pain -- we scan thousands of such images and would thus have to do 4x thousands of fills. Is Gimp unable to auto-fill those background areas? Or do I not have something setup correctly? Is the problem related to the way in which we acquire the image in the first place? What am I missing This is automatic in Photoshop (as long as the background is set to black), so I assume that Gimp would do it even better. Jay ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] How to rotate part of an image without getting white triangles at the corners ?
Andrew, Thanks for your suggestion, but... I must not be understanding something critically important. I _think_ I did as you described, but after rotation the object I just rotated seems to disappear under the transparent (checkerboard) alpha channel, never to be seen again. If I have the black layer underneath, then the rotated object is covered by black. I have looked at the Help, etc., but it is becoming increasingly obvious that one can't just drive this program. It seems you have to be a master mechanic just to do relatively simple tasks. Maybe my brain has been poisoned by the Photoshop way of doing things, but even (what should be) simple things like making the canvas larger (necessary to do if rotating objects that are in a very tight image/canvas) and trying to fill the new area with background color seem to be incomprehensible to me in Gimp -- in Photoshop, you just made the canvas bigger and it was automatically filled by the background color. Are there any good websites that approach this program from a here is how to actually do stuff perspective? I have not found one yet. I am trying not to be frustrated, but what is s simple in my 10-year-old Photoshop is agony (so far) in Gimp. I must really be missing something very, very important! Jay On 03/31/2009 04:50 PM, Andrew wrote: There's probably a better solution to this, but if you add an alpha channel to the image before rotating the selection, then instead of white triangles you'll get transparent sections and you can add a black layer below to fill them in. A ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] How to rotate part of an image without getting white triangles at the corners ?
Partial Oops... I had most recently responded to Andrew ... I _think_ I did as you described, but after rotation the object I just rotated seems to disappear under the transparent (checkerboard) alpha channel, never to be seen again. If I have the black layer underneath, then the rotated object is covered by black. Well... I tried again with a completely newly created image. And it _did_ work as you described. So I went back to the image I had been messing with and noticed that the one and only layer was labeled by Gimp as New Layer instead of Background. It seems that once you mess with layers and flatten the image, the now-one-and-only-layer is called New Layer instead of Background. And, IF it is called, by Gimp, New Layer, the procedure you (Andrew) described does not work (the rotated item turns black). However, if I flatten, save, and close the file (as .tif -- we are always working with .tif files), and then re-open it, the one-and-only-layer is again called Background and the method Andrew described will work. Thus if one had to do 10 such rotations in a single image (a very typical situation for us), it seems we would have to flatten, save, close, and re-open the file 10 times. That does not seem right. What am I missing? Jay P.S. When I do add the new layer as Andrew describes, it is on top of the original (background) layer and the background layer needs to be moved on top of the new layer so that it can be seen and worked on. My arm is aching from all the mousing around. ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
