Re: [Gimp-user] Bits per channel
On Tuesday 29 September 2009 07:06:52 am Phil Labonte wrote: have looked online on the Gimp site and I am not clear if Gimp supports 16 or 24 or 32 bit images? as far as i know, GIMP processes colors with 16 bit precision when use GEGL is enabled from the colors menu. work is in progress to make it possible to fully support opening saving of 16 bit (or higher?) images. -- ys phani. ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Bits per channel
Am Dienstag, den 29.09.2009, 11:48 +0530 schrieb phanisvara das: On Tuesday 29 September 2009 07:06:52 am Phil Labonte wrote: have looked online on the Gimp site and I am not clear if Gimp supports 16 or 24 or 32 bit images? as far as i know, GIMP processes colors with 16 bit precision when use GEGL is enabled from the colors menu. work is in progress to make it possible to fully support opening saving of 16 bit (or higher?) images. Wrong. GEGL uses 32 bit floating point numbers, that gives 128 bit per coloured pixel (with alpha channel). Using 16 bit integers, the maximum intensity of a color channel is 0x. This may lead to temporarily color cropping during multi-step operations, even if the final channel intensity is below 0x. By using floating point numbers, no temorarily cropping will occur. Joerg ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Bits per channel
On Tuesday 29 September 2009 01:05:40 pm Joerg Bergmann em...@jbergmann.de wrote: as far as i know, GIMP processes colors with 16 bit precision when use GEGL is enabled from the colors menu. work is in progress to make it possible to fully support opening saving of 16 bit (or higher?) images. Wrong. GEGL uses 32 bit floating point numbers, that gives 128 bit per coloured pixel (with alpha channel). Using 16 bit integers, the maximum intensity of a color channel is 0x. This may lead to temporarily color cropping during multi-step operations, even if the final channel intensity is below 0x. By using floating point numbers, no temorarily cropping will occur. thank you for clarifying that. i've read about it a while ago and didn't remember correctly. NB: this reply arrived at my personal email address. that doesn't bother me, but other list users won't see it; seems your email client defaults to the wrong adress... -- phani. ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Bits per channel
Working with 16 bit per channel images will be great! 16 bits per channel is essential when working with high dynamic range (HDR) images. What is the timeline for 2.10/3.0? Martin Nordholts wrote: On 09/29/2009 03:36 AM, Phil Labonte wrote: Hello, I have looked online on the Gimp site and I am not clear if Gimp supports 16 or 24 or 32 bit images? Can someone point me to the correct answer for Gimp 2.6.7 Hi GIMP 2.6 does not and GIMP 2.8 will not work with higher than 8 bits-per-channel images. GIMP 2.10/3.0 will. BR, Martin ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] adjusting a horizon
On 09/28/2009 02:29 AM, Jude T. wrote: Jude T. schreef: I know I have seen, in the Gimp Manual, a way of adjusting a photo that's been taken on a bit of a slant - for instance a photo of a window. I have a photo where my horizon is on a slant. Can anyone remind me where in the Gimp manual it tells me how to adjust this? many thanks for any help! Jude Tools Transformation Rotate Andre Thanks Andre.I'll play with this feature. It's not the way of adjusting an image that I saw before - where there was a picture of a window. But I'm sure it will do the job. Many thanks. Jude Also, check out the Steinort and DeMartin's MeetTheGimp videos - - - meetthegimp.org ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Bits per channel
On Tue, Sep 29, 2009 at 9:13 PM, Ken Warner kwarner...@verizon.net wrote: Working with 16 bit per channel images will be great! 16 bits per channel is essential when working with high dynamic range (HDR) images. What is the timeline for 2.10/3.0? I believe you'll find that you can only get a meaningful timeline for eg. 2.10 after 2.8 is released. Looking ahead further than 'the release we are currently working towards' is unreliable, especially since all development on GIMP is done by unpaid volunteers. ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Gimp 2.6.7 install on Centos 5.3
On Friday 25 September 2009, Greg S. wrote: This is the 3rd time I have posted this item and it has not appeared in the forum. Has anyone installed gimp 2.6.7 on Centos 5.3 or Redhat EL5. I have searched the net and there appears to be no rpm's for the above OS's. Has anyone got any ideas please. Since the universe abhors an un-answered question I'll give it a shot, As I'm sure you know both of those distributions are aimed at long term stability w/ proven applications. I've just recently installed a centos 5.3 system and believe the gimp shipped w/ it is 2.2. Having said that I'm going to suggest that the only reliable way is to build from source, and that will probably mean finding and meeting dependencies first. Very likely building them (and their dependencies) from source as well. If you use gnome as a desktop this could lead to breakage of other gnome packages. I don't think it will be really difficult (I'm guessing) but it really hinges on the dependencies. If I am right about centos shipping w/ gimp 2.2 then the gtk version in centos could give you problems (as well as gegl and babl). If you really need the newest gimp then another distribution or virtualization may be a better choice. centos 5.3 is well supported by xen, and I would guess because of its enterprise orientation vmware, virtualbox and others would also have good support ( although I am unfamiliar w/ those in respect to Centos) I have also pulled the packages from the git server. gegl, babl and gimp. need help. regards greg HTH see ya -- dh ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] this is a test[if someone can answers]
elekis ele...@gmail.com writes: hi, just a little test, cause it's a second time I recieve a respond like that and that I m not in the archive. This is the Spam Virus Firewall at bc4.EECS.Berkeley.EDU. I'm sorry to inform you that the message below could not be delivered. When delivery was attempted, the following error was returned. gimp-user@lists.xcf.berkeley.edu: host lists-mx0.xcf.berkeley.edu[128.32.112.242] said: 452 Insufficient system storage (in reply to MAIL FROM command) Final-Recipient: rfc822; gimp-user@lists.xcf.berkeley.edu Action: failed Status: 4.0.0 Diagnostic-Code: X-Spam--Virus-Firewall; host lists-mx0.xcf.berkeley.edu[128.32.112.242] said: 452 Insufficient system storage (in reply to MAIL FROM command) Sometimes yes, to me. Berkeley's firewall odd, i think. Sincerely, -- He didn't order you to tell me all the other things? You still don't understand. If you told Michael what I've told you today, I'm a dead man. You and the children are the only people on this earth he couldn't harm. -- Kay Adams and Tom Hagen, Chapter 32, page 443 ___ 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?
[Repost after a list resurrection] On 2009-09-15, saulgo...@flashingtwelve.brickfilms.com saulgo...@flashingtwelve.brickfilms.com wrote: a Script-fu which does this for Fuzzy selections; the command is added to the context menu raised by right-clicking on a path in the Paths Dialog. The script can be retrieved from http://flashingtwelve.brickfilms.com/GIMP/Scripts/Temp/sg-fuzzy-select-along-path.scm I'm confused on why gimp-vectors-set-visible() is used. Any hint? And I can't guess reasons why you first do gimp-selection-none(), then combine the orig-sel back? And why do you need to set the drawable (which was initially active) active again at end of operation? Doing similarly for the Select By Color tool is possible, but would require a more complicated script owing to the fact that 'gimp-drawable-get-pixel' can not directly fetch from the projection, and that working with channels or masks would require some massaging of the colors retrieved with 'gimp-drawable-get-pixel' so that it can be used by 'gimp-by-color-select'. 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 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()? Thanks, Ilya ___ 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?
[Repost after a list resurrection] On 2009-09-19, Jason van Gumster ja...@handturkeystudios.com wrote: Suggestion: Would it be possible as you walk the path, to compare each pixel to prior and if they are the same to within the threshold tolerance skip that pixel and proceed to next? My theory being that if two adjacent pixels on a path are within threshold tolerance of each other then fuzzy select on either is the same as fuzzy select on both. Even more simple: Couldn't you use gimp-selection-value to test whether the specified pixel is already in the current selection as you walk the path? If it is, then you can skip that pixel and move on to the next one. If you do not mind that the result is going to be majorly different - maybe. *I* think that for best result, one needs an additional *relative* threshold. E.g., if main threshold is 12, and relative is 30%, then one would skip pixels which differ from a preceeding one by less than about 4. If this relative threshold is close to 100% (which is essentially what you recommend), then the result will be quite different comparing to one with low threshold. Yours, Ilya ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
