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&t=4846&p=183034&hilit=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 > 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
On 02/07/15 15:54, Alexandre Prokoudine wrote: > There is no multiple layers selection in GIMP yet. This obviously > needs fixing, and some preliminary work has been done there, but it > was never finished. Hopefully someone will find the time to make it > possible. ah, thanks, that explains it. When you say some preliminary work has been done there, are you referring to the chain / link that appears in the layers dialog? That can be used to select multiple layers for some operations such as move (move in the image, as opposed to drag in the layers dialog) and transform. Or is the preliminary work a different mechanism all-together? And in that case would the chain feature go away since it would be redundant? 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
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
[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] GIMP crashes intermittently & often
Hi Dave, > What do you mean by "bringing an open Excel window into focus to > enter data obtained from GIMP"? You clarified in step 3 below. > We are using GIMP to calculate some values and then manually entering > the data in Excel. Steps: > 1. Excel is active > 2. GIMP is active - make measurements and note them down > 3 Click on the Excel window so that it gets focus- i.e. it comes to the front > so that you can enter data > 4. Message pops up "GIMP has encountered a problem and must close" > > So GIMP has not been idle, nor is it on the other machine when it > crashes The machines have a lot of free disk space - 3 Terabytes on > Machine #1, about 1 Terabyte on Machine #2 Memory is managed by > Windows Wow, that is really bizarre. What is the file type of the image being viewed? Does it still crash if you use an image of a different type? Is the image being edited located on the system on which gimp is executing, or is it located on a shared file system on a different machine? If you go to edit/preferences/folders, what are the temporary folder and the swap folder values, and are those located on the same machine on which gimp is executing? What happens if you do the measurement and instead of clicking on another application, just wait a minute or two? Can you perform another operation in gimp under those conditions without it crashing? For example, measure something else in the same image? If you run the taskmgr and view the performance tab, does anything grow like crazy and saturate at a high value when it's in the process of crashing, then go back down to more normal values? If it does, can you tell which process (probably gimp, but you never know...) is consuming the resource? > The error log on machine #2 shows the following: > Faulting application name: gimp-2.8.exe, version: 2.8.14.0, time stamp: > 0x > Faulting module name: libcairo-2.dll, version: 0.0.0.0, time stamp: 0xa340a328 > Exception code: 0xc005 > Fault offset: 0x000235b4 > Faulting process id: 0x1344 > Faulting application start time: 0x01d03e91dbe5d19d > Faulting application path: C:\Program Files\GIMP 2\bin\gimp-2.8.exe > Faulting module path: C:\Program Files\GIMP 2\bin\libcairo-2.dll > Report Id: df6c9434-ab43-11e4-8279-002590c1ee4d I'm fishing with the above questions to try to figure out why it would be crashing in the cairo library; it's hard to imagine why it would crash there when gimp loses focus, although I don't know squat about cairo or the ways gimp uses it. Do you happen to have a version of the program cairo-trace on your system? If so, it may be helpful to start gimp using the command cairo-trace gimp cairo-trace creates a file that shows all the operations cairo is performing; it may be possible to see what it is doing when it fails by examining that file. Gary > On 02/03/15 19:06, David Scriven wrote: >> Dear All, I'm using GIMP (2.8.14, downloaded from your site) on >> two Windows 7 x64 machines (both fully up-to-date). Both have >> antivirus software and Office 2010 with Word, Powerpoint, Excel, >> etc. installed and active. On numerous occasions and while GIMP is >> being used Windows issues the message "GIMP has encountered a >> problem and must close". This usually occurs when one or more >> Office 2010 windows are also open. For example, a colleague working >> on machine (#1, 4 cores, 8 GB memory, HD Intel graphics) found >> that bringing an open Excel window into focus to enter data >> obtained from GIMP was sufficient to crash GIMP and cause this >> message. (this is consistent and has happened many times). This has >> only just started occurring - previously the user on machine 1 had >> used GIMP for the same task without problem (update to Office >> causing the problem??). I have now encountered the problem on >> machine #2 (16 cores, 64GB memory, high-end NVIDIA card) using GIMP >> and Powerpoint simultaneously, although I have not been able to >> identify a precipitating event that causes this. >> >> I have tried increasing the memory available to GIMP in both >> machines (via Edit/Preferences) but to no avail. The error message >> is virtually meaningless. The crashes are frequent enough (about >> 1 /hour) that is extremely irritating, never mind the loss of time >> and work. Any ideas? David > > What do you mean by > > "bringing an open Excel window into focus to enter data obtained from > GIMP"? > > How are you trying to transfer the data (presumably an image) from > GIMP to Excel? > > It sounds like you are not doing anything with GIMP leading up to the > crash. i.e. it has been sitting idle for some time. Is that > correct? > > How much swap space (paging file size) does the system have? Is it > set to fixed limits, or to "Let Windows Manage My Virtual Memory"? > How much free disk space is there? > > It sounds like you are bumping up against some system resource limit, > but which one is hard to tell. Is there anything in the system error > l
Re: [Gimp-user] GIMP crashes intermittently & often
On 02/03/15 19:06, David Scriven wrote: > Dear All, I'm using GIMP (2.8.14, downloaded from your site) on two > Windows 7 x64 machines (both fully up-to-date). Both have antivirus > software and Office 2010 with Word, Powerpoint, Excel, etc. installed > and active. On numerous occasions and while GIMP is being used > Windows issues the message "GIMP has encountered a problem and must > close". This usually occurs when one or more Office 2010 windows are > also open. For example, a colleague working on machine (#1, 4 cores, > 8 GB memory, HD Intel graphics) found that bringing an open Excel > window into focus to enter data obtained from GIMP was sufficient to > crash GIMP and cause this message. (this is consistent and has > happened many times). This has only just started occurring - > previously the user on machine 1 had used GIMP for the same task > without problem (update to Office causing the problem??). I have now > encountered the problem on machine #2 (16 cores, 64GB memory, > high-end NVIDIA card) using GIMP and Powerpoint simultaneously, > although I have not been able to identify a precipitating event that > causes this. > > I have tried increasing the memory available to GIMP in both machines > (via Edit/Preferences) but to no avail. The error message is > virtually meaningless. The crashes are frequent enough (about 1 > /hour) that is extremely irritating, never mind the loss of time and > work. Any ideas? David What do you mean by "bringing an open Excel window into focus to enter data obtained from GIMP"? How are you trying to transfer the data (presumably an image) from GIMP to Excel? It sounds like you are not doing anything with GIMP leading up to the crash. i.e. it has been sitting idle for some time. Is that correct? How much swap space (paging file size) does the system have? Is it set to fixed limits, or to "Let Windows Manage My Virtual Memory"? How much free disk space is there? It sounds like you are bumping up against some system resource limit, but which one is hard to tell. Is there anything in the system error log? 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 wrote: > >> 2014-11-17 0:11 GMT+01:00 Helen : >> >>> 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 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] 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] 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] [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] 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] 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 O), 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 I). Click on the Bucket Fill tool (or B). 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] 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
>> (2, 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. 2 for 50%, instead of displaying
>> 2 it displays "@" (which is the normal character for
>> 2 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
(2, 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. 2 for 50%,
instead of displaying 2 it displays "@" (which is the normal character
for 2 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 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
>> 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 and after typing 'u'. >>Then hit after all the hex chars are in. >> 2. Keep and down until done with hex chars; >>releasing 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 u the characters being typed are "normal" and in the second they have the 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 u 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
>> 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 and after typing 'u'. Then hit after all the hex chars are in. 2. Keep and down until done with hex chars; releasing 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
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 wrote: >> Hello, >> >> how to write in GIMP with greek letters? You can also use the unicode values for single letters by typing u 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² u03c0r00b2 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
[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
>> 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
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] Brush dynamics when stroking a path
Using gimp 2.8.10
I'm trying to paint a whirlpool stream for a scientific diagram,
similar to what you would see out the back of a boat from the
propeller wash.
I've drawn a path for the stream to follow, sort of a modified sine
wave, starting at the propeller and ending a ways downstream.
What I'd like to do is paint from one end of the path to the other,
with the width of the stroke gradually getting wider, and the ink
deposited fading, the way a FG => BG gradient does.
I was finally able to get what I wanted using the dynamic options
for painting using the paintbrush tool and defining a new one, but
it is not at all clear to me how it works.
Is there a tutorial around for how the brush dynamics work with
stroking a path?
When one brings up the paint dynamics editor and selects one of
the painting properties such as "Size", a graph is displayed. The
vertical axis is labelled with the property selected ("Size" in
this case) and the horizontal axis is initially labelled with an
input device attribute, "Pressure", the top attribute in the list
below the graph. The check box for "Pressure" is not checked.
The explanations I've seen of this graph describe it as a mapping
between a property of the brush (e.g. Size or Color) and a property
of the input device (e.g. Pressure on a tablet).
However, one of the attributes selectable for the graph, "Fade",
is not a property of an input device (I don't think; I don't have
a tablet).
In any case, when stroking a path there is no input device. So what
determines the value of the input device attributes on the other
axis of the graph?
I'm guessing the vertical axis goes from zero to max, where max is
the set "Size" (in this case) of the brush. Correct?
The label on the horizontal axis changes depending on which of the
attributes below the graph is selected, and the check box determines
whether or not that attribute affects the property being edited.
Initially the "Pressure" attribute is selected (grey background), but
not activated (no check). If I want the "Size" of the brush to change
while stroking a path, what input device attribute should I select?
By trial and error, I was able to get what I wanted using "Fade",
but it is not at all clear to me why. Are there preset curves for
these attributes over the course of a stroked path? If so, what are
they?
After selection, a line/curve is displayed showing how the property
of the brush ("Size") will be varied according to the attribute
("Fade") value. If I want the brush to start 25% of its total size
and grow to 100% over the full length of the path, I adjust the curve
to start 25% up the axis on the far left and end at the upper right
corner.
What does the length of the horizontal axis represent? From the
behavior I am seeing with "Size" and "Fade", it appears to represent
the path from beginning, at the left end, to end, at the right end.
So when painting, the brush property (in this case "Size") will have
its attribute(s) (in this case "Fade") varied when painting along the
path as shown by the curve going from left to right. However, it's
not clear to me what "Fade" means in relation to "Size" (see next
paragraph).
If I uncheck the "Fade" box and instead check "Pressure", but establish
the same curve I had for "Fade", I get a different behavior. The
stroked path starts and ends small, with the maximum size in the middle.
Since the stroking is being done by the path traversal tool and not a
human manipulated instrument, there is no change in pressure, so what
is happening? Using "Velocity" causes the brush "Size" to vary in the
opposite way from when "Fade" is used. Again, the velocity should not
be changing, so what is really going on? "Direction" seems to vary
"Size" based on some weighted average notion of the direction of travel,
with horizontal yielding large sizes and vertical yielding small. "Tilt",
"Wheel", and "Random" don't seem to do anything.
If I want the "Color" to "Fade" over the course of the curve, I have to
start the curve at the lower left (No fading?, i.e. 100% color) and have it
end somewhere higher (some fading) on the right. What does fading mean in
this case? changing opacity?
The above two brush properties, "Size" and "Color", seem to behave in
opposite ways when the "Fade" attribute is selected. For "Size", the
"Fade" axis seems to have nothing to do with "Fading" the size, but simply
represents the overall length of the path; but for "Color", it seems to
indicate the inverse opacity (amount of fading) of the brush.
Thanks for any tips / explanations,
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] 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] 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
[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] 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
> To: 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 a
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] 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
[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
Re: [Gimp-user] layer positioning
On 01/02/14 19:27, akovia wrote: > On Thu, Jan 2, 2014, at 08:46 PM, Gary Aitken wrote: >> On 01/02/14 17:48, Joao S. O. Bueno wrote: >> 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. > > Sounds to me like you haven't selected the object yet. > > Select the alignment tool or shortcut "q" > Activate the layer you want to align. > (Make sure this layer is cropped smaller than the image size) > You should have a hand cursor to select the object on the canvas. when > you do you should see 4 small squares outlining how big the object is > that you want to align. > Now select the alignment buttons in the toolbox. > > I hope this is all it is and this works for you. > Thank you. Took me a while to figure out -- I had a mostly transparent layer on top and the selection goes by stacking order. An excellent solution to the problem; using the rulers to snap was also good. Thanks all for your help. 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 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] 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
[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
[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] 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
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 file>export 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] Question about bump map location
(display " scaledImage:") (print imgToScale) imgToScale; force the return value ) ) ; Add watermark to an image ; Arguments: ; Name of file to process (xxx.tif, etc) ; Image to which watermark will be added ; Drawable, unused ; Name of file containing watermark (xxx.png, etc) ; 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 "Mode""RUN-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
Re: [Gimp-user] Question about bump map location
(display " scaledImage:") (print imgToScale) imgToScale; force the return value ) ) ; Add watermark to an image ; Arguments: ; Name of file to process (xxx.tif, etc) ; Image to which watermark will be added ; Drawable, unused ; Name of file containing watermark (xxx.png, etc) ; 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 "Mode""RUN-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
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] 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] 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] 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 (L) 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] 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 "Mode""RUN-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-STRING"Added 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-MODE"Mode""RUN-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] CR2 files
On 02/12/13 13:09, Matthew Miller wrote: > On Tue, Feb 12, 2013 at 03:03:38PM -0500, Kevin Cozens wrote: >>> I photographed the aurora while living in Alaska in RAW format which >>> produces a CR2 extension. Why will GIMP not open these photos? >> You need either the dcraw or ufraw plug-in for GIMP. I prefer the >> dcraw plug-in. The ufraw plug-in has too many options about what >> should be done to the image when it is loaded. I don't know what I >> might want/need to do to the image until after I load it and look at >> it. > > So, the downside of this approach is that the decisions you make *during* > RAW conversion are generally lossless operations; you can go back and do > them differently with no destruction of data. If you start from a file > converted in a certain way, you've already lost a lot of flexibility. Whoa! :-) That is hardly a downside. RAW conversion is something you can dorepeatedly without degrading the image, as it always starts from the original raw data and never modifies it. You don't need to do anything with the ufraw options *when the image is loaded*; you can tweak them after it is loaded into ufraw. The main reason for tweaking them during the load process is if you have a fixed set of parameters you generally use for images from a given camera, such as color profiles, etc. Maybe I mis-interpreted your statement? "If you start from a file converted in a certain way" and that conversion is unsatisfactory, reopen the file from gimp, using the ufraw plugin, and convert it in whatever different way you want. What is a pain is that the ufraw plugin does not allow for saving a .ufraw file, an option you have when starting ufraw stand-alone. So if you want to preserve the options you work out in ufraw, you need to set up a pipeline / shell script to run ufraw and then feed the result into gimp. Is your objection that the ufraw tweaks are not part of the undo history stack? The ufraw process is an advantage, although an inconvenience, in this respect. The gimp undo history stack is wonderful, but it is (unfortunately) not saved with the xcf image. Once you save and quit gimp, reloading the image you have lost all of the history. The ufraw tweaks are totally repeatable and modifiable without degrading the image. Gary ___ gimp-user-list mailing list gimp-user-list@gnome.org 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 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 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 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 07:46, Olivier wrote: > 2013/1/23 Gary Aitken : >> 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 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 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] 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] Grid lines are 10x10, not default set in preferences [Solved]
On 01/22/13 21:27, Owen wrote: > >> 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? > > > > That seems strange, the standard installation sets the default grid to > 10x10 pixels. > > You could look at your .gimp-2.8/gimprc and /etc/gimp/2.0/gimprc file > to see if anything has been set, but my guess is something is broke? > > Have you tried setting a new default grid? Just discovered I had set the grid size using the option under the image menu. Since this was a .xcf file, apparently that setting was saved as the default for the image, over-riding the gimp default. I didn't realize setting the grid size on the image menu was something that was preserved across saves. Thanks for the reply, 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
[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
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
Re: [Gimp-user] Cannot Add New Text (confirm text editing)
On 01/04/13 11:18, latinojuan wrote: > i think it has something to do w/ the layer underneath being so big that > everywhere that i am clicking, GIMP thinks i want to change the current > settings > in the text or something. > > because if i click off of the canvas, then it lets me add new text. > apparently, it has something to do w/ the layer size. it seems like all of the > layers are 780x1280... I see. In the layers panel, try making the text layer which has the big text on it invisible (click on the eye). That should allow you to add new text. Gary >> 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] 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] Layers Pelette
> On Thu, Jan 3, 2013 at 6:49 PM, Terry078 wrote: >> using gimp 2.8. when loading images they sit at the top left of the window . >> only one shows in the layers palette (which ever i click on,how do i get them >> all into layers palette(see screen shot) > > Not possible. I may not understand the problem, but can't you do File / Open as Layers? ___ 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
Re: [Gimp-user] Strange rectangle/ellipse select / crop behavior?
On 12/10/12 10:29, Richard Gitschlag wrote: > > >> Date: Sun, 9 Dec 2012 17:02:13 -0700 >> From: a...@dreamchaser.org >> To: gimp-user-list@gnome.org >> Subject: Re: [Gimp-user] Strange rectangle/ellipse select / crop behavior? >> >> On 12/08/12 19:19, Frank McCormick wrote: >> > On 08/12/12 09:08 PM, Gary Aitken wrote: >> >> 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? >> >> > Yes, I get that too on 2.8.2 on Debian Sid. I was told it was a >> > bug some time ago but is apparently still there. >> >> Thanks, I won't worry about reporting it then and will assume it will get >> fixed >> in due time. >> ___ >> gimp-user-list mailing list >> gimp-user-list@gnome.org >> https://mail.gnome.org/mailman/listinfo/gimp-user-list > > I searched Bugzilla for "crop" and "selection" but didn't find anything, so > either I missed it or it hasn't actually been reported yet. Looks like it's 683462 and it's been fixed. Gary ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] Strange rectangle/ellipse select / crop behavior?
On 12/08/12 19:19, Frank McCormick wrote: > On 08/12/12 09:08 PM, Gary Aitken wrote: >> 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? >Yes, I get that too on 2.8.2 on Debian Sid. I was told it was a > bug some time ago but is apparently still there. Thanks, I won't worry about reporting it then and will assume it will get fixed in due time. ___ 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
[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] 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
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] 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] Question about the new sliders
On 12/05/12 14:00, Liam R E Quin wrote: > On Wed, 2012-12-05 at 13:46 -0700, Gary Aitken wrote: >> On 12/05/12 13:12, Liam R E Quin wrote: > >> I don't think so. In the case of the paintbrush size, what is the max value? > > The maximum value is 10,000. However, since your slider is probably less > than 10,000 pixels wide, the approach taken seems to have been to use > 1,000 as the maximum settable within the slider, but to let you continue > dragging (or edit the number, or use the tiny increment button). > >> 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. > > Right. > >> The OP was requesting a manner in which to get integral values, which I >> think is the main frustration. > > Yes, you can't do that this way. Bummer > 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? 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. I don't have a lot of experience with this but I know I often end up with these artifacts when I've forgotten to turn off things like anti-aliasing and feathering for various operations. How does one intuit what is a brush with a 2.85 pixel diameter going to do when it paints? In these sorts of instances when I'm editing pixels, I want a brush size that lays / aligns more or less exactly with the pixels in the image. That may not be the best way to do the things I'm trying to do in these instances, and I'm happy to learn better ways. But one uses the tools in the way one knows how, although that's sometimes like using the back of a knife to undo a screw... > [...] >> 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. > > I think this is a feature and not a bug. 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. This could be as simple as a global option, over-rideable on a per-tool basis, over-rideable on a per attribute basis, for "minimum increment". 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). If there are, I would like to be able to set a more reasonable max. 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 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
