Re: [Gimp-user] Another Gimp/UFRaw topic
On 2009-09-30, Carusoswi for...@gimpusers.com wrote: 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? This is not a very have-a-clear-answer topic. I would guess that with Canon, the answer is straightforward: the RAW-converted output would be SIGNIFICANTLY better than in-camera one in ALL respects. Dynamic range, handling of clipping, handling of noise, sharpness, etc. With cameras which use more advanced versions of the Apical Iridex hardware or firmware (starting with Sony, but Nikon is reported to be in process of catching up), the situation is not as clear. I did not see any report of RAW processor which can match Apical-style Dynamic Range Optimizations. So: there might be one respect (tonal mapping, sometimes called dynamic range) in which RAW-processed-JPEG might be not as good as in-camera one... It feels as though I have a lot of latitude in GIMP. 8-bit is good enough for minimally postprocessed images, since noise would provide sufficient dithering, both in highlights and in darks. However, significant noise reduction and/or substantial tonal mapping has a risk to make banding visible. Which makes GIMP not very suitable for such styles of photography. (Not so with the subjects I favor most, so I did not see that.) Hope this helps, 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?
Quoting Ilya Zakharevich nospam-ab...@ilyaz.org: 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? Your scenarios are identical, however, it is my opinion that more useful results are produced by treating all of the Fuzzy Selects as one selection and then combining that one selection with the original selection using the OP specified (which is distinct from your approach in the cases where the OP is replace or intersect). Well, since an INDIRECT access to the projection contents IS POSSIBLE, why not allow a direct one?! Rendering of the projection is performed as a separate process asynchronous from operations that access/manipulate the image data. The projection may not even be rendered (if there is no display associated with the image). It would be necessary for the (hypothetical) procedure which accesses the projection to trigger a re-rendering (if a valid one is not available) and wait for that rendered projection to become valid. Once the projection becomes valid, it would need to be locked so that other GIMP processes do not modify it while the data is being retrieved -- if more than one access to the projection is to be executed then the projection would need to remain locked (effectively hanging GIMP while the script is executed). It just makes much more sense to take a snapshot of the projection at a certain point and then access that snapshot thereby permitting other process -- including the projection rendering background process -- to do their thing. For this reason (though I've explained it poorly), I serious doubt you will ever see a 'gimp-projection-get-pixel' type function. 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.) http://flashingtwelve.brickfilms.com/GIMP/Scripts/Alpha/sg-select-along-path.wrk I'm not sure what shape it's in. I believe I had it working except for handling of layermasks and channels. It was at that point that I ran into problems with the drawable's mode (grayscale versus RGB...) and gave up. You also will probably want to use the fuzzy select function from my other script (the one included in this one is not the latest version). 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? Posts by unregistered people get moderated and can take a day or two before they appear. Subscribing to the list will eliminate this delay. ___ 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, Carusoswi for...@gimpusers.com wrote: 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? This is not a very have-a-clear-answer topic. I would guess that with Canon, the answer is straightforward: the RAW-converted output would be SIGNIFICANTLY better than in-camera one in ALL respects. Dynamic range, handling of clipping, handling of noise, sharpness, etc. With cameras which use more advanced versions of the Apical Iridex hardware or firmware (starting with Sony, but Nikon is reported to be in process of catching up), the situation is not as clear. I did not see any report of RAW processor which can match Apical-style Dynamic Range Optimizations. So: there might be one respect (tonal mapping, sometimes called dynamic range) in which RAW-processed-JPEG might be not as good as in-camera one... It feels as though I have a lot of latitude in GIMP. 8-bit is good enough for minimally postprocessed images, since noise would provide sufficient dithering, both in highlights and in darks. However, significant noise reduction and/or substantial tonal mapping has a risk to make banding visible. Which makes GIMP not very suitable for such styles of photography. (Not so with the subjects I favor most, so I did not see that.) Hope this helps, Ilya Ok, I want to make sure that I've asked my question clear enough before I decide that you guys have blown me away with your technological knowledge. I'm shooting in RAW and so I'm opening up a RAW file with UFRaw because without opening the file first with UFRaw, I can't get it into into Gimp for Post Processing. I hope I'm right so far. Well, after opening the RAW file in UFRaw and whether I perforn any adjustments or not in UFRaw, if I hit OK to send it to Gimp isn't it still a RAW file when it's in GIMP or has UFRaw converted it to a jpg automatically and that is why the image looks crappy in GIMP, particulairly when zoomed in on? Isn't there is only a relatively small amount of things you can do to an image in UFRaw? Which is why you'd want to get that RAW file to GIMP to be able to really do some post processing because there is only so much you can do to a jpg? -- Bryan (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] BW Tone Adjustments
In a photo book I was reading of some ways to process a black and white photo. This particular book was using Photoshop, as most do. There was a particular procedure that PS is capable of and I was wonder if that capability exists in GIMP as well. What they would do to adjust the tone for a particular color range was, in stead of using slide bars, they would click and hold in an area of which they wanted to adjust an hold down shift I believe it was, and then at the same time drag the cursor either to the right for brighter or left for darker. Of course this procedure changed everything in the photo with that same color range. Does anyone know if this can be done in GIMP? -- 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
Ilya - Thanks for your earlier note -- I am quite happy to stand corrected and your post suggests a basic experiment I can easily do: compare in-camera processed and post-processed RAW images for the same scene and settings. I'll have a limited sample to work with: my only camera delivering RAW images is a Pentax K100D, quite dated now by newer technology. On the other hand, I can compare UFRaw into GIMP and Photoshop Elements with the Pentax plug-in into PSE and (if I have a suitable intermediate format) into GIMP. At the very least I'll learn something. If I see anything surprising or interesting I may share it and hopefully get useful feedback. Anyway, there's no substitute for knowing what one's own equipment does. On Thu, 1 Oct 2009, Ilya Zakharevich wrote: On 2009-09-30, Carusoswi for...@gimpusers.com wrote: 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? This is not a very have-a-clear-answer topic. I would guess that with Canon, the answer is straightforward: the RAW-converted output would be SIGNIFICANTLY better than in-camera one in ALL respects. Dynamic range, handling of clipping, handling of noise, sharpness, etc. With cameras which use more advanced versions of the Apical Iridex hardware or firmware (starting with Sony, but Nikon is reported to be in process of catching up), the situation is not as clear. I did not see any report of RAW processor which can match Apical-style Dynamic Range Optimizations. So: there might be one respect (tonal mapping, sometimes called dynamic range) in which RAW-processed-JPEG might be not as good as in-camera one... I'm not sure I follow that, unless the sensor's bit-depth and that of the camera's RAW format are different. I'm not at the stage of getting full scale from my images: still working for consistent, decent quality prints from straight-forward subjects. - Mills ___ 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 Thu, 2009-10-01 at 07:11 -0700, Ok, I want to make sure that I've asked my question clear enough before I decide that you guys have blown me away with your technological knowledge. I'm shooting in RAW and so I'm opening up a RAW file with UFRaw because without opening the file first with UFRaw, I can't get it into into Gimp for Post Processing. I hope I'm right so far. Well, after opening the RAW file in UFRaw and whether I perforn any adjustments or not in UFRaw, if I hit OK to send it to Gimp isn't it still a RAW file when it's in GIMP or has UFRaw converted it to a jpg automatically and that is why the image looks crappy in GIMP, particulairly when zoomed in on? Well you would need to Sharpen the RAW image, JPG's are normally sharpened in camera but not so with RAW. In fact even most JPG images could benefit from some sharpening. Cheers George ___ 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
Well thank you Simon, even though you didn't have the answer at least I don't feel alone on this issue. I'll see if I can find anything more in a UFRaw site. Much obliged. -Bryan There was nothing wrong with your question: It was perfectly clear. What was strange is that everyone on the list who replied, did not answer your question but answered the question that thought that they had read. Perhaps, they simply do not want to answer it, or the explanation missed its mark and had to be reformatted to that of the layman :) Myself included. I had a quick look on the UFraw website. It briefly explains how it saves the file from the programme to the disc, but does not explain in which format it passes the file to Gimp. Sorry, but I don't know the answer. You could try asking on a UFraw mailing list if there is one, or the UFraw forum: http://sourceforge.net/projects/ufraw/forums/forum/434060 Simon. Bryan wrote: On 2009-09-30, Carusoswi for...@gimpusers.com wrote: 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? This is not a very have-a-clear-answer topic. I would guess that with Canon, the answer is straightforward: the RAW-converted output would be SIGNIFICANTLY better than in-camera one in ALL respects. Dynamic range, handling of clipping, handling of noise, sharpness, etc. With cameras which use more advanced versions of the Apical Iridex hardware or firmware (starting with Sony, but Nikon is reported to be in process of catching up), the situation is not as clear. I did not see any report of RAW processor which can match Apical-style Dynamic Range Optimizations. So: there might be one respect (tonal mapping, sometimes called dynamic range) in which RAW-processed-JPEG might be not as good as in-camera one... It feels as though I have a lot of latitude in GIMP. 8-bit is good enough for minimally postprocessed images, since noise would provide sufficient dithering, both in highlights and in darks. However, significant noise reduction and/or substantial tonal mapping has a risk to make banding visible. Which makes GIMP not very suitable for such styles of photography. (Not so with the subjects I favor most, so I did not see that.) Hope this helps, Ilya Ok, I want to make sure that I've asked my question clear enough before I decide that you guys have blown me away with your technological knowledge. I'm shooting in RAW and so I'm opening up a RAW file with UFRaw because without opening the file first with UFRaw, I can't get it into into Gimp for Post Processing. I hope I'm right so far. Well, after opening the RAW file in UFRaw and whether I perforn any adjustments or not in UFRaw, if I hit OK to send it to Gimp isn't it still a RAW file when it's in GIMP or has UFRaw converted it to a jpg automatically and that is why the image looks crappy in GIMP, particulairly when zoomed in on? Isn't there is only a relatively small amount of things you can do to an image in UFRaw? Which is why you'd want to get that RAW file to GIMP to be able to really do some post processing because there is only so much you can do to a jpg? -- 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] hi
On Wed, Sep 30, 2009 at 4:10 PM, Martin Nordholts ense...@gmail.com wrote: 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 And in the headers of every message, and in the e-mail he received when joining the list... :) ___ 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-10-01, John Mills johnmi...@speakeasy.net wrote: With cameras which use more advanced versions of the Apical Iridex hardware or firmware (starting with Sony, but Nikon is reported to be in process of catching up), the situation is not as clear. I did not see any report of RAW processor which can match Apical-style Dynamic Range Optimizations. So: there might be one respect (tonal mapping, sometimes called dynamic range) in which RAW-processed-JPEG might be not as good as in-camera one... I'm not sure I follow that, unless the sensor's bit-depth and that of the camera's RAW format are different. Sensor bit-depth is an absolutely bogus metric (unless one uses it as an indicator of amount of RD, which may correlate with other, important issues; such as read noise and correlation of noise of nearby pixels). If RAW files were compressed to 8-bit gamma=2, they won't loose practically any information; 9-bit would be a significant overkill (assuming full-well about 70K electrons, as typical large-sensor dSLRs have). gamma=2.2 is very similar. (The special significance of quantization after gamma=2 is that Poisson noise becomes constant-width, thus dithers in dark parts as well as in highlights.) If you do not know what DRO is, look on dpreview, and/or look for examples on Apical site. Ilya ___ 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-10-01, Bryan for...@gimpusers.com wrote: Well, after opening the RAW file in UFRaw and whether I perforn any adjustments or not in UFRaw, if I hit OK to send it to Gimp isn't it still a RAW file when it's in GIMP or has UFRaw converted it to a jpg automatically and that is why the image looks crappy in GIMP, particulairly when zoomed in on? I have no idea how your communication channel is configured. I would use sRGB 8-bit TIFF (do not know whether deflation makes sense [called ZIP in GIMP]) with no downscale, or at most to-75% downscale (to-65% should be OK with most pocket cameras). Isn't there is only a relatively small amount of things you can do to an image in UFRaw? Probably true (never used UFRaw ;-). On the other hand, AFAIK, GIMP has practically no tools to do photo-related work either (one can't even apply a curve to L channel without going through a hundred hoops). Hope this helps, 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?
On 2009-10-01, saulgo...@flashingtwelve.brickfilms.com saulgo...@flashingtwelve.brickfilms.com wrote: 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? Your scenarios are identical, however, it is my opinion that more useful results are produced by treating all of the Fuzzy Selects as one selection and then combining that one selection with the original selection using the OP specified (which is distinct from your approach in the cases where the OP is replace or intersect). Sorry for being so obtuse, but I STILL do not see in WHAT WAY are they distinct from the left scenario? Rendering of the projection is performed as a separate process asynchronous from operations that access/manipulate the image data. The projection may not even be rendered (if there is no display associated with the image). It would be necessary for the (hypothetical) procedure which accesses the projection to trigger a re-rendering (if a valid one is not available) and wait for that rendered projection to become valid. Once the projection becomes valid, it would need to be locked so that other GIMP processes do not modify it while the data is being retrieved -- if more than one access to the projection is to be executed then the projection would need to remain locked (effectively hanging GIMP while the script is executed). It just makes much more sense to take a snapshot of the projection at a certain point and then access that snapshot thereby permitting other process -- including the projection rendering background process -- to do their thing. For this reason (though I've explained it poorly), I serious doubt you will ever see a 'gimp-projection-get-pixel' type function. Thanks a lot. I'm sure that if such implementation details were more documented, people would bother developers with much less questions... :-( http://flashingtwelve.brickfilms.com/GIMP/Scripts/Alpha/sg-select-along-path.wrk Thanks! Ilya ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] hi
Hi Martin, On 30 Sep 09 22:10 Martin Nordholts ense...@gmail.com said: Then why don't you unsubscribe? Link can be found at the bottom of the mails Maybe because TREY does not see the link. When I opened TREY's mail there was no footer visible, but the message was marked as having an attachment. Turns out there were two. When I opened the first of these (text/html) it echoed exactly the plain text version I was seeing - no footer. Finally I opened the other (text/plain) and the footer was revealed. In my plain text mailer I have to go to a lot of hassle to read such attachments. I suffered the same issues with Paul Hartman's response in this thread. All I'm saying is that you can't rely on people seeing those footers. Sorry not to be talking about the GIMP. Time to shut up, methinks! Greg Chapman http://www.gregtutor.plus.com Helping new users of KompoZer and The GIMP ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] hi
On Thu, Oct 1, 2009 at 4:44 PM, Greg Chapman gregtu...@yahoo.co.uk wrote: Hi Martin, On 30 Sep 09 22:10 Martin Nordholts ense...@gmail.com said: Then why don't you unsubscribe? Link can be found at the bottom of the mails Maybe because TREY does not see the link. When I opened TREY's mail there was no footer visible, but the message was marked as having an attachment. Turns out there were two. When I opened the first of these (text/html) it echoed exactly the plain text version I was seeing - no footer. Finally I opened the other (text/plain) and the footer was revealed. In my plain text mailer I have to go to a lot of hassle to read such attachments. I suffered the same issues with Paul Hartman's response in this thread. I apologize, I accidentally sent a multipart text/HTML message. I normally operate in plain text mode and must have switched and forgotten to change it back. Sorry! Normally the footer should be visible. Martin uses a signature, maybe the fact that the footer is beneath the signature delimiter caused it to be hidden for you in that case... just guessing. :) Paul ___ 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
There was nothing wrong with your question: It was perfectly clear. What was strange is that everyone on the list who replied, did not answer your question but answered the question that thought that they had read. Perhaps, they simply do not want to answer it, or the explanation missed its mark and had to be reformatted to that of the layman :) Myself included. Actually, we're all making what I think are sincere efforts to contribute comments that might help answer the OP's question. I never gave any thought to what format UFRaw sends to Gimp, but I bet it's not some Gimp native format, as I doubt Gimp has one. Gimp saves xcf files which, if my understanding is correct, are equivalent to edit decision files in video applications, or .indd files in Adobe's InDesign page layout application. These are, for the most part, reference files that keep track of the changes you are trying to make to an image (in the case of photo editing apps). There is no image format until you save the file in Gimp. That's why, if you try to print a non-flattened image, Gimp complains and then offers to export it for you. I also erred in my previous post about UFRaw sending jpegs to Gimp. Actually, I'm not certain what sort of file it sends to Gimp, but, I'm guessing it's starts out as (or with components capable of being saved as) an 8-bit Tiff. I believe that, if you use the stand alone version of UFRaw, it will give you a choice of file types when you 'save as.' . . . and that brings us back to what I read as the OP's central question. In terms of image quality, are we better off making most of our adjustments in Gimp after having used UFRaw to convert the raw image, or would we be wiser to make whatever adjustment available to us in UFRaw before sending the image to Gimp. I would bet that, in my case, it's a moot point, as I will get acceptable results either way that are close enough, given the uses to which I will put the images, that my viewers would not discern between either approach. Theoretically, however, I'm guessing that there may be a difference, and I'd be curious to hear from someone with the technical depth to offer some enlightenment. This has turned out to be quite an interesting thread. I'm glad I took the time to read and respond. Thanks, OP. 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
Re: [Gimp-user] hi
On Thursday 01 October 2009, Paul Hartman wrote: On Thu, Oct 1, 2009 at 4:44 PM, Greg Chapman gregtu...@yahoo.co.uk wrote: Hi Martin, On 30 Sep 09 22:10 Martin Nordholts ense...@gmail.com said: Then why don't you unsubscribe? Link can be found at the bottom of the mails Maybe because TREY does not see the link. When I opened TREY's mail there was no footer visible, but the message was marked as having an attachment. Turns out there were two. When I opened the first of these (text/html) it echoed exactly the plain text version I was seeing - no footer. Finally I opened the other (text/plain) and the footer was revealed. In my plain text mailer I have to go to a lot of hassle to read such attachments. I suffered the same issues with Paul Hartman's response in this thread. I apologize, I accidentally sent a multipart text/HTML message. I normally operate in plain text mode and must have switched and forgotten to change it back. Sorry! Normally the footer should be visible. Martin uses a signature, maybe the fact that the footer is beneath the signature delimiter caused it to be hidden for you in that case... just guessing. :) Paul One last word, although these things tend to get a life of their own. This is exactly the reason I like kmail, it ignores the -- sig delimiter, and I do see the senders sig, along with the rest of the footers messages. I personally would consider an email agent that hid that stuff, broken. But that is just one old mans opinion. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) The NRA is offering FREE Associate memberships to anyone who wants them. https://www.nrahq.org/nrabonus/accept-membership.asp Witch! Witch! They'll burn ya! -- Hag, Tomorrow is Yesterday, stardate unknown ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
