Results 1 to 16 of 16

Thread: Gimp User's

  1. #1

    Gimp User's

    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

  2. #2
    Moderator Donald's Avatar
    Join Date
    Feb 2009
    Location
    Glenfarg, Scotland
    Posts
    21,402
    Real Name
    Just add 'MacKenzie'

    Re: Gimp User's

    Haven't seen that site before. Thanks, Carl. Looks good.

  3. #3
    Dukatum's Avatar
    Join Date
    Feb 2013
    Location
    in Your mind
    Posts
    32

    Re: Gimp User's

    Very nice. Thanks for the link.
    Being a Linux user I am very pro-GIMP and try to hold back my anti-photoshopness it 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)

  4. #4
    GiacomoD's Avatar
    Join Date
    Jan 2013
    Location
    Florence, Italy
    Posts
    168
    Real Name
    Giacomo

    Re: Gimp User's

    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

  5. #5

    Join Date
    Nov 2009
    Location
    Provence, France
    Posts
    988
    Real Name
    Remco

    Re: Gimp User's

    Quote Originally Posted by GiacomoD View Post
    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).

  6. #6
    Dukatum's Avatar
    Join Date
    Feb 2013
    Location
    in Your mind
    Posts
    32

    Re: Gimp User's

    Quote Originally Posted by GiacomoD View Post
    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
    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.

  7. #7

    Join Date
    Nov 2009
    Location
    Provence, France
    Posts
    988
    Real Name
    Remco

    Re: Gimp User's

    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.

  8. #8
    GiacomoD's Avatar
    Join Date
    Jan 2013
    Location
    Florence, Italy
    Posts
    168
    Real Name
    Giacomo

    Re: Gimp User's

    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...

  9. #9

    Join Date
    Aug 2011
    Location
    Leiden, Netherlands
    Posts
    185
    Real Name
    Hero

    Re: Gimp User's

    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.

  10. #10

    Join Date
    Nov 2009
    Location
    Provence, France
    Posts
    988
    Real Name
    Remco

    Re: Gimp User's

    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

  11. #11

    Join Date
    Aug 2011
    Location
    Leiden, Netherlands
    Posts
    185
    Real Name
    Hero

    Re: Gimp User's

    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.

  12. #12
    ajohnw's Avatar
    Join Date
    Aug 2012
    Location
    S, B'ham UK
    Posts
    3,337
    Real Name
    John

    Re: Gimp User's

    Quote Originally Posted by Dukatum View Post
    Very nice. Thanks for the link.
    Being a Linux user I am very pro-GIMP and try to hold back my anti-photoshopness it 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)
    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
    -

  13. #13
    ajohnw's Avatar
    Join Date
    Aug 2012
    Location
    S, B'ham UK
    Posts
    3,337
    Real Name
    John

    Re: Gimp User's

    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
    -

  14. #14

    Join Date
    Nov 2009
    Location
    Provence, France
    Posts
    988
    Real Name
    Remco

    Re: Gimp User's

    Quote Originally Posted by Hero View Post
    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 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.

  15. #15

    Join Date
    Feb 2013
    Location
    Georgia, USA
    Posts
    11
    Real Name
    Mir

    Re: Gimp User's

    I just started using GIMP and must say I am loving it! Thanks so much for the helpful links

  16. #16

    Join Date
    Jul 2011
    Location
    Lake Ambulalakaw, Mt. Pulag, Benguet
    Posts
    1,026
    Real Name
    Victor Nimitz

    Re: Gimp User's

    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •