I was looking for something else and stumbled upon this site. Hope that it will be useful to some of you who use the Gimp.
http://www.2expertsdesign.com/tutori...pful-tutorials
I was looking for something else and stumbled upon this site. Hope that it will be useful to some of you who use the Gimp.
http://www.2expertsdesign.com/tutori...pful-tutorials
Haven't seen that site before. Thanks, Carl. Looks good.
Very nice. Thanks for the link.
Being a Linux user I am very pro-GIMP and try to hold back my anti-photoshopnessit is honestly a great piece of software and works well on Win/Mac/Linux, and now they are introducing GEGL which will hopefully mean 16bit TIFF files (currently stuck with 8bit)
Thank you for the link, Carl.
I take advantage of this post to mention this link also, I found it quite useful
http://graphicssoft.about.com/lr/gim...als/1591774/1/
Rob, I'm presently working with the 2.6 version, it has the option "If possible, use GEGL", that sound a bit mysterious to me... what does "If possible" means? When it's not possible? is it a matter of image format?
Most likely, I should upgrade to the 2.8 version
Giacomo
From what I found, filters and scripts need to be written to use GEGL, so older versions of those won't use it. And perhaps (GEGL being marked as experimental for GIMP 2.6) there are some internal operations that don't use it.
It shouldn't have anything to do with the format your image is stored in (that is translated to GIMP's internal format on loading anyway), it might have to do with the mode you use (8 bit/channel colour or gray scale, or indexed), but for photo work you'd only use 8 bit/channel colour (or perhaps gray scale).
I believe it also relies on your hardware (or maybe the drivers for them) supporting the acceleration used with GEGL. For example if you have OpenCL based hardware, then this should support GEGL, forcing the Graphics Processing Unit (GPU) to do some of the hardwork, which will result in much faster performance. I don't know much about it to be honest, just more aware of it, and understand it to be an advantage for improving GIMP and various other tools. I believe it was originally aimed for GIMP but will be used wider spread I guess.
http://gimpfoo.de/2012/04/17/goat-invasion-in-gimp/ could explain why GEGL use is not complete in GIMP (up to v2.8). I wouldn't expect OpenCL be required, as its support is still marked as experimental.
Thank you Rob and Remco
For what I can see on my computer, working with a "normal" full resolution (5184*3456) 8bit RGB image, the processing speed is not too bad, with the exception of a few filters. I suppose that the advantages of using GEGL can become noticeable when working with 16 or 32 bit images.
In any case, it looks that it's something beyond my present capabilities.
Waiting for Gimp 3.0...![]()
You don't need 16/32 bit/colour images for GEGL to have an advantage. 32bit calculations on even a 8 bit/colour image can have quite a few positive results. First thing that comes to mind is when using 32bit floating point calculations is the 'huge' amount of decimals you have at your disposal. This eliminates a lot of rounding off, which in turn will eliminate or at least reduce nasties like banding.
That is only true when combining layers (there's a very nice test somewhere showing this).
However, you still can get banding when you have to stretch contrast for instance (i.e.
curves or levels tool, local contrast enhancement). Floating point cannot give you the
missing levels, so with these you will get gaps between levels (holes in the histogram).
edit: see http://wiki.meetthegimp.org/doku.php?id=bitdepth for
a demonstration of this.
Now, you'll get those gaps with both 16- and 8-bit images. But display formats only need
8 bit colour depth. That means that when editing in 8-bit, those gaps will still be there in
the display version. With 16-bit, the conversion will remove the gaps (unless you really
stretched the histogram to the breaking point): a zone of 256 levels will be collapsed into
one level when reducing the bit depth, so any gaps in such a zone will disappear.
So, yes, GEGL has an advantage even for 8-bit images, but it doesn't remove the need
for 16-bit editing. Both are needed, but for different parts of the editing process.
Btw, that also means that 16-bit editing is less useful when starting from an 8-bit
image (e.g. jpeg)
Last edited by revi; 14th February 2013 at 06:16 AM. Reason: added URL
Remco: Those gaps only occur when you stretch the gammuth. I didn't say anything about stretching the gammuth.
What I tried to explain is when you do complex calculations with lots of steps you often have intermediate outcomes with lots of decimals. If you only have 8 bits of space to hold these values, those decimals will fall of the end with every step.
On the other hand if you use a 32bit floating point container to do the maths, you can keep these decimals until the final outcome and only then round off and give back a 8bit value. It might not seem like much, but it can make decide whether a pixel becomes 126, 127 or even 128 ( the main cause of banding with 8bit calculations).
It's not for nothing that a plumber bending copper pipe in complex shapes uses pi as 3.14159 instead of 3.14 for his calculations. After 5 or 6 bends his calculations can be off by quite a few mm, which can make his work not fit where it's supposed to.
So that's why you want a 32bit container to do the maths even if the outcome is only 8bit.
I use Linux too. Have a look at Fotoxx. Floating point colour and it will do most of the things you are likely to want to do very quickly. There are a set of video tutorials on youtube as well. It has interesting plugins. They take the form of entire programs. It exports to them and when they are closed via just a save Fotoxx picks them up again. I use Hugin,Photivo and the Gimp as plugins. Rawtherapee is also there. I don't generally use the gimp now and if I do it's usually the last thing I use. Photivo is an interesting processing package all on it's own also a very good source of icc files for cameras. I use Argyll and a gui program for monitor calibration as it is far more comprehensive than the software that comes with the usual calibrator.
Gimp has been going TIFF for a long long time. I suspect most of the software is needs will appear in apps like digicam 1st. That is another rather interesting program. It would make more sense for them to go 32bit floating point colour really. Wouldn't surprise me if they do at some point.
John
-
Forgot add that I found monitor calibration essential and applied it system wide. The gui for argyll makes that easy. This may mean that the icc files then has to be installed in any other app such as Photivo that uses it's own colour management. It was that package that convinced me that I needed to calibrate my monitor. Gimp can default to system wide and some other packages don't have there own colour management so system wide is the best place to put it.
Fotoxx uses layers but creates, uses and destroys them as needed all by itself. I generally use ufraw for raw and save as tiff but have been meaning to contact the author of both to get round ufraw export to fotoxx not working and fotoxx not allowing raw conversion parameters to be set. To be honest though there isn't much difference in converting directly from fotoxx but sometimes it is better to do it directly with ufraw.
All of these packages with the exception of Fotoxx are available for windows and mac, also power mac in some cases. The argyll colour management will work with most calibrators and spectometers. The nice aspect is it retains the the same facilities using either. There is none of this well this is how your photo looks now. You just run a calibration check which will show the colour errors were ever they are.
John
-
I think we are talking about different situations here. Let's forget gamut for now, it is another matter entirely (where
16-bit would have an advantage as well). I was just talking about operations that stretch the contrast, either locally
or globally (as you do with the levels and curve tools). Note that correcting white balance also falls in this category!
For example, if you want to pull details out of a shadow part of the image, you could end up doubling the values for
the lightest part. Say you need to stretch the lower 10% of your histogram. That means we have initial values
0-25 for a 8-bit image, 0-6500 for a 16-bit image. Double that, and we end up with ranges of 0-50 and 0-13000, resp.
In both cases, we'll only have the even values within those ranges, i.e. gaps in the histogram.
But: for display we go back to 8-bit only. If we did our editing in 8-bit, that's easy, no conversion. And we'll still have
the gaps in the histogram. In 16-bit, we will have to bin our 16-bit values to reduce the bit depth. That means grouping
ranges of 256 values to get one 8-bit value. So, even though we start with an image where only even values are present,
the 8-bit version will have all values present => no more gaps in the histogram.
Note that the calculations in this precise case are exact even in integer math, so rounding losses do not come in play.
But even in not so nice situations, if you stretch contrast, you'll profit from 16-bit. And the problem here is not
loss of precision, but not having enough information at the start: in the 8-bit case, any operation that stretches
contrast will leave gaps in the histogram.
One moderate operation will not lead to visible degradation, but several could accumulate: white balance correction,
black and white point adjustment, applying a curve to change global contrast, then a touch of local contrast
enhancement, ... you get the picture.
And I agree that the floating point becomes really important when, as you say, you are doing complex calculations
with several steps. A typical case of that is combining layers, especially when using gray-scale masks.
I do know the problem of rounding errors: I've been trained as a research chemist, and error calculations were
a part of the job. We were also taught that high precision constants are nice, but only work if your measurements
are precise enough
So using 32-bit floating point internally is good, but not sufficient for at least one common type operation.
Otoh, most demonstrations of why you need floating point or 16-bit editing use rather extreme situations. We've all seen
very good images produced from edited jpegs. So for best results you'll need floating point calculations on a 16
bit/channel image, but you can get good results with a simple old-fashioned 8 bit/channel editor.
I just started using GIMP and must say I am loving it! Thanks so much for the helpful links![]()
Hi,
here are useful tips if you want to use your mouse scroll to change
( increase/decrease) GIMP brush size.
http://www.youtube.com/watch?v=Ty_5rWwtwjE
https://www.youtube.com/watch?v=rAV8doK69Eo
HTH