Re: [Gimp-user] Epson i print format (Gutenprint question)
On 3/1/22 10:58 PM, Gary Aitken wrote: That uses up 360 bytes of output data, which matches the count. (35 + 19 + 4 + 32 + 3 + 26 + 128 + 113 = 360) Unfortunately, we're left with 1 byte, 0x0d, left-over. The next command in the print stream is actually the 0x0c (FF) at 124. Duh. Turns out the input data byte stream is terminated with a for each line. As a clarification, the byte count is a count of the total data bytes after they are expanded; it is not a count of the bytes in the input stream. In addition, despite the input bytes representing 2-bit nozzles, 4 per byte, it is not possible to specify a repeat of anything other than a 4-nozzle adjacent group on a 4 nozzle boundary. This is because the input stream is treated as a stream of bytes, not a stream of bits. Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Epson i print format (Gutenprint question)
On 3/1/22 1:34 PM, Liam R E Quin wrote:
On Tue, 2022-03-01 at 08:59 -0700, Gary Aitken wrote:
I have a simple image with one straight line of a single color.
Using the gutenprint dialog, I can print that file.
If I do a "reverse translation" of the raw file, there is one escp2
command
in it to print the line, shown below with some notes:
Hello! I'm afraid i'm a little lost here sir - which raw file exactly?
The stream being sent to the printer? What problem are you trying to
solve exactly? Why not look at the source code to the driver and/or
the printer specification?
Yeah, I'm probably way more lost than you are...
The file is one generated by gutenprint and sent using the command
"/usr/local/bin/lp -s -d 'printer_name' -oraw" to the cups print system.
So yes, the stream being sent to the printer.
I have been looking at the source, the (outdated) gutenprint docs, and the
(outdated) Epson ESCP2 documentation. The escp2 documentation discusses
the encoding with examples in terms of full-byte characters, which doesn't
seem like it translates obviously into 2-bit nozzles; unless you assume you
can't treat the input stream as 2 bit chunks.
I need to generate a number of specific output data streams to the printer;
generally regular, single-ink outputs. I can't get the gutenprint plugin to
do it because it always dithers the output; I don't see any way to turn the
dithering off. I'm not worried about banding. If I can understand the
output encoding, I can encode a replacement segment to patch into the output
stream. Not eloquent, but a means of testing to continue with a project.
FWIW, the hex dump in the original post is from a single pixel pure cyan line
360 pixels long, printed with print quality=manual, media=photo paper, 360x360
resolution, unidirectional, interleave off.
My attempt on the provided data follows:
If I start with the 0xde:
0c0 691b 0112 6802 0101 de00 1200 9a05 6959
esc i 12 01 02 0168 0001 (print command)
count is 0x168 = 360 lines is 0x0001
data starts at 0c9 de 1200 9a05 6959
0xde = 222 (negative byte) => 256-222 = 34; + 1 = 35 (repeat count)
next byte = 00 => 35 * {00 00 00 00} => 160 pixels empty space
0x12 = positive count of 18; + 1 = 19 data bytes following
gets us to 0df
0d0 5999 a565 5999 6566 5996 9695 655a fd56
fd
0xfd=253 (neg) => 256-253 = 3; + 1 = repeat 4
next byte (0e0) = 0x66 => 4 * {01 10 01 10}
0e0 1f66 9a59 6656 6566 5996 9665 9659
0e1 = 0x1f = 31; + 1 = 32 data bytes following
gets us to 102
0f0 6559 9565 6695 9965 a665 6969
100 5566 95fe 9919 6596 5996 5696 9666 665a
102 = 0xfe = 254 (neg) => 256-254 = 2; + 1 = repeat 3
next byte 0x95 => 3 * {10 01 01 01}
next byte (104) 0x19 = 25; + 1 => 26 data bytes following
gets us to 11f
110 5956 6669 0456 1044 0041 4110 0040 8140
11f = 0x81 = 129 (neg) => 256-129 = 127; + 1 = repeat 128
next byte (120) 0x00 => 128 * {00 00 00 00}
gets us to 121
120 9000 0d00 1b0c 1b40 5228 0008 5200 4d45
121 = 0x90 = 144 (neg) => 256-144 = 112; + 1 => repeat 113
next byte (122) 0x00 => 113 * {00 00 00 00}
gets us to 123
That uses up 360 bytes of output data, which matches the count.
(35 + 19 + 4 + 32 + 3 + 26 + 128 + 113 = 360)
Unfortunately, we're left with 1 byte, 0x0d, left-over.
The next command in the print stream is actually the 0x0c (FF) at 124.
Any insights would be much appreciated,
Gary
___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Epson i print format (Gutenprint question)
On 3/1/22 8:59 AM, Gary Aitken wrote: I have a simple image with one straight line of a single color. Using the gutenprint dialog, I can print that file. If I do a "reverse translation" of the raw file, there is one escp2 command in it to print the line, shown below with some notes: 006a 1b ( U 05 00 08 08 08 40 0b units; (page1=08), (vt1=08), (hz1=08), (base2= 40 0b = 0xb40 = 2880) ... 00c0 1b i 12 01 02 68 01 01 00 Print color1, compress1, bits1, bytes2, lines2, data... color1 = 0x12 = 18 = light cyan compress1 = 1 (TIFF compression) bits1 (bits/pixel) = 0x2 = 2 bytes2 = = 0x068 = 360 lines2 is # lines to print = 0x0001 = 1 data = unknown, not dumped; specifies the dot size, 2 bits each 0124 0c FF What I don't understand is what bytes2 is counting. There are 100 bytes between 00c0 and 0124. What does the 360 mean? Do the horizontal units factor or the compression type factor into this in some way? My oversight, I see the bytes2 is a count of pixels in each line. But the question remains: How do you compute where the next command (the FF) is? Do you have to actually decode the tiff data? The data doesn't look like tiff (I don't know squat about tiff), but aren't the first two bytes of tiff supposed to be "II" or "MM" describing little/big endian format? And this data starts with 0xde: The actual data, not shown above, looks like this: 0c0 691b 0112 6802 0101 de00 1200 9a05 6959 i esc de ... more data 0d0 5999 a565 5999 6566 5996 9695 655a fd56 0e0 1f66 9a59 6656 6566 5996 9665 9659 0f0 6559 9565 6695 9965 a665 6969 100 5566 95fe 9919 6596 5996 5696 9666 665a 110 5956 6669 0456 1044 0041 4110 0040 8140 120 9000 0d00 1b0c 1b40 5228 0008 5200 4d45 FF ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
[Gimp-user] Epson i print format (Gutenprint question)
I have a simple image with one straight line of a single color. Using the gutenprint dialog, I can print that file. If I do a "reverse translation" of the raw file, there is one escp2 command in it to print the line, shown below with some notes: 006a 1b ( U 05 00 08 08 08 40 0b units; (page1=08), (vt1=08), (hz1=08), (base2= 40 0b = 0xb40 = 2880) ... 00c0 1b i 12 01 02 68 01 01 00 Print color1, compress1, bits1, bytes2, lines2, data... color1 = 0x12 = 18 = light cyan compress1 = 1 (TIFF compression) bits1 (bits/pixel) = 0x2 = 2 bytes2 = = 0x068 = 360 lines2 is # lines to print = 0x0001 = 1 data = unknown, not dumped; specifies the dot size, 2 bits each 0124 0c FF What I don't understand is what bytes2 is counting. There are 100 bytes between 00c0 and 0124. What does the 360 mean? Do the horizontal units factor or the compression type factor into this in some way? How do you compute where the next command (the FF) is? The actual data, not shown above, looks like this: 0c0 691b 0112 6802 0101 de00 1200 9a05 6959 i esc de ... more data 0d0 5999 a565 5999 6566 5996 9695 655a fd56 0e0 1f66 9a59 6656 6566 5996 9665 9659 0f0 6559 9565 6695 9965 a665 6969 100 5566 95fe 9919 6596 5996 5696 9666 665a 110 5956 6669 0456 1044 0041 4110 0040 8140 120 9000 0d00 1b0c 1b40 5228 0008 5200 4d45 FF Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] gutenprint / cups -- defining a new printer configuration
On 2/25/22 5:10 PM, Robert Krawitz via gimp-user-list wrote: On 2/25/22 18:55, Gary Aitken wrote: I'm trying to define a new printer configuration, as described in the gutenprint developer's guide chapter 4. ... As I read section 4.1, it should be possible to duplicate a line in the file /usr/local/share/gutenprint/5.3/xml/printers/escp2.xml (freebsd system) change the text for the "name" parameter, and I would have a differently named printer which behaved exactly as the original -- they would both feed the same physical printer. (I'm attempting this as a mini-step to make sure it works, prior to modifying the printer definition). The important one to change is the "driver" parameter. Those need to be distinct. Ah...that did it, thanks. My head was getting bloody and sore. If you're using the Gutenprint plugin, you can create new printers via the printer selection box and set whatever printer you want, each one with its own settings. I realize that, thanks. Your answer implies it's possible to use Gutenprint without the plugin. Is there a way, and is there any documentation, on how to use gutenprint without the plugin? e.g. If I have an image file, is there a way to send it to a printer via gutenprint from the cmdline? Thanks, Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
[Gimp-user] gutenprint / cups -- defining a new printer configuration
I'm trying to define a new printer configuration, as described in the gutenprint developer's guide chapter 4. I believe this documentation is pretty dated, unfortunately; there is no file printers.xml that I can find anywhere in /usr/local. Based on the lines described in section 4.1, I'm guessing printers.xml has been superceded by the set of files in xml/printers/*.xml. For epson printers, that would be the file escp2.xml. As I read section 4.1, it should be possible to duplicate a line in the file /usr/local/share/gutenprint/5.3/xml/printers/escp2.xml (freebsd system) change the text for the "name" parameter, and I would have a differently named printer which behaved exactly as the original -- they would both feed the same physical printer. (I'm attempting this as a mini-step to make sure it works, prior to modifying the printer definition). So I duplicated this line: and changed it to: The only change being the addition of "My " to the name. However, after restarting cups, when I invoke gimp and try bring up the gutenprint dialog, I see the error message: "Plug-in crashed:"gutenprint" (/usr/local/libexec/gimp/2.2/plugins/gutenprint)" I am running gimp 2.10.20; not sure why the gutenprint plugin is in that 2.2 directory but that's where they all are. If I remove the original definition, so there is only one entry for model 107, it works with the new entry. What am I not understanding about how one should be able to define multiple "printers" to go to the same real printer? Thanks, Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
[Gimp-user] python plugins in 2.10.20
Attempting to run a home-grown gimp plugin I haven't run in a while, and I get the following error: File ".../process_for_web.py", line 43, in from gimpfu import * ModuleNotFoundError: No module named 'gimpfu' Apparently this is a result of migrations to python3 which are not complete yet? On ubuntu there are packages called gimp-python and python2-gimp which solve this problem. I'm running on free bsd; where would I find the source for those so I can attempt to port it? Or is there some easier work-around? Thanks, Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] change background in photo to grey scale
On 2/5/20 8:08 AM, PeterJWhite wrote: I'm brand new to GIMP. I photographed a bronze sculpture on an off-white paper background in natural light. The shadow areas of the background range from white to a peach color. I'd like to change the background to greyscale and then adjust it separately from the sculpture. I've made a quick mask but now can't figure out how to make the background a separate layer from the sculpture, so that I can color correct the two layers independently. The sculptor wants to keep the shadows in the background. 0. Make sure the Layers dockable dialog is visible: Windows/Dockable Dialogs/Layers 1. Duplicate the original layer: Layer/Duplicate Layer 2. Rename the duplicated layer Bkg (dbl click in layers dialog) 3. Move the duplicated layer below the original 4. Select the original layer 5. Add an alpha channel: Layer/Transparency/Add Alpha Channel 6. Convert your mask to a selection / select the background or foreground 7. If your mask/selection is for the foreground, invert it: selection/Invert 8. Edit/Clear This will make the background parts transparent Your foreground is now in the top layer, and the background in the one underneath labelled Bkg. ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] crop to content
On 1/30/20 1:44 PM, Liam Quin wrote: On Thu, 2020-01-30 at 20:44 +0100, geop wrote: I have scanned photographs which have a white border. I try "Crop to content" Crop to content removes outside borders of picels which all have exactly the same value but your border, although whiteish, is not like that. Rotate the image -- the easiest and fastest way is to use tool options, turn on reverse/corrective mode, and turn on a grid "number of lines", and change the number of lines until one lines up with the a vertical edge in the border; drag the lines to rotate them a little and get the grid line to match as well as possible, and then in case the image isn't actually perfectly square, repeat for the top and bottom inner border edges, then finally press Enter to do the rotation. Then crop the iamge with the crop tool to get rid of the border, if that's what you want, or to keep it, image->flatten image, then use rectangle select to select the inner pictiure, select->invert to change it to select the border, select->feather by 5px or so to make the edge soft, and drag the white swatch from the toolbox into the selection (if you don't have the default black and white, press d or click the black/white icon that's near the swatch). slave PS: clean the prints with a microfibre cloth, and the top of the scanner with that and eyeglass cleaner )spray onto the cloth of course, notthe scanner, and not the same cloth you use for prints; you can also use a special Japanese roller that was made for cleaning gramaphone records, https://amzn.to/2U9jN3R - but i worry that it may lift the surface of the print. This is probably too simple a solution, but... If the images are all the same size, and have roughly the same border, can't you specify a rectangle select of a size slightly smaller to eliminate the border, position it at the proper offset, and crop? Or if the images are different sizes, compute a rectangle for e.g. 98%? Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] active preview window and tool function
On 1/15/20 8:53 AM, Wightwizard wrote: When selecting from say colour/level or other tool and the tools dialogue opens, the image windoiw then dulls into background as it is no longer the active window. So when you make an adjustment, have to keep mouse clicking back and forth to see 'real' effect. Is there a way to prevent this and keep image as should be and not semi-transparent with the desktop image showing through each time you click into tool? If you use the keyboard accelerators to activate a tool, you can stay focused on the image window. If you hover your mouse over the tool button, the tooltip will show at the far right the accelerator key used to activate that tool. For example, 'M' will activate the "Move" tool. The switching back and forth is not an issue with GIMP; it is the window manager that is changing the focus, and is outside of GIMP's control. Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Converting from indexed to RGB modes; brush color off
On 12/23/19 7:46 AM, Øyvind Kolås wrote: On Sun, Dec 22, 2019 at 11:42 PM Gary Aitken wrote: I don't know if this is intentional or not; I would have thought that if the original color index map is not full, using a new color would add it to the map, but apparently not. What you are suggesting; to add the directly chosen color of the paintbrush/pencil tool, if there is empty slots in the palette would not conflict with this and be a nice addition - filing an issue against GIMP in gitlab.gnome.org to keep it from being forgotten might be a good idea. It would have to be only the directly selected foreground color though and not its antialiased results with various background pixels which would be ohter colors implicity attempted to be inserted. Since the more complete port to babl/GEGL with 2.10 GIMP is no longer special casing INDEXED/GRAYSCALE mode from RGB. This meant as new features we gained anti-aliasing for the paintbrush in indexed mode, ability to blur and do other filters; as well as anti-aliased results when merging down layers/text-layers - this would quickly exhaust the free slots in the palette if all attempted to be used colors were added (checking if the current foreground color is part of the palette before starting a new stroke is also a more feasible code change than always dynamically growin the palette). /pippin Done, issue #4400 ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Converting from indexed to RGB modes; brush color off
On 12/20/19 8:37 PM, Maxomega wrote: So I was editing a sprite sheet for a video game character, and after working with it for a bit, I noticed the color I was using was off from the brush color. Later, I noticed the layers were behaving strange, and that it probably had something to do with being in indexed mode. I changed the image to RGB mode, but my brush color is still off, and layering multiple brush colors combines the colors for some reason. My brushes are at 100 hardness and 100% opacity, so I don't know what the issue could be. I'm just trying to paint over all the color in the image to be 00FF00, or the greenest green. First attached is a screenshot of the base image, unpainted. Also included is the brush color, which already doesn't match the outside. Note that the top layer is the active one. Second attached is what happens when I try to draw over the image with a plain green brush. The black rectangle is the boundary of the middle layer, but I'm not sure why it's black at all. Third attached is what happens when I try to do same thing (painting with the green brush), but with the second layer active. I'm just really confused. I don't know much about GIMP, but I've been using it for well over 5 years and I've never come across something like this. Attachments: * https://www.gimpusers.com/system/attachments/1316/original/Capture.PNG * https://www.gimpusers.com/system/attachments/1317/original/Capture2.PNG * https://www.gimpusers.com/system/attachments/1318/original/Capture3.PNG I don't know much about this, but doing some fiddling around I've discovered the following: If the original indexed colormap does not contain the color you desire, painting will paint black: 1. create an 8 bit integer color image, transparent background change the image color mode to indexed change the paint foreground color to full green painting in the image will paint black 2. create an 8 bit integer color image, transparent background change the paint foreground color to full green paint in the image => paints green change the image color mode to indexed paint in the image => paints green I don't know if this is intentional or not; I would have thought that if the original color index map is not full, using a new color would add it to the map, but apparently not. By default, when you choose convert to indexed mode, the colormap chosen is "Generate optimum palette" with a maximum number of colors of 255. The "Remove unused and duplicate colors from colormap" option is checked. You cannot uncheck it. To uncheck it, switch to custom palette mode, uncheck it, and then switch back to generate an optimum palette. Unfortunately, doing this has no affect; the generated palette still contains only the existing colors, and no holes for additional colors. I would suggest you create a new colormap with only the colors you wish to use in your images: Windows/Dockable Dialogues/Palettes I would suggest reading the following sections of the 2.10 user manual: 2.4 Colormap Dialog 12.1 Palettes/Colormap 3.5 Palettes Dialog (esp. the Note) Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] color calibration problems
On 12/17/19 2:14 PM, achmil wrote: Sorry for my english but i'm a frenchy. I use version 2.10.14 and I have difficulties with the calibration under gimp. I use EIZO monitor and Epson SC-P800 calibrated with Istudio. I try to use the Soft Proof Mode but i don't find it in french version. After reading the chapter 5.8, which speak about the display filter, i don't find this on my version. I think what you want is Edit/Preferences/Color Management In the doc (https://docs.gimp.org/2.6/fr/gimp-display-filter-dialog.html) we have a filter < Calibration des couleurs > but on my screen, i haven't this filter . What's wrong ? This is an old (version 2.6) manual; things have changed a lot since then. See: https://docs.gimp.org/2.10/en/gimp-pimping.html#gimp-prefs-color-management Other question : Preference options don't seem to work. When I apply an ICC profile printer, nothing happens on the screen. Why ? When I print, the colors are not exact and the contrast is weakened. Try this: 1. Open an image you want to proof 2. View / New View (The new view will be the proof view 3. In the new (proof) view: 3a. View / Color Management / Proof Colors (make sure it's checked) 3b. View / Color Management / Soft Proofing Profile Select the profile you want from the drop-down; If it is not there, choose "Select color profile from disk..." 4. Compare the two images; they should be different. Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Despeckling photos
On 12/4/19 1:44 AM, Liam R E Quin wrote: On Wed, 2019-12-04 at 03:39 +0100, Gimp_Noob wrote: I have several photos which I'd like to try to clean up as best I can. First, scan at higher resolution than yu plan to use. At least double. SOmetimes i find that select by colour works well. (1) make sure you have both blacks andwhites in your image, e.g. with levels or curves. (2) select by colour on a white area. (3) grow selection e.g. 2 pixels )4_ shrink selectin by 2 pixels (6) feather by 1 pixel (requires greyscale or RGB iamge, not indexed) (7) fill with white (e.g. drag the swatch from the toolbox, or use control-. or control-,) (8) select none repeat steps 2 to 8 with black instead of white. Can you explain what steps 3 and 4 acconplish? It seems like they should cancel each other. Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Clone Tool Stuck on "Set a source image first"
On 10/1/19 6:48 PM, Melvis wrote: The clone tool doesn't seem to work. With my image open and the clone tool selected, the message directly under the image window reads "CTRL-click to set a new clone source". When I do so, the message changes to "Set a source image first" and I can go no further. The clone tool window on the bottom left side has "image" selected under "Source". How do I get past this? I think you are still holding the ctrl key down. Once you set the starting source using ctrl-click, let up on the ctrl key. The message should change to "Click to clone (try Shift for a straight line, Ctrl to set a new clone source". Move the mouse to where you want to clone and click, then drag with the button down to clone an area. Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] liquid rescale to fill transparent areas
Can someone tell me how to get the liquid rescale plugin to expand into transparent areas? I have a panorama with stepped transparent areas of sky in one part of the image. I would like to expand the sky into the transparent areas, but I can't get it to work. The image as a whole does not need to be resized. I started by painting a preserve mask over everything but sky, but the result looks like nothing was done. I then tried using a rigidity mask and no preserve mask, with the same result. Is it even possible to use LqR to do this? Is there a better way? from what I understand from your description about the transparent areas , hope I'm correct with this - trying to visualize hmm what you are doing , I know this will work there's a plugin Gimp Resynthesizer and it works by healing the transparent areas or selection areas and it's easy to work this plugin , someone who gives a good help page is https://patdavid.net/ look on his site many useful articles might be one for LqR never know if you don't go look. Thanks for the reply. I've tried resynthesizer and the results are not very good with sky. I've tried both resynthesizing transparent areas and resynthesizing between a pasted section at the top and the existing sky at the bottom. Sky seems to be particularly difficult to resynthesize in a manner which complements the existing sky in the image. None of the articles I have found on LqR show its use for filling transparent areas without resizing. Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
[Gimp-user] liquid rescale to fill transparent areas
Can someone tell me how to get the liquid rescale plugin to expand into transparent areas? I have a panorama with stepped transparent areas of sky in one part of the image. I would like to expand the sky into the transparent areas, but I can't get it to work. The image as a whole does not need to be resized. I started by painting a preserve mask over everything but sky, but the result looks like nothing was done. I then tried using a rigidity mask and no preserve mask, with the same result. Is it even possible to use LqR to do this? Is there a better way? Thanks for any insights, Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
[Gimp-user] cancel darktable image load?
GIMP 2.10 auto-loads a raw file via darktable, loading the file from darktable when darktable is exited -- thanks, works great. But is there a way to cancel this process? i.e. I loaded a file and part-way through the darktable manipulation I decide I want to cancel the process, so I don't have to wait for darktable to process the image and GIMP to load it? ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] interactive batch processing
On 12/9/18 4:38 PM, Bob Long wrote: Gary Aitken wrote on 10/12/18 4:50 am: ... Is there a way to do one of the following: A. Start gimp with a list of file names to process, and have it load only the first on the list. Then when one quits or closes the image, load the next one, etc? B. I can feed the list of file names to a python-fu script, which then can open and display the image. Is there a way for a python-fu script to wait for, or be notified of, the closing of an image display? This would allow the script to effectively pause and allow processing before opening each successive image. gimp-context-push/pop seem like they may somehow enable this but it's not clear to me how they are used. ... Have a look at this script: http://gimpchat.com/viewtopic.php?f=9=4846=183034=sequential_processing#p183034 On 12/9/18 7:06 PM, Akkana Peck wrote: Gary Aitken writes: ... Is there a way to do one of the following: A. Start gimp with a list of file names to process, and have it load only the first on the list. Then when one quits or closes the image, load the next one, etc? I don't know of one, though I would find it useful -- when processing a lot of images from a photo outing, for instance. B. I can feed the list of file names to a python-fu script, which then can open and display the image. Is there a way for a python-fu script to wait for, or be notified of, the closing of an image display? This would allow the script to effectively pause and allow processing before opening each successive image. gimp-context-push/pop seem like they may somehow enable this but it's not clear to me how they are used. I don't know of a way to do that. However, you could do something like: def wait_until_image_closed(filename): '''Poll GIMP's image list, return when there's no longer an open image connected to filename. ''' while True: for img in gimp.image_list(): if img.filename == cur_filename: # or whatever test you want return time.sleep(1) Or better yet, get the current image before starting the loop, then loop until that image is no longer in the image list. I know polling is slightly icky, but I've done it in several GIMP Python plug-ins when there was no notification available. For this task, though, I'd be tempted to use an easier approach: Start GIMP (with no files yet). In a shell window, cd to the directory with the files I want to process, and do this (with whatever list of files you want): for fil in *.jpg; do gimp $fil read x done The first file comes up as a GIMP window. Process it, and when you're ready for the next image, go to the shell window and hit return, and the next file comes up in GIMP. It's not quite as clean since you still have to hit return for each image, but that's still a lot easier than navigating to each new image in the File->Open dialog. Thanks both of you for your suggestions and pointers. I think all of those will enable me to work out a solution. Thanks again. Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
[Gimp-user] interactive batch processing
In the past I have interactively batch processed images via a shell script that invokes gimp for each image. This is both inconvenient and slow. Inconvenient because there are parameters I need to enter into some python-fu scripts that are the same for each of the images, and slow because of the gimp startup and shutdown each time. Is there a way to do one of the following: A. Start gimp with a list of file names to process, and have it load only the first on the list. Then when one quits or closes the image, load the next one, etc? B. I can feed the list of file names to a python-fu script, which then can open and display the image. Is there a way for a python-fu script to wait for, or be notified of, the closing of an image display? This would allow the script to effectively pause and allow processing before opening each successive image. gimp-context-push/pop seem like they may somehow enable this but it's not clear to me how they are used. It seems like gimp-display-get-window-handle might be useful somehow, if there were a means to be notified when the window is destroyed. Any thoughts / hints would be much appreciated. Thanks, Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] ufraw -- exposure vs base curve
On 03/14/18 12:51, Rick Strong wrote: If you are talking about photographs, altering the curve is not the same as boosting the exposure. Generally speaking, boosting the exposure makes the whole picture brighter, while playing with the curve alters areas--shadows, mid-range, highlights--of the photograph. But, you may play around with one to end up with a result very similar to the other. This is best done in raw. I understand altering different parts of the curve affects different aspects of the image, e.g. highlights vs midtones vs shadows. What I'm asking is if modifications to exposure and the base curve are applied to the same thing at the same place in the pipeline. For example, I am looking at an image where with 0 exposure and the default linear (45 deg lower left to upper right) base curve, the rightmost 3/8 of the histogram is empty. It takes an increase in exposure of about 1.33 to bring the curve to the far right. I can get what appears to be the same effect by grabbing the upper right anchor of the line and dragging it left until it is about 3/8 of the way from the vertical left axis, essentially just making the slope of the line a lot steeper and leaving the origin at the lower left. Are those equivalent operations, or are they doing something subtly different in terms of what processing is done to the image? They appear to be equivalent. But that may not be the case. For example, does boosting the exposure affect noise or bayer decoding artifacts more than adjusting the curve? Alterations to the base curve in ufraw are applied at one point in the pipeline and alterations to the secondary curve (under "Correct luminosity, saturation") tab are applied at a different point. Changes to the secondary curve affect the image in a different manner than the exposure and the base curve. Thanks, Gary Not sure where to ask this as I couldn't find a ufraw forum, but I figured a number of users here might be able to answer. Please redirect me if this is inappropriate. Can anyone explain to me the difference between manipulating the base curve in ufraw and boosting the exposure? I'm wondering in terms of where in the processing pipeline the change takes place. i.e. If I could manipulate the base curve to make the image look exactly the same (to my eye, I know it's not perfect) as boosting the exposure, is there fundamentally a difference in the result? ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
[Gimp-user] ufraw -- exposure vs base curve
Hi Folks, Not sure where to ask this as I couldn't find a ufraw forum, but I figured a number of users here might be able to answer. Please redirect me if this is inappropriate. Can anyone explain to me the difference between manipulating the base curve in ufraw and boosting the exposure? I'm wondering in terms of where in the processing pipeline the change takes place. i.e. If I could manipulate the base curve to make the image look exactly the same (to my eye, I know it's not perfect) as boosting the exposure, is there fundamentally a difference in the result? Thanks, Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] grouping multiple layers
On 02/09/15 07:03, Joao S. O. Bueno wrote: Of course, the documentation in this case is an obvious mismatch to what the program does. The current behavior is useless, under any workflow I try to imagine (after all, if the layers are to be flattened, there is no reason for place them in a group to start with); I'm glad I'm not the only one who had trouble with my imagination... Anyway, the right fix for this wouldbe to allow multiple item selection, as Alex puts it. Meanwhile, I've put together this small Python script that does just that: move the selected (linked) layers to a target (active) layer group. Just copy it to your plug-ins folder, and mark it as executable (not needed under windos) http://fpaste.org/183299/ Muito obrigado, Joao! Gary On 8 February 2015 at 17:38, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: On Sun, Feb 8, 2015 at 8:14 AM, Gary Aitken wrote: When you say some preliminary work has been done there, are you referring to the chain / link that appears in the layers dialog? No, it's been there for ages :) I'm talking about how you can make multiple selections of assets (brushes, gradients and so on), if you switch their view to 'list' rather than 'icon'. It should work for all kinds of lists including layers, and for assets it shouldn't be limited to the list view. It just hasn't been done yet. Like every feature, it needs a contributor to write actual code. ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] grouping multiple layers
Hi Alex, Thanks for the response. I expected all of the visible layers to simply be moved as separate layers into the layer group. In that case you need to create a new group layer. You also need GIMP 2.8 for that. I am running 2.8.14 Perhaps I was too vague in my original question; I'll try to clarify. I have tried it both ways: 1a. Create new group layer (Layer/New Layer Group) 1b. Layer/New from Visible. This creates an additional new layer as a sublayer of the group layer created in 1a, containing the visible layers I wanted as sublayers, all flattened into the new sublayer as a single layer. The original layers are still present and independent at the top level. 2a. Layer/New from Visible This creates a new independent layer containing the visible layers I wanted as sublayers, flattened into the new layer as a single layer. The original layers are still present and independent at the top level. In neither case are the existing layers moved to become sublayers. Look at the Layer menu closely and at the small toolbar in the bottom of the Layers dockable palette. I don't see anything there that is not also available via the layers menu. There's a new layer button equivalent to Layer/New Layer, and there's a new group button equivalent to Layer/New Layer Group. Plus the up, down, duplicate, anchor, and trashbin. Should I be seeing something additional? still searching for a convenient solution... Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] grouping multiple layers
Hi Alex, I'm not sure why you are trying to do this. Perhaps I don't understand what you are trying to achieve :) To move existing layers to a layer group, click to select the first one, then drag and drop onto the layer group, repeat for each layer. That's what I'm trying to do. I know I can do it that way. What I was looking for was a more convenient way of doing it -- by somehow selecting / marking / making visible the desired layers, and then moving them as a group all at once into the layer group. Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
[Gimp-user] grouping multiple layers
Hi all, It's not clear to me how to create a group of layers from existing layers. According the the manual: You can put layers to be added together to a layer group by making them, them only, visible, and using the “New From Visible ” command. All visible layers, outside and inside layer groups, will be added to the active layer group. This doesn't do what I expect. What it does is add a single layer to the layer group, and that single layer is the result of flattening all of the visible layers. The original layers still exist as separate layers unrelated to the layer group. I expected all of the visible layers to simply be moved as separate layers into the layer group. Am I doing something wrong, or is this the intended behavior? If it's the intended behavior, then is there an easy way to group a bunch of existing layers other than individually moving them to the group? I tried chaining the layers together and moving one of them to the group, but only the layer I grabbed and moved was put in the group. Thanks for any clarifications... Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Borderless photo not correct
On 01/10/15 13:32, Mark Bourne wrote: Tikiman wrote: Hello to all I am a very new user of Linux and the supplied Gimp program. I tried out my printer (Canon Pixma MG5550) in gthumb and Gimp by printing a borderless 6 x 4 photo. I changed the settings in the print tab to read Glossy photo paper and size as borderless 6 x 4 and also the orientation to suit my needs. The photo printed okay BUT there is a small border about 8mm at the top and 2mm at the bottom of the photo.in portrait style. This did not happen when I had Win XP and Arcsoft software and after checking as much as I can I am unable to locate a solution. Does anyone know why this happens and can it be resolved?. I would appreciate some help with this please. many thanks Tikiman What are the dimensions of the photo? Many digital cameras produce images with a 4:3 ratio, which doesn't exactly fit the 3:2 ratio of 6x4 paper. Either a border has to be left along the shorter edges or part of the image has to be cropped from the longer edges. Actually, there is a third option, and I think it is the default for some windows applications: do an asymmetrical resize to fill the paper. You get a distorted image but apparently a lot of people don't notice. (I'm not sure if it's the default or not; I normally don't run win anything.) I'm not sure if that decision would be down to the software or printer driver, but either way it's possible that GIMP / Linux driver takes the former option so that no part of the image is lost, while Arcsoft / Windows driver may have taken the latter option to produce a truly borderless print at the expense of losing part of the image. I believe it's an option somewhere in the print configuration, something like resize image to fill paper (printer driver) Try cropping the photo in GIMP so that it does have a 3:2 ratio before printing. Also check File Page Setup in GIMP to ensure it is not adding margins. If that still leaves a border, I suspect it would be more down to the printer or driver rather than GIMP. Additional note: If you're printing *with* a border, you want to resize to whatever the final aspect ratio will be, and that will depend on the actual border size. In this case the aspect ratio of the image will not be the same as the aspect ratio of the paper. For example, I print using the smallest border for my epson printer, which is 3mm: 4 = 101.6mm 101.6 - (2*3mm) = 95.6mm 6 = 152.4mm 152.4 - (2*3mm) = 146.4mm 152.4/101.6 = 3/2 = 1.5 146.4/95.6 = 1.53 Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Text Problem in 2.8.14
On 12/21/14 12:10, willderrness wrote: I upgraded and cannot make the text work - a layer appears and I can see the text in the layer but it will not appear in the text box on my image. It worked in earlier versions - please help as I am making XMAS cards - thanks in advance... Will I'm not sure what you mean by I can see the text in the layer. Are you saying you can see the text where it is the default name of the layer in the layers dialog (usually in a separate window to the right of the image window)? Check to be sure your foreground color is different from the background layer over which you are creating the text. When you click to insert a text layer, that layer is inserted above whatever the currently active layer is. If you want the text on top of everything, make sure the active layer is the upper most one (the top one in the layers dialog) before you activate the text tool and click to insert text. Alternately, check to be sure there are no other layers on top of the text layer. Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Text Problem on New Instal
On 12/19/14 15:18, Lougha wrote: I've been using Gimp on an older Mac for a while, but recently bought a new computer - MacBook Pro Retina, 13-inch, running Yosemite 10.10.1. I loaded Gimp 2.8.14 When I try to work on a file, the fonts are all heavily pixelated. The attached screen-shot is a new file, 300 dpi, 8x5 inches. The view is 100%. All font's appear this way, even when I try to export the image as a JPG. the preview buttons also appear very fuzzy when I pull up the font menu. Any ideas? Attachments: * http://www.gimpusers.com/system/attachments/179/original/Fuzzy_Fonts.tiff This looks to me like the normal anti-aliasing that you get by default, although it's a bit difficult to tell because the Calibri font is not on my fbsd system. It you want a sharp transition from black to white, deselect the anti-aliasing box in the font tool. What exactly do you mean by pixelated? All text will appear pixelated if enlarged, which this image has been. What are you expecting it to look like? The font box above the text indicates a size of 100 pts, which that text clearly is not -- assuming the rulers are set in inches. The font tool on the left says 18 pt, which it appears to match better. Can you post an image made with the Sans font, and post the image itself, not a screen shot? The one thing which looks strange to me is that letters such as 'i', which in some fonts such as Sans has solely vertical and horizontal lines, appears anti-aliased. Since I don't have the Calibri font I'm not sure what it *should* look like. In the Sans font an i has sharp transitions from black to white, even with anti-aliasing on. Exporting to jpeg will never improve pixelation issues. In general, converting to jpeg will soften transitions. Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Problem saving in PNG format
On 12/09/14 09:40, John Williams wrote: I have been using GIMP to save image files in the .png format for many years. I recently upgraded to GIMP 2.8 and I cannot seem to save/export the image files. This is not about what kind of command I am using or whether or not the user interface is good or bad. When I activate the export command I successfully complete the process without any error message. I am using the .png image files as wallpapers for the fvwm window manager and I get no error messages or any indication that something is wrong, I just get no wallpaper image. (Please refrain from commenting about the dinosaur-ness of my window manager;)) I have searched the FAQ and gimp user archives but cannot seem to find any mention of this problem. I have also made sure that I have merged and/or flattened the images and have also used the convert tool to use the sRGB color profile. I also have the file-png plugin loaded in my plug-in directory. None of these options have made a difference. Does anyone know anything about this kind of problem? Does anyone know where I might find information about how to fix this kind of problem? Thanks very much for your assistance. Is there any message in gimp's error window? I presume you get the Export Image as PNG dialog, and when you click the Export button, you see the progress bar at the bottom of the main export window fill up before the dialog disappears? Are you saving a new image or overwriting an existing one? What kind of system are you running on? Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Resizing an imaged - revisted
On 11/19/14 18:45, HarryA wrote: I have photo of my wife which is an up close shot of the face. Because she is near sighted the view of eyes through the tri-focual lens are made so small such that the side of the head shows through the lens. I have removed the eyes to separate layers (left and right eye layers) when the three layers are made visible it looks like the original image. But no matter how I try I can not resize an eye image without the other layers getting resized also. I can not un-anchor nor dissociate the eye layer from the face? The layers are not anchored together in the layers dialog. How does one do that? You are probably resizing the image and not the layer. Try this: 1. Make the left eye layer the active layer. 2. Use the rectangle select tool to make a selection around the eye and quite a bit more, but smaller than the whole image. 3. Layer / Crop to selection 4. Clear the selection (Select / None) 5. To make the layer larger: Layer / Scale Layer Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] paint with color from gradient
On 11/17/14 07:49, Helen wrote: But there is nothing in the matrix that says says Color from Gradient. The closest thing I can find is Random color. In gimp 2.6 there is a tick-box for Color from Gradient and it makes a graceful predictable gradual flow from one color to another. Can we still do that, in 2.8? Hmmm, on my 2.8 version it's item #5 in the drop-down. In the matrix, it would be row 4 (color) and column 7 (fade). Are you seeing something different? On Mon, Nov 17, 2014 at 1:43 AM, Olivier oleca...@gmail.com wrote: 2014-11-17 0:11 GMT+01:00 Helen etter...@gmail.com: I used to know how to paint with color from gradient. Various help sites say hoose the dynamics Color From Gradient, but I haven't been able to find that option. How can I use airbrush with Color from Gradient? Thanks, When the airbrush tool is selected, look in its options in the bottom part of the window. Click the icon on the left of Dynamics to open the menu of available dynamics. ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] [Gimp-developer] Test images and test suite (was Re: GIMP should fork babl and GEGL)
On 11/11/14 08:15, Elle Stone wrote: So the important question is: *What copyrighted or otherwise test images GIMP users might have downloaded from the internet and found useful, and *what kinds of test images GIMP users might have already put together, *for what particular testing purposes. The things I find most useful are the following: 1. Peoples' faces. Important here is a wide selection of ethnicities, such as white, asian, african, latino. It would be useful to have individual images; and combination images with the extremes (e.g. white, african, and wedding dress in the same image). In the african group, a wide range from very black to brown. 2. Highly saturated from the natural world -- birds and flowers, for example. I may have a few birds of use. Others may well have better images. 3. Color gradients and ICC targets. In this category I would find useful a chart specifically designed to show the boundaries of different well-known colorspaces, such as sRGB, AdobeRGB, and ProPhoto. If the chart had an outline of the colorspaces as separate .xcf layers it would be great. It might be useful to have layers for some printers as well. It would be good if images have neutral gray cards / gradients of some sort in them, although that is obviously not always possible. Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] [Gimp-developer] Test images and test suite (was Re: GIMP should fork babl and GEGL)
On 11/11/14 17:32, Chris Mohler wrote: The 2002 version contains a *wide* variety of things that can go spectacularly wrong when printing (eg for one, over saturation of black completely destroys the image of the watch), and was a real life saver when I was setting up the workflow of: Workstation - Digital RIP - Large Format Printer. It's a beastly image to try and print correctly, and I imagine the 2009 version is just as devious :) For the curious and not overly competent, can you shed some light on the kinds of issues you had and how you dealt with them? ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] [Gimp-developer] GIMP should fork babl and GEGL
I'd like to add my penny's worth on this discussion. My primary use of gimp involves editing photographic images, for both web and print purposes. On 11/06/14 05:04, Elle Stone wrote: Speaking as a developer (you all keep telling me I'm a developer), a crucially important guiding principle for writing a high end image editor is that you never mess with the user's RGB data without the user's explicit consent. If you *ask* the user whether they want to have their data treated as bonified same as GIMP's sRGB and then use optimized sRGB-only code, that's one thing. Doing so behind the user's back, without their consent, that's another thing. That is disrespecting the user's control over their RGB data. This is critical. If I'm working with a wide-gamut profile, I really really really don't want gimp screwing with the rgb data without my say so. Even if the result is not obvious visually, I need a heads-up so I can pay close attention to what's happening and undo the operation if appropriate. Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] [Gimp-developer] GIMP should fork babl and GEGL
Hi Alex, If you *ask* the user whether they want to have their data treated as bonified same as GIMP's sRGB and then use optimized sRGB-only code, that's one thing. Doing so behind the user's back, without their consent, that's another thing. That is disrespecting the user's control over their RGB data. This is critical. If I'm working with a wide-gamut profile, I really really really don't want gimp screwing with the rgb data without my say so. Frankly, I'm puzzled. It's been, how many? 8 years? since GIMP asks users what it should do with a picture that is tagged with a profile that doesn't match the current RGB working space. Has anyone actually suggested that this is going to be otherwise? :) Maybe I'm misunderstanding the discussion. Gimp asks when one opens an image what one wants as the working colorspace. But we're talking about operations *after* the image has been opened and the working colorspace has been established. Once I establish the colorspace, I expect all operations to be performed in a manner which is consistent with and preserves that colorspace. If some operation deals in some other space without my knowledge, that's not good. My apologies if I'm misunderstanding the discussion. Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] How to swap image colors
I have a logo that I'd like to swap the colors in. The words are blue and the background is white. I'd like to make the words white and the background blue. How can it with this .png file? It depends on whether the words are dithered or not. If there are sharp edges and the image really only has two colors, try the following: Click on the eyedropper (or O (O not 0), then click on the words to make the color of the words the foreground color. Click on the color tool (or shiftO), then click on the words to select all of the color in the words. Don't use the magic wand, as it only selects colors which are contiguous. Invert the selection (Select/Invert or ctrlI). Click on the Bucket Fill tool (or shiftB). Look in the tool options to make sure the fill type is FG color fill. Click on the background area to turn it the color of the letters. The whole image should now be the same color. Invert the selection again. Click in the tool options to change the fill type to BG color fill. Click on the words to turn them the background color. If the words are dithered it's more difficult as you need to change all the in-between colors to an appropriate in-between color. If you need that let us know and we can go into more detail for that. ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Color shift when opening TIFF?
On 10/23/14 13:31, Keith Purtell wrote: I've been using GIMP for several years to (among other things) open TIFF files, edit, export into Acrobat Pro to create a PDF. Today I took a client PDF and saved it as high-res TIFF, fixed a problem, exported the revised TIFF and converted to PDF. I do this often. It wasn't until I got to looking at the new PDF that I noticed a big color shift in one section. There's a pale green box with darker forest-green text inside. Both shades of green looked like the saturation had been pumped way up. I backtracked, and finally realized this color shift was happening the instant GIMP opened the TIFF. Just to be clear, this is not a buggy TIFF from outside. I made it myself by take a normal PDF and using the Save-as-Image function. This didn't happen with the other three images from the same project. Experimenting with Mode made no difference. Ideas? I'm not certain, but my guess is the tiff file has an embedded color profile other than whatever your gimp is set to, and the conversion option is set to auto-convert without asking questions. Open Edit/Preferences/Color Management and check what RGB profile is set to and what File Open behaviour is set to. Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Selection to Layer
New user here. running GIMP 2.8.10 on an old XP machine. Have downloaded 2.8.14 but holding off on the installation while learning. Al that aside. Question, How do I change a selection to a layer? Edit/Copy Edit/Paste as/New Layer ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] keyboard shortcuts for 50% view, etc
Thanks for the verification.
Bug? Shift+2 == @, but you'd think that all keyboard shortcuts
should use the actual scan code for the key(s) and not its logical
input value.
I say bug because it is, according to the Edit/Keyboard Shortcuts
menu/ +View dialog, already assigned.
How the mapping is done would depend on where in the stack one did it.
I could see a case for doing it either way.
Gimp has an interesting issue for shortcuts, I think (I'm not familiar
with the code) Chars/keycodes are not mapped the same all the time.
You want normal characters, such as @, when entering text; but the rest
of the time you want it to be a shortcut. Which means it has to be
mapped in two different ways depending on the state. It obviously does
it correctly / according to the docs/interface for some characters, but
not others.
I have not been able to get the keyboard shortcuts for 100% view
(shift2, etc.) to work since as long as I can remember. The ones
for 100% and greater ('1', '2', etc.) seem to work fine.
If I activate the shortcut key editing dialog and try to set the
shortcut manually, e.g. shift2 for 50%, instead of displaying
shift2 it displays @ (which is the normal character for
shift2 on my keyboard) and it works fine.
Does anyone else have the same issue?
Is there something I am missing, or are the shortcuts simply not
working in my (fbsd) build?
Aha, here we are (I think).
https://bugzilla.gnome.org/show_bug.cgi?id=677707
Thanks.
___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives: https://mail.gnome.org/archives/gimp-user-list
[Gimp-user] keyboard shortcuts for 50% view, etc
I have not been able to get the keyboard shortcuts for 100% view
(shift2, etc.) to work since as long as I can remember.
The ones for 100% and greater ('1', '2', etc.) seem to work fine.
If I activate the shortcut key editing dialog and try to set the shortcut
manually, e.g. shift2 for 50%,
instead of displaying shift2 it displays @ (which is the normal character
for shift2 on my keyboard) and it works fine.
Does anyone else have the same issue?
Is there something I am missing, or are the shortcuts simply not working
in my (fbsd) build?
Gary
___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Optimize jpegs
On 05/22/14 07:08, Søren Pilgård wrote: On Thu, May 22, 2014 at 2:30 AM, Owen rc...@pcug.org.au wrote: I'm creating some textures for 3d models using gimp. I've been exporting as jpg with quality set at 100, but the file sizes are humongous. What do you think is the best setting to bring down the file size with no noticeable loss of quality? Well, I would simply experiment and decide what is best for you Open original, export as new-name1.jpg at say 70% Then reopen original, and export as new-name2.jpg at say 60% and so on Most of my saves are at 50% Why jpgs? What sizes do you get with pngs? It is indeed hard to give a perfect number out of the box. The overall visual quality is very much dependent on what the image actually depicts and on what kind of compromise you can tolerate. A dirt texture can probably pull off a much lower quality than a smooth gradient. First, make sure the image is down-sized to something like 1280 x 1024 or less. Then turn on the preview in the jpeg export dialog. That will tell you both how large the file will be, and you can view the preview to see what it will look like. Decrease or increase the percentage until you're happy with the compromise. Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] greek letters
Are you using Linux? What is your locale setting? I can't type an alpha either, on Debian Sid, UTF-8, libgtk2 2.24.23-1, git master gimp from a few days ago. [fixed version, sorry!] For me, using the Gimp on-canvas text tool, hold down control and keep it pressed hold down shift and keep it pressed press u and let it go (keeping control and shift pressed) press 3 and let go press b and let go press 1 and let go let go of control and shift will insert a lower-case Greek letter alpha (α). When I try that, it works up to the b (as soon as I type the u a little window pops up and subsequent digits go there), but it refuses to accept either b or c -- it simply does nothing for those letters, and nothing appears in the little IM window. It will accept digits 0-7 and 9 and a, d, e or f but not 8, b or c. gnome-terminal behaves the same way. We discussed it on IRC and Liam wondered whether I had some other binding for ctrl-shift-b and c and ctrl-shift-8 -- it's possible, but if so I don't know about it and they don't do anything I can see. I can't find any such bindings in my window manager. It works two different ways on this windoze box (can't test on my fbsd box as I'm rebuilding world now). 1. Release the ctrl and shift after typing 'u'. Then hit enter after all the hex chars are in. 2. Keep ctrl and shift down until done with hex chars; releasing ctrlshift completes the sequence Does the problem exist with both methods? Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] greek letters
It works two different ways on this windoze box (can't test on my fbsd box as I'm rebuilding world now). 1. Release the ctrl and shift after typing 'u'. Then hit enter after all the hex chars are in. 2. Keep ctrl and shift down until done with hex chars; releasing ctrlshift completes the sequence Does the problem exist with both methods? No, only with the second one. The first method works and allows me to enter an alpha. (Can't speak for the original poster.) That points strongly to there being some sort of keyboard accelerator overriding the input for the characters that don't work, since in the first case after ctrlshiftu the characters being typed are normal and in the second they have the ctrlshift modifiers as part of the keystroke. I can think of only three likely place for that to be taking place: 1. Gimp 2. window manager 3. x-server mappings via xmodmap fwiw, both methods work here on win7 and fbsd. Does anyone know of any other app that uses ctrlshiftu to start a unicode entry? If so, what happens in that app? Or any app where it could be assigned temporarily for testing? Alternatively, one could try assigning one of the sequences which doesn't work to some gimp function and see if that works. If it works, it would indicate the keystroke was getting to gimp and is not being siphoned off somewhere higher up. If it doesn't work, it doesn't say anything one way or the other. Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] greek letters
On 05/13/14 07:32, Alexandre Prokoudine wrote: Adding a Greek keyboard layout to your operating system/desktop environment of choice would be a sensible solution. There also typically is an app usually called Character Map that you can use to copy/paste single letters from. Alexandre On Tue, May 13, 2014 at 5:30 PM, gimppimpf for...@gimpusers.com wrote: Hello, how to write in GIMP with greek letters? You can also use the unicode values for single letters by typing ctrlshiftuenter where is the hexadecimal value of the unicode character you wish to enter. The 'U' may be either upper or lower case, as may be the hex letters. For example to enter the formula for the area of a circle, πr² ctrlshiftu03c0enterrctrlshift00b2enter Wikipedia has a good table of unicode characters: https://en.wikipedia.org/wiki/List_of_Unicode_characters Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] recording changes
On 04/06/14 02:00, Alexandre Prokoudine wrote: On Sun, Apr 6, 2014 at 6:52 AM, Gary Aitken wrote: I'm frustrated by large storage requirements for xcf files resulting from processing many jpg image files. The processing is typically pretty simple, crop, curves, with no touch up. I don't mind the xcf size for images which required a lot of detail work, but it's crazy for the majority of them. Things which a raw processor encodes in a few KB turn into 60 MB; an 8x factor over the original file size. Are there any plugins, or is any work being done / planned, on some means to save (even a selected set of) operations so the result can be reconstructed from the original? It would save me many GB of space. We don't like it either, which is why it's planned for the future. Some foundation has already been laid for that in the code, but it will take time. As we are volunteers, not paid developers, we can't tell you, when this will be available for end-users. Thanks for the info, Alexandre. I understand the volunteer issue. I'm not complaining, just wanted to know what the current situation was. Was hoping it was in the pipe for a specific release. Thanks to the gimp team for all your work. Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Problem importing raw Minolta and Sony files
Can you provide an example image to confirm this? Sure. Let's use the clouds photo since it is a more modern Sony format and pretty dramatically shows the loss of information. Point your browser here: http://smallthoughts.com/photos/misc/GIMP/clouds.arw Looks like a normal image when opened here (fbsd, ufraw 0.19.2). Underexposed, but can be brought up to 1.49 w/out any overexposure blinkies. Clouds have lots of definition. WB (Camera WB) looks fine. A little *tiny* bit of purple fringing; I'd be delighted if all mine had that little. You don't have the color profile, gamma, and linearity set to something strange, do you? If I set to no profile, gamma=0.45, linearity 0.1 all looks good. ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
[Gimp-user] recording changes
I'm frustrated by large storage requirements for xcf files resulting from processing many jpg image files. The processing is typically pretty simple, crop, curves, with no touch up. I don't mind the xcf size for images which required a lot of detail work, but it's crazy for the majority of them. Things which a raw processor encodes in a few KB turn into 60 MB; an 8x factor over the original file size. Are there any plugins, or is any work being done / planned, on some means to save (even a selected set of) operations so the result can be reconstructed from the original? It would save me many GB of space. Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Problem importing raw Minolta and Sony files
On 04/04/14 20:43, Jeffery Small wrote: Ubuntu 13.10 system running on an Asus U56E system UFRaw ver. 0.19.2 Dcraw ver. 9.19.1 GIMP ver. 2.8.6 Darktable ver. 1.2.3 Shotwell ver. 0.15.0 I reported on this a long while ago and then got very busy with other things. This is a follow-up with details. When attempting to load Minolta (mrw) and Sony (arw) raw image files into GIMP, UFRaw is not properly processing them. The following webpage has images which demonstrate the problem: http://smallthoughts.com/photos/misc/GIMP/index.html The raw files are being imported with distorted color and contrast. However, as the additional images show, other programs such as Darktable and Shotwell are importing and displaying these files properly. Has anyone else been experiencing similar problems, and is there any known solution? This is kind of a shot in the dark. I don't know anything about shotwell, and not much about darktable. But I know darktable automatically applies an exposure correction curve to the raw file when it imports it, and ufraw does not (unless you set one as the default). You might look at the exposure correction curve darktable applies and see what it looks like when you apply a similar curve in ufraw. There may be other automagic things darktable does in regards to color; not sure. ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
[Gimp-user] flip / rotate a path?
Is there a way to flip / rotate a path the way you can a layer or image? I need to make a path and then generate a mirror image of it. ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] flip / rotate a path?
On 03/29/14 18:20, Simon Budig wrote: Gary Aitken (g...@dreamchaser.org) wrote: Is there a way to flip / rotate a path the way you can a layer or image? I need to make a path and then generate a mirror image of it. Switch the respective transform tool to path mode, make the relevant path visible and work with it... Ah, duh. Thanks! ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] flip / rotate a path?
On 03/29/14 18:18, akovia wrote: On Sat, Mar 29, 2014, at 07:48 PM, Gary Aitken wrote: Is there a way to flip / rotate a path the way you can a layer or image? I need to make a path and then generate a mirror image of it. You can use all the same tools but you have to tell it you are working with a path instead of a layer or selection in the tool options. These are the top 3 icons in the tool options beside the word Transform: It has Layer selected by default. Thanks. The only trick is if you want to transform just the path instead of the entire layer. To do so you must use the path to selection option before applying the transformation. That turns out not to be the case. If you select a path, then select the transform tool and select the path icon for what to Affect, it applies only to the selected path. You don't want to transform a path to a selection and then transform back because you can get a lot of additional points on the path. ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] color proofing / printing -- profiles not applied when printing? gutenprint plugin
On 01/31/14 05:05, uga...@talktalk.net wrote: You cannot actively colour manage a workflow unless you have colour calibrated your monitor. I understand that, and have that on my list of things to get done. Also, you do not say if you are printing to Epson Premium Glossy Photo Paper, nor do you say what profile/media settings you have selected in the printer driver. Epson premium glossy paper user, selected in the driver The default RGB space has to be something if colour management is active. true, but not necessarily used. However, it is unlikely yourdigital photographs will use this colour space. As far as my own images go, I'm starting from raw, so the color space is whatever I export with the image from ufraw. ProPhoto RGB, is a wide colour gamut, developed by Kodak. It much wider than sRGB and is also sometimes called ROMM RGB. Didn't realize at first that ROMM RGB was another name for ProPhoto; found that subsequently, thanks. What I don't understand is this: I have physical prints from cone color on Epson premium glossy photo paper, printed with conecolor k3 inks which were designed specifically to be a very close match for epson ultrachrome k3 inks. Regardless of what the image looks like on screen, if I import the image and keep its embedded profile, then print it using the appropriate profile for the printer + paper + ink, I should get an image that closely matches the professionally supplied one. I'm not; it's got too much yellow in the skin tones. In the gutenprint print dialog, under the Output tab, by default it has the following settings: Color Correction: Default Image Type:Mixed Text and Graphics I set Image Type to Photograph, but left Color Correction alone. If I set Color Correction to High Accuracy I see no difference. Gary -Original Message- From: Gary Aitken g...@dreamchaser.org To: gimp-user-list@gnome.org gimp-user-list@gnome.org Sent: Thu, 30 Jan 2014 21:22 Subject: [Gimp-user] color proofing / printing -- profiles not applied when printing? gutenprint plugin Hi all, I recently installed an epson 3880 and am trying to get decent color out of it. I'm relatively new at this and may have more than one thing wrong. At the moment I am using the outback photo printer evaluation image as a test, since it has rather large color bars and swatches to compare: http://outbackprint.outbackphoto.com/printinginsights/pi049/essay.html I have my Color Management preferences set as follows: Mode of operation: Color managed display RGB Profile:sRGB IEC61966-2.1 CMYK profile: None Monitor profile:NEW MultiSync LCD 1970NX Display rendering intent: Perceptual Print simulation profile: Epson Stylus Pro 3880_3890 PremiumGlossyPhotoPaper Softproof rendering intent: Perceptual Mark out of gamut colors File Open behaviour:Ask what to do The test image has an embedded profile, ProPhoto RGB, which I chose to keep when I loaded it in. It shows under Image/Image Properties/Color Profile as ProPhoto RGB Reference Output Medium Metric(ROMM). I don't know what the Reference Output Medium Metric means... With color management disabled in the display filters dialog (View/Display Filters/Color Display Filters) the image on-screen appears darker and less saturated, with reds too orange and blues too violet. With color management enabled the image looks bright and highly saturated, although the saturated green-yellow and green patches become difficult to distinguish. I suspect that is an out-of-gamut situation, but not sure. The photographic images in the test image become much brighter and saturated. If I also enable Color Proof, things get muted a bit, particularly in the test patches, although changes in the actual photographic images on-screen are much more subtle. Questions related to viewing on the display: Assuming the incoming image is correct with its attached color profile: 1. Checking only Color Management Is this the best / most accurate we can do on this display? 2. Checking only Color Proof What does this represent? Is it a rendering of the image mapped to RGB and then color-corrected for the printer, and therefore incorrect? Is any display color-correction included in this? 3. Checking both Color Management and Color Proof Is this the proper way to preview an image for printing? 4. This dialog is labelled Display Filters. I am assuming that means items selected here *only* affect how the display appears, and has nothing to do with printing. Correct? The images being printed appear similar to what I see on the screen with Color Management unchecked, and Color Proof unchecked: When printed, the most saturated reds appear dull and orangeish The image has three saturated greens, clearly distinguished in unmanaged mode
[Gimp-user] color proofing / printing -- profiles not applied when printing? gutenprint plugin
Hi all, I recently installed an epson 3880 and am trying to get decent color out of it. I'm relatively new at this and may have more than one thing wrong. At the moment I am using the outback photo printer evaluation image as a test, since it has rather large color bars and swatches to compare: http://outbackprint.outbackphoto.com/printinginsights/pi049/essay.html I have my Color Management preferences set as follows: Mode of operation: Color managed display RGB Profile:sRGB IEC61966-2.1 CMYK profile: None Monitor profile:NEW MultiSync LCD 1970NX Display rendering intent: Perceptual Print simulation profile: Epson Stylus Pro 3880_3890 PremiumGlossyPhotoPaper Softproof rendering intent: Perceptual Mark out of gamut colors File Open behaviour:Ask what to do The test image has an embedded profile, ProPhoto RGB, which I chose to keep when I loaded it in. It shows under Image/Image Properties/Color Profile as ProPhoto RGB Reference Output Medium Metric(ROMM). I don't know what the Reference Output Medium Metric means... With color management disabled in the display filters dialog (View/Display Filters/Color Display Filters) the image on-screen appears darker and less saturated, with reds too orange and blues too violet. With color management enabled the image looks bright and highly saturated, although the saturated green-yellow and green patches become difficult to distinguish. I suspect that is an out-of-gamut situation, but not sure. The photographic images in the test image become much brighter and saturated. If I also enable Color Proof, things get muted a bit, particularly in the test patches, although changes in the actual photographic images on-screen are much more subtle. Questions related to viewing on the display: Assuming the incoming image is correct with its attached color profile: 1. Checking only Color Management Is this the best / most accurate we can do on this display? 2. Checking only Color Proof What does this represent? Is it a rendering of the image mapped to RGB and then color-corrected for the printer, and therefore incorrect? Is any display color-correction included in this? 3. Checking both Color Management and Color Proof Is this the proper way to preview an image for printing? 4. This dialog is labelled Display Filters. I am assuming that means items selected here *only* affect how the display appears, and has nothing to do with printing. Correct? The images being printed appear similar to what I see on the screen with Color Management unchecked, and Color Proof unchecked: When printed, the most saturated reds appear dull and orangeish The image has three saturated greens, clearly distinguished in unmanaged mode on-screen, but with two of them difficult to distinguish in managed mode on-screen. The prints have the clearly distinguishable green pattern seen in the unmanaged image on-screen. In unmanaged mode on-screen, the blues tend towards violet, which is what they do when printed. CMY are all less saturated unmanaged on-screen, and printed. In the gutenprint plugin, the printer command being issued is lp -s -d 'Epson_Stylus_Pro_3880' -oraw I also have the test image from Cone Color http://shopping.netsuite.com/c.362672/site/test-image.zip and the two test prints they supply which are supposed to be color-corrected and should match epson inks very closely. If I use the Cone Color test image and compare the output to the sample cone-color k3 ink sample, there is clearly too much yellow in the skin-tones. Any help / hints would be greatly appreciated. Thanks, Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Is it possible to set the max brush pen slider values
On 01/30/14 13:31, Paul Read wrote: The sliders are nearly useless for me as I typically use pens and brush sizes of 1,5, 10 and 20. I need to change the size regularly and the sliders would be ideal yet my 'working' range is in a tiny little bit at the end of the slider value. It would be a huge gain for me to some how set the max slider value to a value of my choice (say 50) rather than the current value of 1000 Is it possible? If not can I make a feature request (and if so how) There is already a feature request filed for this: https://bugzilla.gnome.org/show_bug.cgi?id=689731 Also see the following old post related to the subject: https://mail.gnome.org/archives/gimp-user-list/2012-December/msg00055.html ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
[Gimp-user] epson printer, gutenprint, and *nix
Hi all, The epson Stylus Pro 3880 (and maybe others) comes as a standard model, and it's another $200 in the US for a postscript-enabled model. If one is using CUPS for printing, it appears the drivers don't actually use postscript. Is this the case, and is there any reason to get a ps-enabled model? ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
[Gimp-user] layer positioning
Hi folks, Either I am blind or incompetent, maybe both... a hint would be much appreciated: I wanted to set up a template for dealing with printing four images on a sheet. I created an image the size of the sheet and then added four layers, each of the desired image size which needed to be positioned appropriately. When I went to position the images, I could not find any reasonable way with the move command or with any of the layer operations to position each layer precisely. By that I mean simply type in the coordinates of the upper left corner, or move with the mouse where I see a text version of the upper left coordinate of the new layer position as I move. If trying to position using the mouse, the lower left of the status line shows the position of the pointer itself, so that is useless in positioning the layer as a whole; and the numbers to the right of the per-cent size display show how much the layer has moved relative to its starting position, not the absolute position of the upper left corner. (I'll grant that the latter is useful, but in this case one needs something else, particularly if a layer has been moved and needs to be repositioned to a fixed location.) The only way I could get what I wanted was to expand to 800%, and at that magnification I could grab the upper left corner with the mouse so the mouse position was itself the upper left corner position. Surely there's a better way? Layer/Layer to Boundary Size... does not appear to work as advertised. The offset appears to be relative to the original size of the layer, not the original size of the image. The panner image is limited to the size of the layer, not the image. When you first bring up the dialog, you are unable to reposition the layer unless you change the layer size to make the layer smaller. If you make the layer half the size of its original size and then click Center, the offset is set to - 1/2 the size of the original image, not + 1/2, which seems bizarre. The layer is scaled properly, and ends up where you would expect (based on the center command given, but not based on the offsets indicated), but the values in the Offset boxes seem to have the wrong sign. It works by moving the original layer relative to the desired new layer, rather than position the new layer size relative to the image. Which means you can't move the layer relative to the image if the layer is smaller than the image, and the graphic panner doesn't show you the layer position relative to the image as a whole. It is not at all intuitive and is not useful for quite a few common cases. Layer/Transform/Offset shifts the contents, but not the layer itself. Which is what it is supposed to do, so that's ok; it's just not usable for this operation. Thanks for any clues, Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] layer positioning
On 01/02/14 17:48, Joao S. O. Bueno wrote: Ok- that was unfair of me - it is actually easy to do this with the align tool once one grasps one or two concepts of its operation. Took me less than 2 minutes. a) select the align tool on the toolbox. b) click on one of your layers c) Verify that alginement is related to image in the tool options d) click on the left arrow and on the up arrow, in the upper halff of the tool options dialog to have it positioned at the upper left corner of the canvas e) repeat b - d 3 more times for the other layers, replacing the arrow buttons as desired This would be great, but... I must be missing something; running 2.8.10 on fbsd. When I click on the alignment buttons, nothing happens, and they don't change appearance on mouse-down or mouse-up. I can't quite tell from the glyphs, but they look like they may be greyed out; at least they are overall a lot lighter than most of the toolbox glyphs; they look about like the bucket-fill tool. The Offset text box is active and allows changes, and the reset options does its thing. No error messages that I can see. Any ideas what would cause them to be inactive? All other tools seem to work. On 2 January 2014 21:38, Gary Aitken g...@dreamchaser.org wrote: Hi folks, Either I am blind or incompetent, maybe both... a hint would be much appreciated: I wanted to set up a template for dealing with printing four images on a sheet. I created an image the size of the sheet and then added four layers, each of the desired image size which needed to be positioned appropriately. When I went to position the images, I could not find any reasonable way with the move command or with any of the layer operations to position each layer precisely. By that I mean simply type in the coordinates of the upper left corner, or move with the mouse where I see a text version of the upper left coordinate of the new layer position as I move. If trying to position using the mouse, the lower left of the status line shows the position of the pointer itself, so that is useless in positioning the layer as a whole; and the numbers to the right of the per-cent size display show how much the layer has moved relative to its starting position, not the absolute position of the upper left corner. (I'll grant that the latter is useful, but in this case one needs something else, particularly if a layer has been moved and needs to be repositioned to a fixed location.) The only way I could get what I wanted was to expand to 800%, and at that magnification I could grab the upper left corner with the mouse so the mouse position was itself the upper left corner position. Surely there's a better way? Layer/Layer to Boundary Size... does not appear to work as advertised. The offset appears to be relative to the original size of the layer, not the original size of the image. The panner image is limited to the size of the layer, not the image. When you first bring up the dialog, you are unable to reposition the layer unless you change the layer size to make the layer smaller. If you make the layer half the size of its original size and then click Center, the offset is set to - 1/2 the size of the original image, not + 1/2, which seems bizarre. The layer is scaled properly, and ends up where you would expect (based on the center command given, but not based on the offsets indicated), but the values in the Offset boxes seem to have the wrong sign. It works by moving the original layer relative to the desired new layer, rather than position the new layer size relative to the image. Which means you can't move the layer relative to the image if the layer is smaller than the image, and the graphic panner doesn't show you the layer position relative to the image as a whole. It is not at all intuitive and is not useful for quite a few common cases. Layer/Transform/Offset shifts the contents, but not the layer itself. Which is what it is supposed to do, so that's ok; it's just not usable for this operation. ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
[Gimp-user] gutenprint interface
I'm having trouble getting gutenprint w/cups to work on freebsd; gutenprint works fine from a browser, but not from the gimp when I use Print with Gutenprint The dialog comes up, and if I select the lpr device, it appears to send the output to the lp/lpr device unfiltered; but if I select the printer added in cups, I see no output and no errors in the error log, and the printer doesn't even wake up. I think it may not be finding the device, which is not listed in /etc/printcap, and I don't believe needs to be, as it works from firefox. When the dialog pops up there is a process running for gutenprint: /usr/local/libexec/gimp/2.2/plug-ins/gutenprint -gimp 24 18 -run 0 Any thoughts / hints on how to debug this? Thanks, Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] Tool Options alternative
On 12/06/13 01:43, scl wrote: On 6.12.2013 at 9:30 AM josephbupe wrote: My question is about the Tool Options which currently consume alot of space, whether docked under the Tool box, side-by-side, left or right of the working space. Could you consider a horizontal Tool Options above the Tool box with a possibility of the user to switch to either the native Tool Options verticle arrangement or a horizontal arrangement? Hi josephbupe, there were already considerations to improve the tool handling, but thank you much for your proposal. The following reading might be interesting for you: - UI wiki article 'Rethinking GIMP tool options': http://gui.gimp.org/index.php/Rethinking_GIMP_Tool_Options - The GIMP UI brainstorm, especially on the Tool Options: http://gimp-brainstorm.blogspot.de/search/label/tool%20options In most cases image editing monitors use landscape orientation. Thus vertical screen space is more precious than horizontal space. This could get less important if we manage to allow GIMP for the getting-more-important tablet computers, but this is another story. Every pixel counts. A solution should take this into account. Kind regards, Sven Thanks for posting the links. Some observations from my usage perspective: An ability to pop up the options for the current tool over the image would be useful. I find it cumbersome to constantly move the mouse back and forth between the image and the toolbox when switching tools or tweaking options. One possibility would be some kind of modulated popup, where a modifier key pops up the toolbox under the pointer and holds it there until the key is released. Another modifier key could pop up only the options for the current tool until released. The advantages of this is that it minimizes having to mouse around to bring up and dismiss the dialog, and the pointer stays over the focus of work. I think this comes under the peripheral vs. central paragraph in the Rethinking GIMP Tool Options blurb. I know there are a limited number of modifier keys, and all are taken in the default configuration; however it is possible to configure otherwise. Alternately, one could map a particular shortcut for the purpose and have it bound to all visible gimp windows including the image windows. It would require two keystrokes, but still work pretty well. An advantage of the shortcut approach is that it makes typing into dialog fields easier, instead of just mouse interactions (It's kinda awkward to type while holding down a modifier key, and the modifier has to be ignored internally). If this is already possible, I would (almost) kill to get someone to give me a hint for how to configure it. A related issue is that switching layers, paths, and channels (or any other dockable dialog, although I find it particularly a problem with those three) changes the focus so that normal tool selection shortcuts no longer work. That's understandable given the need to type into some of the dialogs, but despite years of working with it (albeit not in any particular expert capacity), I am still constantly screwing up by hitting a shortcut and doing something crazy or not knowing at all what I have just done and wondering why the desired action is not happening because the focus was still on the layers / paths / channel dialog. I don't have a suggestion for how to overcome this, but it is worth thinking about if it is a common problem. Is it possible to bind a shortcut for all gimp windows to mean return focus to the last image window? At the moment I accomplish this using my window manager's process switch (e.g. ctl-alt-tab), but that is somewhat awkward because depending on what you've been doing the image window may not be the immediately previous one. While I concede that vertical screen space is often more important than horizontal space when considering the whole image, this is not always the case for any particular task or image. It would be great if the toolbox and the tool options (Maybe all dialogs since a general implementation is usually to be preferred) could be docked under the image window toolbar. This would be particularly useful if it were possible to somehow specify or turn on shifting the tool options to a horizontal toolbar in the image window when going to full-screen mode, although it would be unnecessary if the modulated pop-up idea above were implemented. Aside: One thing which slows down my use is the ordering of options for some of the tools. I assume they are optimized in a reasonable default manner. However, each particular user's activity patterns, skill and knowledge level gives their own relative importance to the different options. It would be great if it were possible to reorder the layout. For example, I find it frustrating to have to scroll down to check the hard edge option for erase; my personal usage pattern would move that higher up so I don't have to scroll. Gary
[Gimp-user] modifying tool options
The help page for toolbox shortcuts indicates there should be a Context menu at the top of the shortcut editor for modifying the tool parameters. Am I blind, or is it not there? Thanks, Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] Editing Photos and Maintaining Exif Information
On 11/10/13 08:14, Rainer Dorsch wrote: Hello, I usually use digikam for managing my photos collection and gimp to improve some photos. In the past I simply saved under a different name and I had the orignal and the improved image in my digikam collection next to each other. Now digikam moves the improved photo to the end of the collection. digikam thinks that Time and Date of the photo changed. exiv2 is also not happy with the modified IMG_0243b.JPG Has anybody an idea, what is going wrong now? Try using exiv2 -u -p a There are a number of different timestamps, including: Exif.Image.DateTime Ascii 20 2010:09:11 20:12:47 Exif.Photo.DateTimeOriginal Ascii 20 2010:09:08 14:14:47 Exif.Photo.DateTimeDigitized Ascii 20 2010:09:08 14:14:47 exiv2 without arguments prints Exif.Photo.DateTimeOriginal (I think that's the one it uses) as the reported Image timestamp Exif.Image.DateTime is the more correct date for when the image itself was generated. Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] Can't save bug?
On 11/03/13 17:53, Ian H wrote: I recently encountered a very frustrating situation and am wondering if it's a bug or feature. I was working on an image, it was quite big, 7000 px wide, 6000 tall but only 5 quite simple layers, the .xcf is 7.8MB. All of a sudden after pasting from another .xcf file (which I had just 10+ times with no similar result) I moved the pasted part, the image was pretty much finished and I went up to click fileexport and everything between open recent and quit in the file menu was grey. No chance to save or export and it appears half an hour of work lost. It was as if the file menu didn't think I had a file open, but if I scrolled accross to the filters menu for example, they were available for selection which they are not when you have no image open. I could edit the image and change layer visibilities and do what I wanted to the image - except save it. I had flash backs to darker days of shareware version of lesser softer titles on proprietary systems. In a moment of frustration I hit the little x to resign for the night and it warned me to save before closing.. I hit save as the only option was to overwrite a file I didn;t really want to overwrite but I did and then wrote this. Any ideas? It's 2.8.6 running on an up to date ubuntu 13.10 on a high end PC. To at least save the work and preserve the original, rename the original .xcf file outside of gimp, then do the save before quitting. I am running 2.8.6 on fbsd and have never seen this. I have images a lot larger than that (41,000 x 3,000 px) and have had no problem other than running out of temp file space. In that case, the gimp warned me and I reconfigured; so I don't think it is related to the image size. Were there any error messages in the console display? I don't know under what circumstances the items under the file menu are greyed out other than no image; even if the image is read-only they are still active, so it's a total mystery to me. It does sound like it somehow got its head wedged thinking no file was open. I presume you can't reproduce the problem? Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] using GIMP jpegs in OpenOffice Writer - error
On 09/04/13 06:00, Uniklaps wrote: Win 7 64 bit RAM 16 GB GIMP 2.8.4 Hi friends, with GIMP I create maps using a WACOM tablet. I save the data as xcf, additional using the export option as jpg and tif. These files Jpg and tif are for further use. If I try to insert one of these jpgs, OpenOffice Writer (3.4.1) show an error report graphic filter not found (translated from german) If I open the GIMP jpg with Photoshop elements and save it again as jpg either overwriting the old file from GIMP-export or creating a new file (copy) , OO Writer shows the same error-report; same reaction with the GIMP tif. But if I open the GIMP jpg or GIMP tif with PhotoLine (V 17.11; Shareware; demo free www.pl32.de) and save it again als jpg (highest qualitiy) then OO Writer insert this picture. Is this behaviour caused by GIMP or OO Writer or are both guilty or is this a bug ? Is there a way to persuade GIMP to export a readable jpg ?? Thanks for all your help! Hi Konrad, I am using OO 3.4.1 on FreeBSD and GIMP 2.8.6. I have no trouble inserting .jpg files output from gimp into OO Writer. I also had no trouble when using OO 3.3.x. How big are these files, and is there any chance you are simply running over some memory / address space limits? I know once upon a time there were issues of this sort in windows environments when the 4G limit was reached. Since you are running windows, is the OO you are running a 32 bit version, and not able to make use of the whole address space? What happens if you use smaller images, or export using a lower quality jpg? Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] bit of a n00b question but...
On 09/02/13 00:10, JjStAr wrote: I'm stuck. Python plugins are not installing. They don't show up. Script-Fu works fine though. Can anyone help me? I don't know squat about Python, unfortunately. However, I just tried starting the python console on my system (freebsd) and it didn't show up. As I was starting it from an icon on the desktop, I know from past experience that errors often get swallowed when an app is started in this manner. So I started it from a shell window and saw the related errors. so... Try starting the gimp from a shell window instead of the normal app launch method. Are there any errors? Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] Question about bump map location
) ; Relative height (per cent) of watermark to original image ; Opacity of watermark (define (add-watermark orgImg drw watermarkFileName relHt opacity) ; (display \nadd-watermark\n) ; (display (string-append fileName=\ fileName \\n)) ; (display (string-append watermarkFileName=\ watermarkFileName \\n)) ; (display (string-append relHt=\ (number-string relHt) \\n)) ; (display (string-append opacity=\ (number-string opacity) \\n)) (let* ( ; (orgImg 0); original image (watermarkImg 0) ; watermark image (layer 0) ; the layer to manipulate ; (multiplier (/ opacity 100)) ; opacity as a decimal multiplier (xOff (car (gimp-image-width orgImg))); x offset for added watermark (yOff (car (gimp-image-height orgImg))) ; y offset for added watermark ) ; open the image and the watermark ;(set! orgImg (car (file-tiff-load RUN-NONINTERACTIVE fileName fileName))) ; load the original image (set! watermarkImg (car (file-png-load RUN-NONINTERACTIVE watermarkFileName watermarkFileName))) ; load the watermark image ; establish relative height for added image (if (equal? relHt ) (set! relHt 2) ) (gimp-context-push) (gimp-image-undo-group-start orgImg) ; scale the watermark image ; (display watermarkImg:) (print watermarkImg) ; (display (string-append ht: (number-string (car (gimp-image-height watermarkImg))) \n)) (scale-relative watermarkImg orgImg relHt) ; (display (string-append ht: (number-string (car (gimp-image-height watermarkImg))) \n)) ; set the opacity of the scaled image ; Note! 0 = opacity = 100, NOT 0 = opacity = 1 as noted in the function definition (set! layer (car (gimp-image-get-active-layer watermarkImg))) ; get the layer (drawable) to modify ; (display layers:) (print layer) ; (display (string-append multiplier: (number-string multiplier) \n)) (gimp-layer-set-opacity layer opacity) ; add the scaled image to the main image (set! layer (car (gimp-layer-new-from-drawable layer orgImg))) ; (display layer:) (print layer) (gimp-image-insert-layer orgImg layer 0 0) (gimp-layer-set-name layer Copyright) ; position the scaled image in the lower right corner of the main image ; (display (string-append xOff: (number-string xOff))) (set! xOff (- xOff (car (gimp-drawable-width layer ; (display (string-append xOff: (number-string xOff))) (set! yOff (- yOff (car (gimp-drawable-height layer ; (display (string-append yOff: (number-string yOff))) (gimp-layer-set-offsets layer xOff yOff); (gimp-image-delete watermarkImg); get rid of the original watermark image (gimp-image-undo-group-end orgImg) (gimp-displays-flush) (gimp-context-pop) ; Need to save the modified image ;(gimp-image-delete orgImg) ; get rid of the original image ) ) ; Register add-watermark ; NOTE!!! The script-fu browser will show an additional argument, SF-MODE, which it automatically ; adds and removes in some crazy way. ; It appears to only be of significance when calling a non-script-fu procedure from a script-fu, ; or vice-versa, and its purpose is to indicate whether or not the argument dialog box should be displayed. ; So basically, for my purposes, it is of no significance whatsoever. ; SF-MODE ModeRUN-INTERACTIVE; First arg is run mode ; NOTE!!! It also appears there is no way to use this procedure both interactively and non-interactively, ; because of the need to specify the name of the input file for non-interactive use. ; So note the additional procedure, batch-add-watermark (script-fu-register add-watermark ; function name Add Watermark... ; menu label Adds a scaled, partially transparent image to an image Gary Aitken ; author Copyright 2013, Gary Aitken ; copyright notice 2013-08-28 v 0.1 ; date created ; image type the script works on SF-IMAGEImage 0 ; image to which watermark will be added SF-DRAWABLE Drawable 0; unused SF-STRING Added image file/home/garya/Photos/Copyright.png ; file containing image to add ; SF-VALUE Relative (percent) height of added image5 ; height of scaled image as a percent of main image height SF-ADJUSTMENT Relative (percent) height of added image'(3 1 100 1 10 1 0) ; height of scaled image as a percent of main image height SF-ADJUSTMENT Opacity of added image'(50 1 100 1 10 1 0) ; Opacity of scaled image ) ; Image/garya puts a top level menu item of garya on the menu bar for the image window (script-fu-menu
Re: [Gimp-user] Question about bump map location
) ; Relative height (per cent) of watermark to original image ; Opacity of watermark (define (add-watermark orgImg drw watermarkFileName relHt opacity) ; (display \nadd-watermark\n) ; (display (string-append fileName=\ fileName \\n)) ; (display (string-append watermarkFileName=\ watermarkFileName \\n)) ; (display (string-append relHt=\ (number-string relHt) \\n)) ; (display (string-append opacity=\ (number-string opacity) \\n)) (let* ( ; (orgImg 0); original image (watermarkImg 0) ; watermark image (layer 0) ; the layer to manipulate ; (multiplier (/ opacity 100)) ; opacity as a decimal multiplier (xOff (car (gimp-image-width orgImg))); x offset for added watermark (yOff (car (gimp-image-height orgImg))) ; y offset for added watermark ) ; open the image and the watermark ;(set! orgImg (car (file-tiff-load RUN-NONINTERACTIVE fileName fileName))) ; load the original image (set! watermarkImg (car (file-png-load RUN-NONINTERACTIVE watermarkFileName watermarkFileName))) ; load the watermark image ; establish relative height for added image (if (equal? relHt ) (set! relHt 2) ) (gimp-context-push) (gimp-image-undo-group-start orgImg) ; scale the watermark image ; (display watermarkImg:) (print watermarkImg) ; (display (string-append ht: (number-string (car (gimp-image-height watermarkImg))) \n)) (scale-relative watermarkImg orgImg relHt) ; (display (string-append ht: (number-string (car (gimp-image-height watermarkImg))) \n)) ; set the opacity of the scaled image ; Note! 0 = opacity = 100, NOT 0 = opacity = 1 as noted in the function definition (set! layer (car (gimp-image-get-active-layer watermarkImg))) ; get the layer (drawable) to modify ; (display layers:) (print layer) ; (display (string-append multiplier: (number-string multiplier) \n)) (gimp-layer-set-opacity layer opacity) ; add the scaled image to the main image (set! layer (car (gimp-layer-new-from-drawable layer orgImg))) ; (display layer:) (print layer) (gimp-image-insert-layer orgImg layer 0 0) (gimp-layer-set-name layer Copyright) ; position the scaled image in the lower right corner of the main image ; (display (string-append xOff: (number-string xOff))) (set! xOff (- xOff (car (gimp-drawable-width layer ; (display (string-append xOff: (number-string xOff))) (set! yOff (- yOff (car (gimp-drawable-height layer ; (display (string-append yOff: (number-string yOff))) (gimp-layer-set-offsets layer xOff yOff); (gimp-image-delete watermarkImg); get rid of the original watermark image (gimp-image-undo-group-end orgImg) (gimp-displays-flush) (gimp-context-pop) ; Need to save the modified image ;(gimp-image-delete orgImg) ; get rid of the original image ) ) ; Register add-watermark ; NOTE!!! The script-fu browser will show an additional argument, SF-MODE, which it automatically ; adds and removes in some crazy way. ; It appears to only be of significance when calling a non-script-fu procedure from a script-fu, ; or vice-versa, and its purpose is to indicate whether or not the argument dialog box should be displayed. ; So basically, for my purposes, it is of no significance whatsoever. ; SF-MODE ModeRUN-INTERACTIVE; First arg is run mode ; NOTE!!! It also appears there is no way to use this procedure both interactively and non-interactively, ; because of the need to specify the name of the input file for non-interactive use. ; So note the additional procedure, batch-add-watermark (script-fu-register add-watermark ; function name Add Watermark... ; menu label Adds a scaled, partially transparent image to an image Gary Aitken ; author Copyright 2013, Gary Aitken ; copyright notice 2013-08-28 v 0.1 ; date created ; image type the script works on SF-IMAGEImage 0 ; image to which watermark will be added SF-DRAWABLE Drawable 0; unused SF-STRING Added image file/home/garya/Photos/Copyright.png ; file containing image to add ; SF-VALUE Relative (percent) height of added image5 ; height of scaled image as a percent of main image height SF-ADJUSTMENT Relative (percent) height of added image'(3 1 100 1 10 1 0) ; height of scaled image as a percent of main image height SF-ADJUSTMENT Opacity of added image'(50 1 100 1 10 1 0) ; Opacity of scaled image ) ; Image/garya puts a top level menu item of garya on the menu bar for the image window (script-fu-menu
Re: [Gimp-user] Layer Opacity Access Point(s) Madness
That was pretty difficult to get a handle on. Is this what you're looking for: Windows/Dockable Dialogs/Layers (ctlL) 2nd thing down is an Opacity slider. Are you looking for a way to select a specific layer and operate on it using the Opacity slider via the keyboard? Or just find the slider in the first place? Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
[Gimp-user] dump defaults
Assuming one starts gimp with no user-specific gimprc, is there a way to dump out all the default values? I'm asking because the default gimprc has everything commented out, and there's no GIMP2_DIRECTORY or gimp_dir defined in my environment. Thanks, Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] dump defaults
On 09/01/13 16:12, Michael Natterer wrote:
On Sun, 2013-09-01 at 14:57 -0600, Gary Aitken wrote:
Assuming one starts gimp with no user-specific gimprc,
is there a way to dump out all the default values?
gimp --dump-gimprc
ok that yields
(temp-path ${gimp_dir}/tmp)
(swap-path ${gimp_dir})
I'm asking because the default gimprc has everything commented out,
and there's no GIMP2_DIRECTORY or gimp_dir defined in my environment.
The default directories depend on the platform, and/or on the
compile time prefix. You should use gimptool to figure these,
the internal logic used is the same. Try gimptool --help.
I don't see anything there that indicates it is gimp_dir,
and none of the values are the ones set by default, which in my case
is ~/.gimp-2.8. All of the directory options are for source info
(such as libdir, prefix, execprefix, mandir, etc., and all of the
values are in non-user-writeable directories.
My system-wide (freebsd) default gimprc, /usr/local/etc/gimp/2.2/gimprc,
has the following (commented-out) lines:
(temp-path ${gimp_dir}/tmp)
(swap-path ${gimp_dir})
If I look at Preferences/Folders, I see
Temporary folder: tmp
Swap folder: .gimp-2.8
If I open a 10,000 x 3,000 .xcf which is 128MB, with the tile cache size set to
16MB, I see a new file ~/.gimp-2.8/gimpswap.6637, and nothing in ~/tmp. I
don't know what will cause something to be written to temp space, but
apparently gimp_dir is set to ~/.gimp-2.8 by default on fbsd. It is
particularly confusing because the tmp entry, when seen in the UI, *looks*,
because of the missing prefix path components, like it would be /tmp or ~/tmp,
but in fact is not.
Thanks for the pointers.
Gary
___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
[Gimp-user] reconciling script-fu interactive and batch arguments
I have never learned / figured out / been pointed at an example for how to properly write a script which is usable in both interactive and batch modes. Let's say I have a script-fu add-on: (define (add-watermark orgImg drw watermarkFileName relHt opacity) ... ) (script-fu-register add-watermark Add Watermark... Adds a scaled, partially transparent image to an image Gary Aitken Copyright 2013, Gary Aitken 2013-08-28 v 0.1 ; SF-MODE ModeRUN-INTERACTIVE ; First arg is run mode ; SF-STRING Main image file ; name of main image to modify SF-IMAGE Image 0 ; main image to modify SF-DRAWABLE Drawable 0 ; unused SF-STRINGAdded image file myfile.png SF-VALUE Relative (percent) height of added image 5 SF-VALUE Opacity of added image 50 ) As written above, with the SF-MODEModeRUN-INTERACTIVE SF-STRING Main image file arguments commented out, this script works in interactive mode, operating on the active drawable in the active image; the first two arguments to the function (orgImg and drw) are filled in automagically by the gimp when the script is activated. The only way I have figured out how to use this from batch mode is to add another script which contains the name of the base file to process: (define (batch-add-watermark inFileName watermarkFileName outFileName relHt opacity) (let* ( (orgImg (car (gimp-file-load RUN-NONINTERACTIVE inFileName inFileName))) (drw (car (gimp-image-get-active-layer orgImg))) ) (add-watermark orgImg drw watermarkFileName relHt opacity) (gimp-file-save RUN-NONINTERACTIVE orgImg drw outFileName outFileName) (gimp-image-delete orgImg) ) ) This works, but neither procedure is making any use of what should be the first argument (missing from add-watermark above but present in batch-add-watermark) which is the mode. My gut says the mode is there to make this all much easier, but I can't figure it out. Can someone give me a proper explanation of how to do this, or point me at something? Thanks, Gary ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] Unskewing images of flat rectangular objects in Gimp
On 02/04/13 11:19, Steve Kinney wrote: On 02/04/2013 03:46 AM, Elmer Wix wrote: Øyvind Kolås pip...@gimp.org wrote: [...] The perspective tool has an inverse mode, if you align the grid lines from the wireframe preview with the lines desired to become horizontal/vertical and then do the transform you should end up with a rectified version of the quadliteral. Thanks! That worked. The size and aspect ratio of the rectified quadrilateral isn't always close to what I want it to be, though. Is there a way to specify this before I do the perspective transform, or do I just need to do it in 2 steps (correct perspective, and then re-size)? I has a well DUH! moment over this because I never noticed the function, so I started tinkering around with it. If there is a rectangular selection on the canvas, the area selected by the perspective tool conforms to the selection when resampled. The tool options dialog dock for Rectangular Select has settings for adjusting the size and position of the selection in pixels. I can't believe the amount of time I have wasted squaring up photographed or scanned rectangular objects by hand. But I love it when posters like Øyvind point out things that should have been obvious to me - better to learn late than never! Thank you! I've been wondering how to do that for a *long* time. ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] I'm finding it hard to work with brush sizes in 2.8
On 02/01/13 12:27, Matthew Miller wrote: On Fri, Feb 01, 2013 at 08:55:55PM +0200, Ville Sokk wrote: The new dialog devotes the left 5% of the slider to this range. I know there was some talk about changing this slider to be logarithmic. Is there any progress on that? I don't know if you noticed but the slider has a top and bottom part. The cursor changes when you hover. The top part is used for large changes and the bottom for fine tuning. Yeah, but with it so small, I get large changes as effectively random numbers of 1.0, 7.24, 13.49, 19.73, 25.98, 32.22, 38.46, depending on which of those six pixels I hit. More often I'm getting 88 or 200 or 400 or something first. The fine tuning lets me adjust increments from there, but is only really useful if I hit the right number first, and it's hard to scale *down* because my mouse hits the right side of the screen. (Better if I don't maximize the window, but that's silly.) The best approach I've found is to use a brush with a native size of around 5, and then aways start by hitting the reset size button and adjusting up from there using the fine-tuning. That's pretty silly but is less frustrating than the alternative. This is exactly why the enhancement I proposed some time ago would be helpful: https://mail.gnome.org/archives/gimp-user-list/2012-December/msg00055.html ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] Doing a select without the mouse?
On 01/23/13 20:18, Steve Kinney wrote: On 01/23/2013 07:36 PM, Gary Aitken wrote: Hitting enter in the image window has no effect whatsoever when the rectangle tool is active. At least in my 2.8.2 version. Ditto here. I tried it and was surprised that I could not figure out a way to make the rectangular select tool options draw a rectangular selection - it moves and resizes them all day long but only if one already exists on the canvas - as far as I can tell. For me this is not a problem but it is kind of puzzling. I now see how to use it, although it is awkward. But at least I can get the exact location and size I want: 1. Click in the image and drag out any rectangular selection 2. Change focus back to the tool options and set the origin and size 3. Change focus back to the image and hit enter Gary ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] Doing a select without the mouse?
On 01/23/13 02:14, Ofnuts wrote: On 01/23/2013 05:00 AM, Gary Aitken wrote: Is it possible to do a rectangle select without the mouse? For example, with the rectangle tool selected, one can fill in the fields in the tool options to specify the coordinates and size of the rectangle, but I can't see a way to actually commit the operation; What operation? Until you click/drag on the image, there is no selection started, and the numbers you enter in the Tools options are meaningless. To give them a purpose you have to click first, which means using the mouse. If the values are meaningless, then why do they appear in the Tool Options for the rectangle select? Clicking and dragging sets the values for Position and Size in the Tool Options. These are not read-only entries; they may be set via the keyboard. If one can set them via the keyboard, it should be possible to have them take effect after entering them. They should either be read only, or should have a corresponding Select button which can be activated. ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] Doing a select without the mouse?
On 01/23/13 07:46, Olivier wrote: 2013/1/23 Gary Aitken g...@dreamchaser.org: On 01/23/13 02:14, Ofnuts wrote: On 01/23/2013 05:00 AM, Gary Aitken wrote: Is it possible to do a rectangle select without the mouse? For example, with the rectangle tool selected, one can fill in the fields in the tool options to specify the coordinates and size of the rectangle, but I can't see a way to actually commit the operation; What operation? Until you click/drag on the image, there is no selection started, and the numbers you enter in the Tools options are meaningless. To give them a purpose you have to click first, which means using the mouse. If the values are meaningless, then why do they appear in the Tool Options for the rectangle select? Clicking and dragging sets the values for Position and Size in the Tool Options. These are not read-only entries; they may be set via the keyboard. If one can set them via the keyboard, it should be possible to have them take effect after entering them. They should either be read only, or should have a corresponding Select button which can be activated. To complete the selection, press Enter in the image window. Hitting enter in the image window has no effect whatsoever when the rectangle tool is active. At least in my 2.8.2 version. I tried the following: Get focus to image window ^R to activate rectangle tool Shift focus to Rectangle Select tool options dialog (wm key sequence + tabs or mouse click) Set position to 10,10 Set size to 50 x 100 Shift focus to image window (wm key sequence or mouse click) Hit enter nothing happens Can you give me a sequence where it does work? Thanks, Gary ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] layers, new problem with old methods
On 01/22/13 07:59, Richard Gitschlag wrote: Floats belong to whatever layer or mask was current when the clipboard content was pasted in. You can only do two things with a float: Make it a new layer by using the 'add layer' command, or use the 'anchor' command to merge it down into whatever layer or mask was already selected when the float was pasted into the image. That is correct, but because the Layers dialog displays the float at the top of the entire layer stack there is no visual indication in the dialog of which layer it belongs to. If we merely changed the display of the dialog so that the float is always displayed just above its source layer (actual functionality unaffected), this would make it more intuitive to the user. While voting doesn't count ;-), I would second that as a suggestion. I've meant to make the same comment before. Gary ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
[Gimp-user] Doing a select without the mouse?
Is it possible to do a rectangle select without the mouse? For example, with the rectangle tool selected, one can fill in the fields in the tool options to specify the coordinates and size of the rectangle, but I can't see a way to actually commit the operation; I don't see a do it button at the bottom, or an option in the tool options menu. I'm looking to get a precisely sized selection to fill into an added space. For example, when adding a strip at the top of an image, I would like to grab the top 100 pixels, flip it vertically to create a mirror image, and paste it into the expanded canvas. Am I missing something? Thanks, Gary ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
[Gimp-user] Grid lines are 10x10, not default set in preferences
My Preferences / Default Grid says the grid spacing is 48 pixels for both width and height. Yet when I choose View / Show Grid I get lines spaced on 10 x 10 intervals. What am I missing? Thanks, Gary ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] Cannot Add New Text (confirm text editing)
On 01/03/13 12:57, latinojuan wrote: Hello, I am clicking on a layer in GIMP, and when I click on the text tool, this dialog pops up CONFIRM TEXT EDITING the layer you selected is a text layer but it has been modified using other tools. Editing the layer with the text tool will discard these modifications. You can edit the layer or create a new text layer from its text attributes. with 3 options, Create New layer, Cancel, and Edit however, no matter what I click, it doesn't let me create new text anywhere. ALSO, it seems to jump from the layer i selected to another layer whenever I click EDIT. SO frustrating. What is weird is that I was able to create new text prior to this, but not anymore. if it helps, I am editing a photoshop document, but it's now saved as XCF. also, it's gimp 2.8.0 any help is appreciated! It appears to work as advertised to me, so I'm not sure what the issue is. Here's the behavior I see: I created a text layer and then rotated the layer 90 degrees using Layer/Transform When I select the text layer, and select the text tool, and then click on the text layer in the image, the dialog you refer to pops up. If I select Create New Layer, the original text layer is left unchanged, and a new layer containing the same text as the original layer is added, and I can edit it as a normal text layer because it is new and has only plain text and has not been modified in a manner which renders the text itself uneditable. For example, I can change the wording of the text itself. If I select Edit, the original text layer is reverted to its last state where it was plain text (in this case, back to horizontal text instead of the rotated text), and I can edit that as a normal text layer. As in the other option, I can change the wording of the text itself. The difference between the two buttons is that one leaves the original text as is and creates an additional text layer, and the other uses the original layer. Is this not the behavior you are seeing? What is the behavior you are expecting? GIMP is currently not able to modify the text itself (i.e. change the text itself) once it has been modified in a manner such as rotation. Gary ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] GETTING SKIN TONES RIGHT
On 12/15/12 10:48, Gracia M. Littauer wrote: I'm trying to print a scanned 8 X 10 professional photo of an African-American family (fiends) who have rich tones of very dark milk chocolate to middle dark brown. Printing pictures of fiends can get you into big trouble :-) I know black skin tones are either red or yellow. I have been playing with color balance, but the results are very dull and flat. Any suggestions before frustration over eating kill me ;^). -- Gracia in Cooleemee, NC- on Zenwalk 6.2 http://www.flickr.com/photos/mynameistaken/ http://www.youtube.com/bellalight Cogito, ergo sum I'm out of my league here, but are you working with a color-corrected monitor and do you have a color profile for your printer? That's probably your starting point if you actually want to get them right. You will also need some kind of white / grey / black reference from the scanned image, unless it is known to be corrected to something standard like sRGB already. In order to have any sane approach to the problem, you need to have the colors on your monitor (what you see) print in the same colors on the printer (what you get), and the color profiles properly set up make that happen. At that point you can correct the image so it looks the way it should be, to your eye or to some white / grey reference point, and then it will print ok. Unless the problem is not the translation from the display to the paper, but rather getting it to look right on the display in the first place. In which case I haven't a clue. But here's a thought: If you can find another image with the skin tone you like, bring both images up in gimp. Display the reference image at 100% and pick an area where the skin is the color you want. Use the pointer tool (windows / dockable dialogs / pointer) and hover over a pixel of the appropriate color and write down the rgb values. Then go to the main image, find the skin area where you want the color to match, and note those rgb values. Then use the curves tool to bring them into agreement the way you would to do a white balance. Gary ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
[Gimp-user] Strange rectangle/ellipse select / crop behavior?
FreeBSD, 2.8.2 I'm wondering if others are seeing the same thing I'm seeing: If I select an area using either the rectangle or ellipse select tools, then crop the image, the crop happens correctly, but the selection is left displaced from the new image. If the selection is from one of the other tools (free select, fuzzy, scissors), the selection is left superimposed on the image where it should be. Is anyone else seeing this? Gary ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] gimp multipage tiff
On Fri, Dec 7, 2012 at 11:52 AM, Oleg wrote: Hi, all. Gimp open a multipage tiff as a multilayer image and i can edit it. But when i save it, all layers are merged into one and i've get a onepage tiff. How can i save a multipage tiff? Just curious, what was the source of the original multipage tiff? Gary ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] gimp multipage tiff
On 12/07/12 09:27, Oleg wrote: On Fri, Dec 07, 2012 at 09:06:18AM -0700, Gary Aitken wrote: On Fri, Dec 7, 2012 at 11:52 AM, Oleg wrote: Hi, all. Gimp open a multipage tiff as a multilayer image and i can edit it. But when i save it, all layers are merged into one and i've get a onepage tiff. How can i save a multipage tiff? Just curious, what was the source of the original multipage tiff? A scanner strange people. I'll be careful to avoid scanning images of strange people! :-) ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
[Gimp-user] Dodge/Burn -- any reason why range is not a checkbox?
Is there any reason the dodge/burn tool does not implement the range option as a multi-choice instead of a single-choice? I run into cases when I would like to burn shadows and midtones, and it's difficult to get it right if you have to perform two operations. Gary ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] Question about the new sliders
On 12/04/12 00:28, Jeffery Small wrote: shaunak for...@gimpusers.com writes: I notice that there are two cursors that appear while using the new sliders. One is an up arrow that allows me to quickly change from 0 - 100 (Like the old slider) and another is the double side arrow cursor that makes only small changes. I can see how this is useful but I cant seem to figure out how to get one to show over the other. The fast moving (up-arrow) slider appears when you have your mouse in the top half of the slider area. The slow moving (horizontal arrows) appear when you are in the lower half of the area. It is new behavior to learn, but it will become second nature eventually. On freebsd, I get both arrows as described, but *both* of them do the fine- grained increments. Is there a setting that controls this, or is this a bug? Gary ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] Question about the new sliders
On 12/05/12 11:45, Liam R E Quin wrote: On Wed, 2012-12-05 at 11:32 -0700, Gary Aitken wrote: On 12/04/12 00:28, Jeffery Small wrote: The fast moving (up-arrow) slider appears when you have your mouse in the top half of the slider area. The slow moving (horizontal arrows) appear when you are in the lower half of the area. It is new behavior to learn, but it will become second nature eventually. On freebsd, I get both arrows as described, but *both* of them do the fine- grained increments. Is there a setting that controls this, or is this a bug? To be clear, see the enclosed image. The slider with the word Threshold on it is an example. Hovering the mouse pointer in the upper half, e.g. over the word Threshold, changes the mouse pointer to an upwards pointing arrow; clicking in the bar when the mouse pointer displays the upwards arrow will set the amount directly: clicking on the left of the top-half of the bar will set Threshold to 0, clicking on the right (over the 81.5 in this example) sets it to around the maximum of 255, clicking in the middle (e.g.just under the g of sample merged) sets it to about half, or 127. Dragging in this mode will drag the edge of the shaded bar directly. When the mouse pointer is in the lower half of the bar, e.g. in the shaded area under the word Threshold, the mouse pointer is shown with a cursor made of a horizontal arrow pointing both left and right. In this mode, dragging in the bottom half of the area will select the number (81.5 in the image I attached to this message) and the number will change as you drag. The behavior I am seeing under freebsd is as follows: In the upper half, I get the up-arrow mouse pointer. Pressing and dragging that up-arrow mouse pointer changes the value in gross, non-integral increments. When moved from the extreme left to the extreme right, the range covered is large -- If I have the paintbrush tool options up, the size ranges from 1.00 at the extreme left to 1074.55 at the extreme right, although it may be dragged clear across the screen to get much larger values (9491.50 at my right screen limit in this case. Hmmm... If I test the fuzzy select tool as in your image, it goes from 0.0 at the extreme left to 255.0 at the extreme right, where it is clamped at that maximum value -- dragging further across the display causes no further increase. In the lower half, I get the left-right mouse pointer. Pressing and dragging that left-right mouse pointer changes the value in small, non-integral increments. Depending on what the current value is, the possible range varies. If I type in the value 500 to set the value, then grab at the approximate location of the vertical dividing line between the grey and white areas, I get a range of approx 448.56 to 564.11, but if dragged clear across the display it will go up to approx 1400. So two thoughts: 1. Should the integral behavior I am seeing with the up-arrow on the threshold for fuzzy select be going by tenths, or by whole integers? 2. It looks like the bug may be tool-related. Gary ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] Question about the new sliders
On 12/05/12 13:12, Liam R E Quin wrote: On Wed, 2012-12-05 at 12:38 -0700, Gary Aitken wrote: So two thoughts: 1. Should the integral behavior I am seeing with the up-arrow on the threshold for fuzzy select be going by tenths, or by whole integers? Neither, it depends on the width of the toolbox. It should go up or down by distance you drag as a percentage of the max value, times max value E.g. when the up arrow is one third the way along from the left of the scrollbar-thingy, clicking (or dragging at that point, it's the same) gives you one third of the maximum value. So, it's supposed to work as it does, I think. I don't think so. In the case of the paintbrush size, what is the max value? It is certainly not reached at the right boundary of the size slider, where it is ~1000. I can drag clear outside the slider to the right edge of the display and get it up to ~9500. The OP was requesting a manner in which to get integral values, which I think is the main frustration. When sizing a brush, for example, if I know the brush was designed as a 100x100 image, I often want to pick sizes in integral amounts. It's essentially impossible to do with the slider. In addition, once one attempts to do that, the value ends up at some fractional amount like 437.23 and you have to delete the decimal part to get back to whole integers. 2. It looks like the bug may be tool-related. What exactly are you saying is a bug? I'm not saying GIMP is bug-free :-) just trying to see if in fact it's a problem with how to use these controls not being obvious, or whether your gimp is behaving different from mine, or whether all the gimps in the world are misbehaving (always a possibility, especially near a full moon). From what you've described as the formula, I would say it may be mostly behaving as intended, modulo the max value issue and modulo the where is it supposed to be clamped on the right boundary issue. Outside of that, what I would question is whether that intention / design plays well in reality, given the desire for whole-number increments in many cases. BTW you've probably already seen I may have jumped the gun and filed a minor bug on this. My apologies. Could be a full moon thing, as I had a horse magically appear on the wrong side of a fence today. But I doubt it ;-) Gary ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] Question about the new sliders
On 12/05/12 18:56, Liam R E Quin wrote: On Wed, 2012-12-05 at 17:25 -0700, Gary Aitken wrote: On 12/05/12 14:00, Liam R E Quin wrote: [...] I admit I usually use editable brushes, which are limited to square, diamond, circle, triangle, etc., and I have keys bound to increment-by-10, increment-by-1, and the same for decrement. likewise, without the bindings. I think wanting integer-only brush sizes would be an enhancement request, although I'm not sure I understand the motivation: scaling by a non-integral amount sometimes gives better results. But maybe integral brush sizes is just a thing I happen never to have wanted :) Not sure I understand that statement. You apparently use integral brush sizes enough to have bound keys to incrementing and decrementing by 1 and 10. That seems to imply you use integral brushes a lot, unless you always start with an odd-ball non-integer brush size. Am I missing something? Yes. I pretty much only use the dynamic (editable) brushes, and all I care about is the approximate size in most cases. I just looked, and my current brush has a size of 172.36, so pressing } will make it 182.36 and pressing ] will make it 173.36. They get to odd sizes because I might click anywhere on the Size slider. I also have $ and % bound to softer/harder by 10, and 4 and 5 for softer/harder by 1. Right now the brush hardness is 0.69. I'm not a graphic artist, but if you're designing an icon, for example, or a finely detailed map as a that you want as compact as possible, you sometimes want to minimize feathering, anti-aliasing, and everything else that results in partial colors of one form or another. Makes sense but it's a long way from cleaning up 2400dpi full-page scanned images for sale as stock :-) or from freehand painting, or from using dodge/burn on a photograph, where soft edges are needed. agreed; I don't do those pixel things very often, but others might. [...] If this is a feature, and if you can grant that wanting integral sizes has some utility, shouldn't that be relatively easy to attain by the user? I would submit that integral sizes, or something more integral than 0.01 increments for brush size in particular, is likely a common desire. I suppose for people doing professional pixel-level work it may be, that hadn't occurred to me. I don't mean to imply that one usage is better or more important than another. It might also be useful to be able to set the max and min values (max in particular). I suspect there are very few people who want a brush size more than 1000 (but hey, I don't design billboards). I used to recompile my own gimp with a larger maximum brush size, although I have not often used more than 400 pixels or so. Being able to set a maximum might help with Fitt's Law - quicker selection of the largest size. Even in a pixel context a square brush with a radius of 0.5 pixels makes sense to me though. So I'm not sure what is a good answer here. There's a paint tool options button to reset bitmap brushes to their native size, so maybe keybindings for tool presets would let you switch brush sizes with a single keypress? I agree a .5 radius makes sense; it's also a 1.0 diameter ;-). Dang, there's a conundrum -- brush Size should be labelled Radius or Max Extent (or something like that for non-circular type brushes). I may not be understanding correctly, but it seems like that would allow setting of specific sizes, not the whole range one might be interested in? What bothers me about the keybindings idea is that it is an accelerator, and the less-proficient / less-experienced with the specific tool user tends to use the mouse. Getting the desired behavior should be possible via the mouse. Going back to my original proposal, what downsides does it have? It requires no changes to the interface, some additions to preferences, and pretty simple changes to the guts of the generic slider. It allows arbitrary granularity and a pretty wide range of possibilities, and is relatively simple: valueDelta = ((float)deltaPtr / (float)maxPtr) * (valueExtent * 100.) / granularityX100; valueDelta = (float)((int)(valueDelta * 100) / granularityX100) * granularityX100 / 100.; newValue = value + valueDelta; e.g.: value=175.000 granularity=1.500 minValue=-100.000 maxValue=400.000 deltaPtr=15 maxPtr=1024 valueExtent=500.00 granularityX100=150 deltaPtr * valueExtent * 100 / maxPtr=732.421875 valueDelta / granularityX100=4.882812 valueDeltaX100=450.00 valueDelta=4.50 newValue=179.50 Gary ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] Tearing my hair out
On 11/12/12 16:05, Briyanna wrote: On 11/12/12 15:43, Briyanna wrote: I'm still running 2.6 but I think it's the same I think you're dragging by the normal window manager header, not the gimp dialog header, which is the bar just below it where the tool options menu button is along with the tool name. Press and hold in the area to the left of the tool options menu button (e.g. if it's showing the paintbrush tool, the tool options menu button is the arrow to the right of where it says Paintbrush at the top; press on the tool name or the blank area to the left of the left arrow button) BTW, once it's back where it belongs, you can bring up the tool options menu and select lock to tab to dock which should prevent dragging it out in the future. I am dragging the icon/text that says Tool Options, not the window itself. That's your problem. Below the window bar that says Tool Options, there is another bar-like area that has a left-facing arrow button over on the right side. Drag from the empty space somewhere to the left of the button. Gary ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] Tearing my hair out
On 11/12/12 15:43, Briyanna wrote: I accidentally pulled my Tool Options tab from my Toolbox. No matter how I drag it back to where it says You can drop dockable dialogs here it does not return to where it came from. It will drag itself to random places all over my display, but it refuses to dock back to the Toolbox. I've seen tutorials and help texts and videos show that there should be a blue outline when it's in place, or it turns into a hand in some versions, but that doesn't happen for me - the top left corner remains a black arrow (corner), and it will drag maybe halfway to where I tell it to if I am trying to move it across the screen, and drop where it feels like dropping. Does anyone have any idea how to put the Tool Options tab BACK on the Toolbox where it belongs? Thanks! Using GIMP v 2.8.2 on Windows 7 Home Premium I'm still running 2.6 but I think it's the same I think you're dragging by the normal window manager header, not the gimp dialog header, which is the bar just below it where the tool options menu button is along with the tool name. Press and hold in the area to the left of the tool options menu button (e.g. if it's showing the paintbrush tool, the tool options menu button is the arrow to the right of where it says Paintbrush at the top; press on the tool name or the blank area to the left of the left arrow button) BTW, once it's back where it belongs, you can bring up the tool options menu and select lock to tab to dock which should prevent dragging it out in the future. Gary ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
[Gimp-user] build problem
I'm trying to build 2.8 on freebsd. As a starting point, I'm trying to build only babl-0.1.10 I've downloaded the tarball and unpacked it. then: cd /usr/local mkdir -p gimp-2.8/lib/pkgconfig mkdir gimp-2.8/bin export PATH=/usr/local/gimp-2.8/bin:$PATH export PKG_CONFIG_PATH=/usr/local/gimp-2.8/lib/pkgconfig export LD_LIBRARY_PATH=/usr/local/gimp-2.8/lib cd ~/Computing/GIMP/work_2.8/babl-0.1.10 ./autogen.sh --prefix=/usr/local/gimp-2.8 make make all-recursive Making all in babl Makefile, line 1013: Missing dependency operator make: fatal errors encountered -- cannot continue babl/Makefile line 1012-103 looks like this: # GObject Introspection -include $(INTROSPECTION_MAKEFILE) INTROSPECTION_MAKEFILE is set empty early on in babl/Makefile It is also set empty in the top level Makefile, along with all the other INTROSPECTION_* symbols plus a few others like LDFLAGS and LIBOBJS I'm guessing there's something additional I need to do either in terms of flags passed to make or autogen, or else some environment vars needed to get the gnome build environment correct. help? Thanks, Gary ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
[Gimp-user] script-fu (display...) output in batch mode
Can someone tell me where the output of (display ...) in a script goes when running in batch mode? Thanks, Gary ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] interface to ufraw -- save options
On 09/20/12 22:54, Liam R E Quin wrote: On Thu, 2012-09-20 at 22:37 -0600, Gary Aitken wrote: Is there a way to tell gimp to bring up ufraw differently, You can run ufraw outside of gimp, not as a plugin. I'm trying to automate a process, and don't want to have to manually start ufraw. I could start ufraw and use its gimp button to transfer control to gimp, but that doesn't do what I want either -- if you tell ufraw to save to get the .ufraw file saved, it quits; so then you can't transfer control to gimp. Fundamentally, I want to do the following: specify a set of raw file names to process specify a destination directory for each raw file: a. process in ufraw a1.manual crop, etc., if desired a2.save a .ufraw file in the source directory b. process in gimp b1.manual manipulation if desired b2.automatic resizing and sharpening, etc b3.automatically generate a .jpeg file in the destination directory With the exception of the input file names and the output directory, (and a1 and b1) I want everything else done automatically. I tried using a shell script and having ufraw write a .tif intermediary; however, that has the following problem: In step b3, I need to get the destination directory name, and I can't figure out how to do that automatically. A command line arg like -DDEST_DIR foo would be great, but I don't see anything in the man page for defining an arbitrary input arg which a script could have access to. An arg in a script can have a fixed default value, but that's not what I need. One could get really gross and dynamically generate a script with the proper default for the arg before starting gimp, but that's sick :-). I'm all ears for any suggestions. Gary ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] interface to ufraw -- save options
On 09/21/12 16:48, Alexandre Prokoudine wrote: On Sat, Sep 22, 2012 at 2:02 AM, Gary Aitken wrote: I'm trying to automate a process, and don't want to have to manually start ufraw. I could start ufraw and use its gimp button to transfer control to gimp, but that doesn't do what I want either -- if you tell ufraw to save to get the .ufraw file saved, it quits; so then you can't transfer control to gimp. Fundamentally, I want to do the following: specify a set of raw file names to process specify a destination directory for each raw file: a. process in ufraw a1.manual crop, etc., if desired a2.save a .ufraw file in the source directory b. process in gimp b1.manual manipulation if desired b2.automatic resizing and sharpening, etc b3.automatically generate a .jpeg file in the destination directory Is there a reason you can't save .ufraw for each file, then run ufraw in batch mode to create TIFF files for further editing with GIMP? I'm wondering, because it's something I used to do a lot some 4 or 5 years ago, before darktable was conceived. Thanks for the suggestion; a variant of that idea may work. On 09/22/2012 12:17 AM, Gerald wrote: As far as I know, UFRaw is mostly a graphical front-end for the command-line utility DCRaw. On 09/21/12 16:35, Partha Bagchi wrote: It is a modified version and so not as up to date as DCRaw which has all the options you need. :) Unfortunately, I need the gui interface to determine what the parameters should be -- crops and exposure mods, for example. ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
[Gimp-user] interface to ufraw -- save options
Hi all, I've got a script for processing a bunch of files which starts by bringing up ufraw. I would like to have ufraw save the list of modifications made before returning to gimp. (.ufraw file) However, when gimp starts ufraw, it passes some option to ufraw which causes ufraw to not display the save tab which allows setting what to save. Is there a way to tell gimp to bring up ufraw differently, or is the problem in ufraw? Thanks for any insights, Gary ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
[Gimp-user] how / when to use gimp-image-delete
When processing a series of files in script-fu, I'm trying to do the following: for each file name: Create an image by reading it in. (set! orgImg (car (file-ufraw-load ... Create another image by duplicating the input image and manipulating it. (set! newImg (car (gimp-image-duplicate orgImg))) (gimp-image-scale newImg wid ht) (plug-in-unsharp-mask RUN-NONINTERACTIVE newImg newImg ... Write the new image out. (file-jpeg-save ... newImg ... Since I'm done with the newly created image, I did a (gimp-image-delete newImg) Continuing on, if I try to re-use that variable to create another image from the original image and try to manipulate it, I get an error after a bit: (set! newImg (car (gimp-image-duplicate orgImg))); doesn't complain (gimp-image-scale newImg wid ht) ; doesn't complain (plug-in-unsharp-mask RUN-NONINTERACTIVE newImg newImg ... Error: Procedure execution of plug-in-unsharp-mask failed on invalid input arguments: Procedure 'plug-in-unsharp-mask' has been called with an invalid ID for argument 'drawable'. Most likely a plug-in is trying to work on a layer that doesn't exist any longer. If I comment out the gimp-image-delete it works fine. Can someone explain to me what is going on? (Using gimp 2.6) Thanks, Gary ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
[Gimp-user] turning off thumbnail in jpeg saves; deleting a thumbnail?
Is there any way to turn off the jpeg thumbnail when writing out a file using file-jpeg-save? Otherwise, a small web image can be large when generated by copying from an existing image which has a thumbnail. In my case, the source image is coming in via ufraw. It's not clear to me whether the thumbnail I'm getting is created by GIMP or sent to it from ufraw. If it's being created by gimp, is there a way to delete the thumbnail from an image? Or does one have to create a new empty image and copy only the active layer from the existing image to it? Will that even solve the problem? Problem with creating a new image is all the exif data, etc, is lost. Thanks, Gary ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
[Gimp-user] what's with the auto-insert of run-mode as the first arg for script-fu methods?
Using gimp 2.6 I originally defined my script-fu procedure as (define (my-proc fileExpr) ... ) and registered it using: (script-fu-register my-proc ... ; image type the script works on SF-STRING FileNameExpression ) But the procedure browser lists it as taking two args, the first of which is run-mode INT32 Interactive, non-interactive In order to get it to work, I had to change the definition to: (define (my-proc runMode fileExpr) ... ) but left the registration as is (without run-mode). What's the deal with the auto-insert of run-mode in the procedure browser help, and do I have to define it as an arg in the registration? If so, what is its type? (I tried SF-RUN-MODE and it didn't like that) If I leave it as is and try to use it from the menu instead of the script-fu console, There's no place to enter the run-mode in the dialog which pops up, and it feeds the string first arg in as the run-mode and barfs. totally confused, looking for some enlightment... ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] script-fu: illegal function?
On 09/17/12 21:44, Richard Gitschlag wrote: That's right - parentheses are not free in Scheme scripting, every opening parenthesis must be immediately followed by a function call. When you just want parentheses to group a few statements together with, call the (begin ... ) function: (begin (function a) (function b) (etc ) ... ) Thanks, both of you for clarifications. Not sure where I saw the print but it seems to work: (define (find-dot txt txtLen offset) (print foo) xyz pqr) (find-dot abcd.ef 7 1) find-dotfoo pqr (define (find-dot txt txtLen offset) (display foo) xyz pqr) (find-dot abcd.ef 7 1) find-dotfoopqr The function itself seems to be accepted. It appears the difference between using display and using print is that print outputs enclosing double quotes plus trailing newline; display outputs the unadorned string and no trailing newline. -- Stratadrake strata_ran...@hotmail.com Numbers may not lie, but neither do they tell the whole truth. Date: Mon, 17 Sep 2012 18:47:38 -0400 From: ke...@ve3syb.ca To: gimp-user-list@gnome.org Subject: Re: [Gimp-user] script-fu: illegal function? On 12-09-17 02:28 PM, Gary Aitken wrote: ((define (find-dot txt txtLen offset) (print foo)) (find-dot abcd.ef 7 1)) First, you wrapped the whole thing in ( ). Drop the leading and trailing parentheses. Second, that is a line of Scheme code and Scheme does not contain a print function. You probably meant to use display. Also keep in mind that the display function only takes a string so you may first need to convert what you pass it to a string. -- Cheers! Kevin. http://www.ve3syb.ca/ |Nerds make the shiny things that distract Owner of Elecraft K2 #2172 | the mouth-breathers, and that's why we're | powerful! #include disclaimer/favourite | --Chris Hardwick ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
