[Gimp-user] superimpose no-smoking sign
Hello, I've only used gimp a little bit but need to teach an autistic child to not run into the street and do other things. To do that, I need to take pictures and then super-impose a basic no sign (like you see for no-smoking) over it. I need to do this for a lot of pictures. Any suggestions for how to do that. I am going through the gimp help browser now but have basically no idea. I _really_ appreciate it. -- Shawn <[EMAIL PROTECTED]> ___ Gimp-user mailing list Gimp-user@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Save For Web Option?
On Wednesday 05 April 2006 01:03, Mark Sargent wrote: > am a rather experienced Linux user for the past 2yrs or so, but, not > much with Gimp. I used to use Fireworks/Photoshop on Windows some time > back, and am wondering where within Gimp I can just save as for web, and > it allows me to resize etc. I can't seem to find that option anywhere in > the menus. All I see is, save, save as, save a copy, save as template. I > have a 14.5mb file that I need to get to under 500kb or less. Could > someone point this non-gui fool in the right direction? Cheers. Well, if you're a non-gui fool, I'd suggest a non-gui tool. I'd use imagemagick, something like: convert infile.bmp -resize 500x500 -quality 75 outfile.jpg ImageMagick uses the file extension on the output to decide what type of image compression to use, so it will save as a JPEG. The -resize option by default will not stretch your image so the above will resize your image to be at most 500 pixels on each side. Finally the -quality is used by the JPEG compressor and takes a number between 0 and 100. Smaller numbers give you worse images, but 75 is a good tradeoff which gives you good image quality and good compression. You can easily play with the numbers to get larger or smaller image sizes. If you do want to use the GIMP (certainly not a bad choice), you should use Image->Scale Image to shrink the resolution down, then Save As and enter a file name with a .jpg extension. The GIMP will then prompt you for a quality level and if you click the "Show Preview in image window" you can see the effects of dragging it back and forth, and you can also see the file size right undernath the quality slider. Have fun, Shawn. ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
[Gimp-user] Suggestions for RAW workflows
Hi, This isn't strictly a GIMP question (although the GIMP may well be a component of the solution), but it seems likely that some of the people here will have some good ideas. I'm experimenting with various approaches to turning my RAW images into high-quality TIFF or JPEG files for printing and/or on-screen viewing, and I'm looking for suggestions from others who are doing the same thing on Linux. So far, I've found that using GIMP and the ufraw plugin, I can get conversions that are fairly nice in most respects. Manipulating the exposure and the curves in the ufraw dialog even allows me to take advantage of the greater contrast that the RAW format captures, compressing or stretching the dynamic range prior to converting to 8-bit color depths so that highlights aren't blown out and details aren't lost. There are a couple of problems, though. First, the ufraw plugin, and the dcraw program, seem to fall down in one respect: my converted images are often much noisier than the JPEGs produced by the in-camera processing. I shoot in RAW+JPEG so I have both, and in some cases I've been able to get a better final image out of the JPEG than the RAW, simply because of the noise issue. I have found that the GIMP 'selective gaussian blur' can be used to get rid of much of the noise, but it has to be used very carefully to avoid losing too much detail or distorting portions of the image. I'd like to find a less 'fiddly' solutuion. The second problem is that I'd like to print some of my images in relatively large sizes (11x14 or so), and it seems to me that if I want the best quality possible, it's not a good idea to convert to 8-bit color. Of course, that rules out using the GIMP to clean up noisy areas, since it doesn't yet support higher bit depths. Cinepaint doesn't have the selective gaussian blur filter, nor does ImageMagick. So, are there any other RAW photographers who use Linux or *BSD and want to share their photo processing workflow? Thanks, Shawn. ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] How to get "step" gradient
On Wednesday 03 January 2007 14:24, Tonio wrote: > Is it possible to make the gradient colors go in > steps, i.e. so it won't be smooth, but kind of bands > of colors, (from start color to end color with jumps > in between). Posterise might do it for you. Create a regular, smooth gradient and then use Layer->Colors->Posterise. Turn on preview and drag the levels slider around to get the number of steps and widths of bands you want. Shawn. ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] GIMP's equivalent of adjustment Layer in PS?
On Monday 08 January 2007 23:10, Steven Woody wrote: > in Photoshop, there is a tool 'adjustment layer', what's the > equivalent in Gimp? thanks. GIMP doesn't have any equivalent. I believe it's in the plan for future releases. I know the new graphics engine will make adjustment layers very simple to implement, so I wouldn't expect to see them implemented before the new engine goes in, and I would expect them to be implemented very soon after. For now, you just have to make the adjustments directly on your image layer. I usually copy the image layer before applying an adjustment to it, in case I decide to remove the adjustment. Shawn ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] GIMP's equivalent of adjustment Layer in PS?
On Thursday 11 January 2007 13:46, Steve Thompson wrote: > I guess that about says it all, right? We listen to our users, but > adjustment layers is a pointless discussion. You're not listening. It's pointless because adjustment layer support is already in the roadmap. Need heard. Need understood. Approach to resolving need defined. Work toward that end in progress. What more do you want? You want Sven and company to drop everything else they're doing in order to implement adjustment layers RIGHT NOW, integrating this new feature into an architecture that will be immediately abandoned and replaced as soon as 2.4 is out the door? Doing what you seem to want will: 1. Delay 2.4 2. Delay the next, GEGL-based version which will... 3. Delay > 8bpc support 4. Delay CMYK support 5. Delay a whole raft of other desireable features All so that you can have adjustment layers just a bit sooner -- maybe. Depending on the complexity of implementing adjustment layers in the current engine, it's entirely possible that you'll get your feature *LATER* than if you wait for the GEGL-based version!!! Sheesh. Even as a corporate developer, I'd get pissed off at a manager who tried to push that kind of stupid decision on me. Why would anyone be surprised that VOLUNTEER developers would get annoyed at similar pressure from people that have no authority over them, and are unwilling to help out? Shawn. ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
[Gimp-user] Re: Getting Rid of the Gray
I would just do the same as with a color image, that is, Filters-->Colors-->Color to Alpha. Of course first you would need to convert the image to rbg. You can put white to alpha and any shade of gray, or use the color picker to select an exact value. Select by Color also works with grays, afaik. Carol's pointer was worth a look. Shawn Lindsay. ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] Re: Gimp-user digest, Vol 1 #473 - 4 msgs
> Message: 2 > Subject: Re: [Gimp-user] rounded rectangle > From: Daniel Haus <[EMAIL PROTECTED]> > To: Gimp Users Mailinglist <[EMAIL PROTECTED]> > Date: 16 Oct 2002 23:38:46 +0200 > > > i guessed that, unfortunately almost none of the script-fus work with > gimp-1.3 in my localized (german) gnome2-environment, because of some > confusion about floating point numbers (in german it's "1,0" instead of > "1.0" so i about always get error-messages). i've seen this bug is > already reported. can this easily - until it's officially fixed - be > corrected by a few hacks, or will this require some more work and > knowledge about gimp's internals? did anyone make it work? > > > the tutorial at http://gug.sunsite.dk did it for me. it's not exactly > how i'd like it, a better solution might be a "roundness" option in the > rectangular-selection-property-tab, but at least, it works. > Can you choose select-->grow from the menu? If so, you can make a small rectangular selection on a huge background and grow it by a large number like 256 pixels. The result will be a rectangular selection with rounded edges. Shawn Lindsay. ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] Re: rounded edges
Forgive me, list. I forgot to change the subject line in that last post re Daniel's problems with rounded edges. To get rounded edges without script-fu: 1. make a small selection on a huge background 2. select-->grow; choose a huge number like 256 pixels 3. Voila. Well, depending on your processor, it may take a few seconds. Shawn. ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] Re: Colorizing
Mark, Have you looked at the color mapping filters? Filters-->Colors-->Map-->Color Range Mapping, or the Gradient Map. These might help you get the effect you're envisioning. Shawn. > Reply-To: [EMAIL PROTECTED] > Message: 1 > > Thanks Andrew. I gave this a shot but it does not seem to work ... I > think maybe because the foreground and background colours are not > distinct enough. I think I will look at using bezier curves ... got > some reading to do! > ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] hardware
What's a good processor for gimp? I'm pricing a new computer. I kind of have my eye on Intel's 3.06 P4 but am waiting for prices to drop. What are some advantages of other processors? Mostly what I want is quicker processing of some plugins, and being able to run other programs at the same time. Almost anything will be better than my Celery, but I want something really good and not outrageously expensive. What should I look for? Thanks. Shawn. ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] hardware
Thanks for the feedback. I'll definitely take another look at dual Athlons. I still have some questions, though. Is Intel's 533 MHz fsb a real advantage? Or only with certain kinds of RAM? Some benchmarks show the Athlon is a real fast cruncher, so for most things it probably gives you the most bang for the buck. Btw did anybody see the review of AMD's Barton chip at Ace's? ( http://www.aceshardware.com/read.jsp?id=5364 --yea! Pricewar!) . They used a Photoshop benchmark and the P4 3.06 GHz was best at most but not all filters. Ace's said that Photoshop had been optimized for SMP and hyperthreading. Would that be true of Gimp? I'd think stuff like Gaussian blur would be the same or similar. Dang I wish they'd use Gimp for some benchmarks. Loading up on RAM I know is good, but which kind? RDRAM, DDRAM, DRDRAM, SDRAM, DDR SDRAM--ECC or not?--ack!--just give me speed, reliablity and let me keep my shirt. Even with a couple gigs of RAM I'm going to be swapping. Is an SCSI drive worth the extra price? I'm thinking no because I can get a 7200rpm ide for $40, or a 10K RPM IDE drive at a fair price, but if somebody has good things to say about their 15K SCSI I'd like to hear it. Do better latency and seek time make much of a difference? Are the 15Krpm Cheetah's and Fujitsu's really as quiet as the reviewers say? What's the optimal balance between transfer rate and access time for working on large .xcfs? Finally, would a smaller main drive (with / /usr /home /tmp and swap) be faster? I was thinking it would be most efficient to have a small fast drive with a second, larger drive for storage. Am I wrong to suppose a large main drive would slow me down? Does putting the swap on the first sector still matter, or have advances in hard disk technology made this inconsequenstial? Thanks again. Peace, Shawn. ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] Auto-level script-fu
How can I invoke auto leveling (Image/Colors/Levels/Auto) from a script? Is this possible? Thanks, Shawn. ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] RGB to BGR script works, but how to run auto levels?
On Sat August 30 2003 12:06 pm, Walter Francis wrote: > I also run auto levels on the images when I'm done, but so far it looks > like this is not possible from Script-fu. Any updates on there? I submitted a bug report (http://bugzilla.gnome.org/show_bug.cgi?id=119233) and a patch to add a PDB entry for auto levels. If you don't mind applying the patch and building the GIMP yourself, you should be able to get auto levels to work from your script. The patch is at: http://bugzilla.gnome.org/showattachment.cgi?attach_id=19053 Apply the patch to tools/pdbgen/pdb/color.pdb, then do the typical configure, make, make install process, taking care to add the "--with-pdbgen" option to the configure command line so the PDB code will be updated. If you're not comfortable with patching and building, you'll probably have to wait until the patch gets applied by the developers. If you use Debian, drop me a line and I'll send you patched versions of the Sid .deb files. Shawn. ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] Channel Mixer for 1.3?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Has anyone ported the plugin? Or is there similar functionality elsewhere? Thanks, Shawn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/vZQKp1Ep1JptinARAklaAJ9X8QT5OrtylczJMDFIubKfU+m+MACeIp0t KeZKkbEeTizUW2GbqOJwRok= =+IXX -END PGP SIGNATURE- ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] How to treat several pictures at once?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 04 February 2004 12:05 pm, Dirk Völlger wrote: > Hi there, > > I am a new gimp user as well as a new list member. I have got the > following question: I took a series of pictures (measures) and I have > to normalize and equalize them to see any result. Is there any perl > skript or smth. else that does this step with all the pictures I have > because it is impossible to treat ~ 50 pictures seperately (no time ...) > I have never used perl, so I also do not know how to use it with gimp. > > Any help, tutorial or hint would be cool because it is quite urgent. Assuming it can do the job (and it can do a lot of jobs), your best option is probably not the GIMP, but rather ImageMagick, which provides set of command line tools for doing all sorts of image operations. You mentioned normalizing and equalizing. To do that with ImageMagick, you would just run, e.g.: mogrify -normalize -equalize *.JPG Done! If you find that ImageMagick won't do it, then you should look into scripting the GIMP. I recommend writing your scripts in Python, but it really depends on what you're most comfortable with -- or most interested in learning. Shawn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAIc3ap1Ep1JptinARAmzaAJ9943rllPjruAJYqdAp+rOMEkbbVACfWPTz iwM+0yHuXJHILRbvMq74nMQ= =mw9v -END PGP SIGNATURE-
Re: [Gimp-user] Re: frontend to help classify images
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Saturday 08 May 2004 12:43 pm, Helge Hielscher wrote: > On Sat, 08 May 2004 14:02:32 -0400, h121 wrote: > > Short: > > I'm looking for a front-end tool to help me process > > (qualify and classify / catalog) about 10,000 scanned images. > > You may want to have a look at KimDaBa. > http://ktown.kde.org/kimdaba > http://kde-apps.org/content/show.php?content=10065 I second the recommendation. A little more information: KimDaBa uses an XML file to store all of the image metadata. While this solution isn't ideal for huge image databases, because it has to load the entire metadata database into RAM to get reasonable performance, it will be just fine with only 10,000 images (I have about 7,000 images in mine). Once all of the metadata is in XML format, you can write a little code to put it in any other format you like. KimDaBa supports arbitrary classification schemes. Basically, you define a set of categories (you called them dimensions), and the values for each category. The image classification window is customizable, so you can arrange the defined categories for convenience. Though it may not be applicable for your application, you can also define groups within a category. Groups contain values or other groups. After images are categorized, you can drill down pretty much any way you like. Selecting one criterion, then another, then another, until you've identified the set of images you want, or at least narrowed it down far enough to make a manual search reasonable. KimDaBa will also allow you to "mark up" images, rotating them, drawing on them, etc., but all of the modifications are stored as metadata, without modifying the actual image file. When you display the photo with KimDaBa, the markup is visible, the image is rotated, etc. KimDaBa reads date/time and rotation data from EXIF, if available. One thing KimDaBa does not do (AFAIK) well is provide convenient ways to zoom in. Also, it's a bit slow to display each image. I think this is because it just uses the KDE image code to decompress and display images, and it isn't terribly fast. In a KDE photo manipulation tool I wrote, I had to resort to trading off some RAM to cache the last few and the next few images. I think JPEG decoding time was the biggest part of the problem, but frankly didn't look into it that much after I found an acceptable solution. Also, it sound like you might need something more flexible than KimDaBa's HTML generation for the final image database. One other plus, the primary author, Jasper Pedersen, is generally quite responsive, so if you can make a case that some need of yours is likely to be shared by others, he's likely to add your requested feature, and quickly. The code is reasonably clean also, so if you're a C++ programmer you can always look into adding whatever bits you need yourself. Shawn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAnUUIp1Ep1JptinARAhjxAJ9YBgjNoDPAd8QDkrYpLlkASqLQ0QCfR02P Py5ESlyHoy8ORMdB+0y5xP8= =YwRn -END PGP SIGNATURE- ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] Poor print quality with GIMP on Linux
I have an HP Photosmart 7260 printer which prints great photos when I print from other Linux applications, particularly KDE apps with kprinter. To get good photos I do have to explicitly set the printing mode in the driver settings, but it works well. It works well in every application *except* the GIMP, that is. The GIMP appears to do some rescaling and adjustment that makes the output look noticeably blurry. I've configured the GIMP to print through kprinter (with command "kprinter -dPhoto --stdin") so that the kprinter dialog pops up and allows me to set the print mode. What's really annoying about the GIMP not printing nicely is that it makes printing photos a multi-step process. The image viewers I've tried print okay, but they assume 72dpi, rather than whatever I really want (usually 300dpi, but sometimes more or less, depending). So, my current process is to load the image in the GIMP, use "scale image" to adjust the dpi setting (usually without actually scaling the image) and then save the image as a postscript file. Then I can load the .ps file up in kghostview or whatever and it prints very nicely. Any ideas what I can do to fix this? I have the GIMP's Image/Output Settings set to all the defaults (Image Type: Photograph, Output: Type Color, all the parameters on the Adjust Output dialog to "1.000"). I'm careful to ensure that I don't have to do any scaling from the print dialog, either... "Scaling" is set to 100.0%. What else... the printing system is CUPS v1.1.21rc1, the driver for the printer is Foomatic v3.0.2 + hpijs v1.6.2 (configured through the KDE printing manager) the system is Debian unstable, with a 2.6.8 kernel and the GIMP is version 2.0.5. Thanks for any suggestions, Shawn. pgpunbXcT9xLa.pgp Description: PGP signature
Re: [Gimp-user] Poor print quality with GIMP on Linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 04 October 2004 10:04 pm, Shawn Willden wrote: > "Scaling" is set to 100.0%. As Sven pointed out in private e-mail, I misstated here. That's what I get from going from memory. My goal is to avoid scaling (and the quality reduction that may occur), so what I've been doing is using the "Use Original Image Size" button and verifying that the "Scaling" is the right number of PPI (in PPI mode, not Percent mode). I have been seeing the blurriness without scaling up to the full size of the page, as would happen if Scaling was really at 100%. Shawn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBYrJE6d8WxFy/CWcRAgbQAJ9dSCT8qibquVtjQ5cxRfQBWZRBxACgkfzE Rn24Gv2L9ONiwTkLW3lBLbM= =fEUM -END PGP SIGNATURE- ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Poor print quality with GIMP on Linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (I hope you don't mind if I post this back to the list, Sven) On Tuesday 05 October 2004 09:04 am, you wrote: > > I have been seeing the blurriness without scaling up to the full > > size of the page, as would happen if Scaling was really at 100%. > > I have no idea what is causing your problems then. I have been told > that the gimp-print drivers would create superb printouts. Perhaps you > should ask your question on the gimp-print mailing-list. They should > know better. The gimp-print project has it's homepage at > http://gimp-print.sourceforge.net/. Well, I didn't post there because I'm not using the gimp-print drivers. The gimp-print drives don't support my printer, so I'm using the hpijs driver from HP. My assumption was that the print dialog and whatever it generates to send to the drivers is on the gimp application side, rather than on the gimp-print side, which I believe is only drivers. Is this not correct? Thanks, Shawn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBYs2M6d8WxFy/CWcRAuSQAJ9YhWHjDXdzcxUR27q8qwRG/a6fUwCfaHeb nzwUvnjYO6+ITYqwCE/EzmU= =sa0D -END PGP SIGNATURE- ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Poor print quality with GIMP on Linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 05 October 2004 11:27 am, Sven Neumann wrote: > I replied to the list (and to you) so the discussion has been on-list > all the time... Apparently my filters are putting your replies in my Inbox, rather than in my GIMP folder. I'll have to look into why that is. Anyway, sorry for the confusion. > The plug-in that ships with GIMP has been written by the gimp-print > developers and it uses libgimpprint. So you are using the gimp-print > drivers. I do not know exactly what the plug-in is doing in case of > your setup. The gimp-print folks should know better. Okay, thanks. I'll take my questions over there. Shawn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBYtxK6d8WxFy/CWcRAursAKCEXfxxTAdBxoQKom/+ZiVk+XvnFACgkzHb xU8/bHScEX8ZVTTzQ7ekVkk= =fNR5 -END PGP SIGNATURE- ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] Changing the default parameter file for MPEG1 encoding
How can you edit the template parameter file the GIMP uses for MPEG1 encoding? Specifically, is it possible to have the GIMP add the line: FORCE_ENCODE_LAST_FRAME by default to the parameter file? Thanks Shawn Williams___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user