Re: [Gimp-user] HOWTO: stroke a path with the current tool?
Quoting Ilya Zakharevich nospam-ab...@ilyaz.org:
I'm confused on why gimp-vectors-set-visible() is used. Any hint?
I did that merely so I could watch how the process progressed along
the path. It is not functionally necessary.
And I can't guess reasons why you first do gimp-selection-none(), then
combine the orig-sel back?
I assumed that you wanted to add together all of the fuzzy selections
made along the path, and then combine that result with the original
selection using the operation mode. To not do so would lead to some
rather useless results.
For example, if the operation mode were CHANNEL-OP-REPLACE and this
was passed to 'gimp-fuzzy-select-full' then despite making fuzzy
selections all along the path, the only thing that would matter would
be the fuzzy select performed on the path's last point.
Also consider what happens if the 'operation' mode were
CHANNEL-OP-INTERSECT and the original selection was the entire image
(if there were no selection originally then the final result would be
no selection). If I merely passed the INTERSECT mode to Fuzzy Select
then after the first x,y point on the path was fuzzy selected, the
resulting intersection would be only that fuzzy selection. Moving to
the next x,y point and the resulting selection would only be the
intersection of the two Fuzzy Selects. At any point along the path --
including the last point on the path -- the resulting selection will
be no larger than the intersection of that point's fuzzy selection and
the one before it.
And why do you need to set the drawable (which was initially active)
active again at end of operation?
A script not leaving any drawable active after execution would be very
impolite; however, you are correct that this particular script would
not do that even if the original drawable wasn't re-activated (the
original drawable is never made inactive in this script).
The re-activation was a remnant of alternate version of the script
which also handled By Color Select. In order to perform By Color
Select in sample merged mode, it was necessary to create a temporary
layer that contained the merged image ('gimp-drawable-get-pixel' only
works with a drawable). After the By Color Select was processed, the
script deleted the temporary layer -- leaving no drawable active --
and then needed to re-activate the original active drawable.
Is there no way to get-pixel() meaning visible pixel? I understand
that this might be problematic when started from context menu of
Paths (may there be multiple views of an image with different
visiblity flags of masks/layers?), but if started from menu of Image
window, GIMP knows which view (is it what you call projection? I
found no definition in the docs) the user means...
The projection is the composited result of all of the layers,
employing all settings for the specified blend modes, opacities,
masks, and visibilities -- it is what you see in the image window.
There is no direct access to the projection contents from the PDB and
since 'gimp-drawable-get-pixel' does not provide a sample merged
mode, it would be necessary create a new layer that contains the
projection contents (in other words, do the equivalent of Layer-New
from visible).
The best approach to this would
likely be to create a new image from the drawable or projection, copy
the path to the new image, perform the walking selection along the
path, and then move the resulting selection back to the original image.
I would very much prefer to avoid this. The image is about 0.1GPix
already with a few layers, and the hardware is close to 10years old...
And: if I want to operate on one layer only, would cadr of the
result of gimp-drawable-get-pixel() suitable as argument to
gimp-by-color-select()?
I basically gave up on my attempt to create a By Color Select version
because of all of the edge cases that needed to be handled: layer
offsets and dimensions (path coordinates are relative to the image,
'get-pixel' uses the drawable coordinates), changing colorspaces (mask
and channels are grayscale, while a layer may or may not be), and
image/drawable boundaries (paths are not constrained to the image).
All of these distinctions are dependent upon whether the colors are
being sample merged, thus further complicating things.
If you wanted just a simple version which handled only a single layer
(not its mask, nor a channel) which had the same dimensions as the
image (and no offsets), and did not need to provide a sample merged
option, I could write one sometime later this evening.
___
Gimp-user mailing list
Gimp-user@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] brush precision
Oh. That's probably why I couldn't find the thread - I must've been looking in the wrong archive Thanks, Sven; I will post the suggestion there /Gary Maybe you should post that suggestion to the gimp-developer list. There was a discussion about the brush outline recently and your suggestion might turn out to be useful for that. ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
[Gimp-user] contribute to my cause
hello.. I'm creating a linux distro which is the first in my country (Dominican repolishing) but still do not have artwork, I have nothing prepared and if they can not help to create the wallpaper and boot screens like the logo . Keep in mind that the name of the distro could be even amber palm tree but can not bring myself to leave your comments about this. I'm not asking anyone to believe all this only if someone wants to help with that and to spare some time to be grateful .. because I have very little time for work and college to put myself to create the art .. Thank you all for reading this .. Happy-Word Data from the distro linuxdom.wordpress.com -- Happy-Word (via www.gimpusers.com) ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
[Gimp-user] File gamma 0.4545? And pnmtopng.
What an earth. I found that GIMP has placed file gamma 0.4545 to PNG images without my will. $ xloadimage x.png x.png is 1120x840 PNG image, color type RGB, 8 bit, file gamma 0.4545 The image is displayed too dark. The brighter image is correct because xloadimage shows the original x.ppm that way. I found this problem only now because GIMP, eog, gqview, and webbrowsers ignores the file gamma. Is it wrong to ignore the file gamma? How to delete the file gamma with GIMP or with command line converters? What convert -gamma 1.0 would do for x.png? (1) Fix the file gamma to 1.0? (2) Modify the pixel values? Similar questions about GIMP and other programs. How to configure GIMP to not set the file gamma? I have never set the gamma value. I have always wanted 1:1 correspondence between the file and the display. Who GIMP developer uses 0.4545 gamma? :-) BTW, I remade the png by not using GIMP: cat x.ppm | pnmtopng x.png $ xloadimage x.png x.png is 1120x840 PNG image, color type PALETTE, 8 bit The PNG image should be RGB, not PALETTE! Somebody should fix the pnmtopng. Juhana ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
[Gimp-user] Creating texture images?
How to convert photos taken with a cheap Canon camera to what can be used as textures in games? See GPU Gems 3 for linear space images and how they are used in the rendering. Do we know enough about how a particular camera works? How to measure how a camera works if that is necessary in the process? Juhana ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] File gamma 0.4545? And pnmtopng.
Hi, On Wed, 2009-09-30 at 20:53 +0300, Juhana Sadeharju wrote: What an earth. I found that GIMP has placed file gamma 0.4545 to PNG images without my will. $ xloadimage x.png x.png is 1120x840 PNG image, color type RGB, 8 bit, file gamma 0.4545 As far as I know PNG expects the gamma to be set to the gamma correction of the PNG file based on the screen gamma i.e. the display exponent. That would be 1/gamma then. GIMP sets the gamma value 2.2, which is the gamma value for the sRGB color space. How to configure GIMP to not set the file gamma? Do not check the checkbox labeled Save gamma in the PNG save dialog. Sven ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Creating texture images?
Juhana Sadeharju wrote: How to convert photos taken with a cheap Canon camera to what can be used as textures in games? It would depend upon the game, but unless some proprietary process is being used, any software package which would convert the images taken with the camera (probably ~.jpg with or without capability of a raw image) to the image needed in the game should do the tirck. Do we know enough about how a particular camera works? As long as the image processing software can read the images in the format from the Canon camera, and write the format needed by the game, why would how the camera works make a difference? ns ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] HOWTO: stroke a path with the current tool?
On 2009-09-30, saulgo...@flashingtwelve.brickfilms.com saulgo...@flashingtwelve.brickfilms.com wrote: A lot of thanks for helping me understand this problem. And I can't guess reasons why you first do gimp-selection-none(), then combine the orig-sel back? I assumed that you wanted to add together all of the fuzzy selections made along the path, and then combine that result with the original selection using the operation mode. To not do so would lead to some rather useless results. For example, if the operation mode were CHANNEL-OP-REPLACE and this was passed to 'gimp-fuzzy-select-full' then despite making fuzzy selections all along the path, the only thing that would matter would be the fuzzy select performed on the path's last point. Also consider what happens if the 'operation' mode were CHANNEL-OP-INTERSECT and the original selection was the entire image (if there were no selection originally then the final result would be no selection). If I merely passed the INTERSECT mode to Fuzzy Select then after the first x,y point on the path was fuzzy selected, the resulting intersection would be only that fuzzy selection. Moving to the next x,y point and the resulting selection would only be the intersection of the two Fuzzy Selects. At any point along the path -- including the last point on the path -- the resulting selection will be no larger than the intersection of that point's fuzzy selection and the one before it. I read all this, and STILL have the same question... Let me try to rephrase it... Consider two scenarios (with a particular OP of CHANNEL-OP-*), left one and right one: save-selection + delete-selection do few FuzzySelects with OP do few FuzzySelects with OP combine with saved-selection with OP load saved-selection Is there a case when these two scenarios are going to give different results? My logic is: there is no difference since a) it is enough to consider the case of one FuzzySelect; b) for one FuzzySelect there is no difference. On which step do you think my logic breaks? The projection is the composited result of all of the layers, employing all settings for the specified blend modes, opacities, masks, and visibilities -- it is what you see in the image window. There is no direct access to the projection contents from the PDB and since 'gimp-drawable-get-pixel' does not provide a sample merged mode Well, since an INDIRECT access to the projection contents IS POSSIBLE, why not allow a direct one?! I basically gave up on my attempt to create a By Color Select version because of all of the edge cases that needed to be handled: layer offsets and dimensions (path coordinates are relative to the image, 'get-pixel' uses the drawable coordinates), changing colorspaces (mask and channels are grayscale, while a layer may or may not be), and image/drawable boundaries (paths are not constrained to the image). Could you still provide your version (non-working OK), since I *need* to implement this anyway, and having some starting place would be a great help. I'm going to create a temporary small layer for each point on the path (reuse it if the next point still fits). (I already have code which does projection-copying.) If you wanted just a simple version which handled only a single layer (not its mask, nor a channel) which had the same dimensions as the image (and no offsets), and did not need to provide a sample merged option, I could write one sometime later this evening. If you would: first, let me try to write my own version based on your old attempt. And if I fail, I might try to use your offer as a rain ticket. ;-) A lot of thanks again, Ilya P.S. Unrelated: I'm trying to post to the devel list, both from GMANE, and directly. Nothing passes through. Do I need to subscribe first before posting is possible? ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
[Gimp-user] hi
I would like to stop receiveing the gimp e-mail's. Thanks ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] hi
On Wed, Sep 30, 2009 at 4:04 PM, TREY Mcatt deerslayer...@yahoo.com wrote: I would like to stop receiveing the gimp e-mail's. Thanks ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user Follow the link at the bottom of this - or any - message from the mailing list. This one: https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user Chris ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] hi
On 09/30/2009 11:04 PM, TREY Mcatt wrote: I would like to stop receiveing the gimp e-mail's. Thanks Then why don't you unsubscribe? Link can be found at the bottom of the mails / Martin -- My GIMP Blog: http://www.chromecode.com/ ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
[Gimp-user] Another Gimp/UFRaw topic
For starters, is there any good reason why UFRaw should be used for anything other than opening a RAW file before transporting it to Gimp? What I really wanted to ask was, Why, when open up an image in UFRaw and it looks great, even when zoomed in as much as allowed. However, when you sent it to Gimp via UFRaw, when you zoom into even a small amount the image is very pixelated. When or how did it become downsized or some sort of processing that might cause this to happen? Is it possible to bring in a RAW file and retain it's sharpness? Thanks for anyone's help in regards to this. -- Bryan (via www.gimpusers.com) ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Another Gimp/UFRaw topic
Bryan - Wiser heads will probably correct or refine this, but ... The 'raw' file is supposed to represent data very close to what is provided by the camera's sensor array. Before saving images in non-raw formats (JPEG, etc.) the camera performs some conversions of the image field as well as - usually - applying some compression. These conversions are irreversible and represent a compromise intended to give pleasing images of common subjects. This is crudely analogous to the processing applied to color negatives by most photo processors as they are printed - you have probably seen the quite surprising results this sometimes gives: colors gone crazy! UFRaw gives you the chance to make different assumptions and adjustments, and keeps the original image file untouched in case you want another chance. It also provides as default a compensation similar to what the camera would have done if left to its own algorithms. That's what you get if you don't intervene. If you aren't making any adjustments in UFRaw you may be just as well-off to work with [say] JPEG images out of your camera. The intermediate stage of adjusting your image in UFRaw is one of the main reasons for using RAW format in the first place. At least that's my [mis?]understanding. - Mills On Wed, 30 Sep 2009, Bryan wrote: For starters, is there any good reason why UFRaw should be used for anything other than opening a RAW file before transporting it to Gimp? What I really wanted to ask was, Why, when open up an image in UFRaw and it looks great, even when zoomed in as much as allowed. However, when you sent it to Gimp via UFRaw, when you zoom into even a small amount the image is very pixelated. When or how did it become downsized or some sort of processing that might cause this to happen? Is it possible to bring in a RAW file and retain it's sharpness? Thanks for anyone's help in regards to this. ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Another Gimp/UFRaw topic
On 2009-09-30, John Mills johnmi...@speakeasy.net wrote: If you aren't making any adjustments in UFRaw you may be just as well-off to work with [say] JPEG images out of your camera. The intermediate stage of adjusting your image in UFRaw is one of the main reasons for using RAW format in the first place. This is as far from being true as one can get. A hint: a camera uses as-much-pessimized-as-possible computer, and does RAW--JPEG conversion in a fraction of a second. RAW converter most probably uses hundreds times more powerful hardware, and takes up to minute(s) to perform convertion. Guess how the results compare... Hope this helps, Ilya ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
[Gimp-user] Another Gimp/UFRaw topic
On 2009-09-30, John Mills johnmi...@speakeasy.net wrote: If you aren't making any adjustments in UFRaw you may be just as well-off to work with [say] JPEG images out of your camera. The intermediate stage of adjusting your image in UFRaw is one of the main reasons for using RAW format in the first place. This is as far from being true as one can get. A hint: a camera uses as-much-pessimized-as-possible computer, and does RAW--JPEG conversion in a fraction of a second. RAW converter most probably uses hundreds times more powerful hardware, and takes up to minute(s) to perform convertion. Guess how the results compare... Hope this helps, Ilya I'll embellish the OP's original question for further discussion. Obviously, if you adjust in UFRaw, your 'range' of adjustments is much wider than what would be available if you were starting straight to GIMP with a camera generated JPG. In the spirit of the OP's question, if you make no adjustments in UFRAW, is there any more latitude for adjustment in the resultant JPG file (in Gimp or other editing application) than what you might get straight from the camera? Personally, I use UFRaw to fine tune the exposure (I like those blinking whatchamacallits) although, most of the time, having shot in RAW and adjusted exposure in the camera according to the histogram view, I generally already have the best exposure balance so that, if there is any blinking in UFRaw, it will show up for both overblown highlights and underexposed shadows. I might do a little noise control on some shots, and that's about it. The rest, in my view, is better handled in GIMP. It feels as though I have a lot of latitude in GIMP. It's not unusual for me to rescue details in deep shadows by adding duplicate layers in screen mode (masking out all but the shadowed areas). I finally have that process down, and it works quite well. Since I don't shoot in JPEG at all, I cannot say if the process would be greatly compromised using in camera jpegs, but someone else may be able to share some thoughts along those lines. Caruso -- Carusoswi (via www.gimpusers.com) ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
