Hello all,

gimp 2.7.5 on winXP, unfortunately. New hardware problems on my freebsd system. grr. Anyway...

Why won't the gimp allow me to use a difference of gaussians on a layer mask? This seems like a perfectly fine thing to do for edge detection, and indeed, other edge-detect algorithms work:

For example: New layer mask, from grayscale copy of layer Filters / edge-detect / difference of gaussians says: Execution error for 'Difference of Gaussians': Can operate on layers only (but was called on channel or mask). but
Filters / edge-detect / Edge...
works fine

Is this a bug, or am I missing something? Any insights would be appreciated,

Gary

Hi Alexandre,

Yes, I'm aware that I can work around it as you mention, and have been doing so. But it is a pain in the rear, and unless there is some over-riding reason for not allowing one to do this operation, it seems the gimp should allow it.

My main reason for posting was to see if it is a known issue and decided to be left as-is. I don't see an open bug for it. I suspect it may be a relic of implementation difficulties and so a capability which may be desirable but a bit awkward to implement.

Thanks,

Gary

On 1/21/2012 12:39 PM, Alexandre Prokoudine wrote:

On Fri, Jan 20, 2012 at 11:02 PM, Gary Aitken wrote:

Hello all,

gimp 2.7.5 on winXP, unfortunately. New hardware problems on my freebsd system. grr. Anyway...

Why won't the gimp allow me to use a difference of gaussians on a layer mask? This seems like a perfectly fine thing to do for edge detection, and indeed, other edge-detect algorithms work:

For example: New layer mask, from grayscale copy of layer Filters / edge-detect / difference of gaussians says: Execution error for 'Difference of Gaussians': Can operate on layers only (but was called on channel or mask). but
Filters / edge-detect / Edge...
works fine

Is this a bug, or am I missing something? Any insights would be appreciated,

Hi Gary,

Not sure about the technical side of this, but you should be able to perfectly work around that.

1. Enable display of the mask via right-click menu so that the mask is displayed instead of the layers's contents. 2. Layers> New from Visible.
3. Apply your filter to that layer.
4. Copy all of the layer's contents and paste it into the mask. 5. Remove or disable the extra layer you created.

Alexandre Prokoudine http://libregraphicsworld.org
_______________________________________________ gimp-user-list mailing list
gimp-user-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-user-list

Hi Seth,

Thanks for the perspective. I was thinking if my world ever settled down (won't happen for a few months at best) I might try to gnaw on that a bit. Thanks again,

Gary

On 1/21/2012 4:05 PM, Seth Burgess wrote:

Hi Gary,

edge_dog isn't the most elegant of plug-ins, and behaves more like a script than most C plug-ins; it creates temporary layers, and to do so, uses gimp_layer_copy. (see
http://git.gnome.org/browse/gimp/tree/plug-ins/common/edge-dog.c line 471). So it inserts a check that the drawable is a layer before it does anything else.

I expect that careful checks and alternate code paths could alleviate the issue (copying masks to new layers), or it could be rewritten to do its operations in a more self-contained way. I'm not volunteering here, but it doesn't seem like an insurmountable amount of work for someone motivated.

HTH,

Seth Burgess

I have a question regarding the use of ICC profiles in UFRaw + GIMP.

If I load an image into UFRaw and specify an ICC profile for my camera, then output a .tiff image, that image is color-corrected. At least that is my assumption...

Now, if I load the .tiff image into GIMP, and again specify an ICC profile for the camera, the image is corrected again, I think. Which amounts to over-correction. Correct?

How do people handle this in their workflow? Correct in UFRaw and use GIMP with no correction?

What happens when you specify an icc profile in UFRaw and then activate UFRaw from the GIMP?

Thanks for any insights,

Gary

Humor me, and try the following:

Scenario 1:

Load a raw image into ufraw with some feature for which you can tell a difference when a profile is applied.

Apply the profile in ufraw. Save the file as .tif

Start gimp. Go to Edit/Preferences/ColorManagement Make sure RGB Profile is set to "None" Load the .tif image.
It should look as the corrected image, i.e. profile applied. Go to Edit/Preferences/ColorManagement Check RGB Profile
It still says "None"
ok so far
Presumably the profile used is the one embedded in the .tif image. But there is no way of knowing what that profile is or whether it has been applied that I can figure out.

Now set the RGB Profile to the one you used in ufraw when generating the .tif image.
You will see the image transformed again. In effect, the profile is being applied twice.

Discard the image from gimp. Leave the RGB profile set.
Load in the tif image.
You will see that the color profile has been applied twice, once from the one embedded in the image, and once from the one specified in the color management preference.

Scenario 2:

Start gimp Edit/Preferences/Color Management
Set RGB profile to none
Read in a non-raw image with no profile attached Edit/Preferences/Color Management
Set RGB profile to something where you can notice a difference. Export the image as .tif
Change the gimp color profile back to none. Load the exported image back in.
The image appears as it did when first read in, without any applied profile. Apparently, the profile was not attached to the exported image.

Scenario 3:

Start gimp Make sure no profile is set.
Drag a raw file onto gimp
Should start up ufraw
Make sure ufraw applies a color profile to the image. Click ok to end ufraw and send the image back to gimp Image shows up in gimp with profile applied Edit/Preferences/Color Management
Shows no RGB profile
Export the image as .tif
In this case the exported image still contains the color profile.

In scenario 2, gimp exports a .tif image without the applied color profile. In scenario 3, gimp exports the image with the applied color profile, presumably because it was embedded in the image when it got it from ufraw.

It appears that gimp only exports a profile with an image if the profile came with the image when it was loaded into gimp.

Unless you know in advance whether or not an image has a color profile attached to it, you can't know how to process the image, given the above issues. Furthermore, you can't produce an output image with a profile attached, such as adobe rgb for printing. You may be able to achieve that result if the printer you are targeting is reachable from your system, but that doesn't cover the case where you want to put an image on a thumb drive or transmit it to a different place for printing.

I claim this a bug. I would think it should track which profile was applied to each image, and
1. Not apply it twice if it is the same as the one which came with the image
2. Ask for verification if trying to apply a profile to an image which is different from the one the image came with (Assuming it came with one). If applying a new profile over an existing profile, I can think of two possible scenarios.
2.a You believe the input profile is incorrect or inappropriate. In this case you want to unapply/replace the input profile with the new one.
2.b You accept the input profile as correct, but want to remap to a different output space, such as adobe RGB. In this case you want to keep the transformation of the input but attach the new profile to the output. I presume this is what the CMYK profile is for, but it appears to me that profile only applies when executing code in the print command path. It does not appear to be applied when exporting an image. It also appears that this is what the RGB profile in the properties actually does (apply a profile in addition to any input profile that came with the file); however, as noted earlier, the profile is not embedded in the output. I do not know if it is permissible to apply multiple profiles to a file; my impression is not. If it is not, then in order to produce a file suitable for printing, gimp (and any other image manipulation program) has to be able to read a file with a profile, apply that profile to transform the input pixels to the reference space, and then output that file from the reference space with a new profile attached. Otherwise, all of the processing of the image has to be redone to produce images for different targets (e.g. web, print). 3. Export the profile with the image when one has been applied, if possible.

BTW, I'm using gimp 2.7.5 (2.8 preview); I don't know if this is specific to 2.7.5 or not. It may also be that these are temporary issues with the transition to full color management and 16bit colors. But if they are issues not already on the gimp development plate, they should probably be raised so they are at least well-known.

Or I need to be educated if they are not considered bugs. Sticking to sRGB doesn't solve these issues. I'm more than willing to accept that I need an education, so any and all clarifications or welcome.

Gary

On 1/30/2012 6:07 PM, Frank Gore wrote:

On Mon, Jan 30, 2012 at 7:50 PM, Gary Aitken wrote:

I have a question regarding the use of ICC profiles in UFRaw + GIMP.

If I load an image into UFRaw and specify an ICC profile for my camera, then output a .tiff image, that image is color-corrected. At least that is my assumption...

Now, if I load the .tiff image into GIMP, and again specify an ICC profile for the camera, the image is corrected again, I think. Which amounts to over-correction. Correct?

ICC is not a correction. It is a profile. It tells the application how to interpret the colours that are encoded in the file. If you specify an ICC profile in UFraw, that profile gets saved into the image file, and Gimp uses that profile information when it opens the image file. If you re-specify a new ICC profile within Gimp after you've opened the image, you're not "over-correcting" anything, you're just doing an extra useless step that results in nothing happening.

In your case, I'd say you've got absolutely no reason whatsoever to be doing colour management. Sticking to standard sRGB for your entire workflow would be entirely acceptable and would give you the best results.

--
Frank Gore
THE place to talk photography!
www.FriendlyPhotoZone.com