On Mon, Mar 7, 2011 at 2:34 PM, Debi Rapson wrote:

Can you point me in the direction of where I would go to get GOOD tutorial information about GIMP so that I can properly teach it?

I'm a fan of Rolf's tutorials:
http://meetthegimp.org/

HTH,
Chris

Hi,

Glad to hear a school is considering using GIMP - when I learned in school they tried only photoshop ad other commercial stuff.

*The* reference is the official documentation, which is very very detailed as a reference - http://docs.gimp.org/ The tutorials for image retouching (and other stuff), on the main website, should provide a very good basis - http://www.gimp.org/tutorials/

I know that in the past (before I started using GIMP) "Grokking the GIMP" was considered a very good book on GIMP, and the good part is that it's available online! http://gimp-savvy.com/BOOK/index.html Many of the screenshots are outdated, and the ui changed a bit, but as a reference for how to do things, it can be great.

Now, if we want more "modern" stuff (since some of the things above are outdated(, that children will consider cool, I'd try any of the many tutorial sites on the web, for tutorials about specific effects. I started with gimpusers - http://www.gimpusers.com/tutorials and GimpTalk http://www.gimptalk.com/forum/ GimpTalk was (and probably is) the biggest GIMP forum on the web, it has more resources than you can imagine. it may require lots of filtering, but it has some high quality tutorials.

If you need anything specific, feel free to ask on here (or better, on the the gimp-users mailing list - see http://www.gimp.org/mail_lists.html), or on the GIMP chat (see http://www.gimp.org/irc).

Good luck! ~LightningIsMyName

On Mon, Mar 7, 2011 at 10:34 PM, Debi Rapson wrote:

Our school system appears to be headed for using GIMP as a way of teaching our students about graphics.

Can you point me in the direction of where I would go to get GOOD tutorial information about GIMP so that I can properly teach it?

Can you point me in the direction of a list of places that actually use GIMP for photo retouching and graphics creation. We are trying to give our kids real-world skills and we need to be able to point to real places that are using GIMP for photo retouching and graphics resolution. If I am going to teach using this software I need as much ammunition as possible to make this seem exciting and something that the kids will WANT to learn to use.

Thank you.

Debi Rapson Memorial High School
Art & Technology Dept
603-624-6378

_______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Our school system appears to be headed for using GIMP as a way of teaching our students about graphics.

Can you point me in the direction of where I would go to get GOOD tutorial information about GIMP so that I can properly teach it?

Can you point me in the direction of a list of places that actually use GIMP for photo retouching and graphics creation. We are trying to give our kids real-world skills and we need to be able to point to real places that are using GIMP for photo retouching and graphics resolution. If I am going to teach using this software I need as much ammunition as possible to make this seem exciting and something that the kids will WANT to learn to use.

If I might give a piece of advice: if you're about to teach some real-world skills, try to be as much software agnostic as possible. Most of the tools and ideas in graphics editing are in fact common and present in different applications, so if you'll put pressure on learning “the way of thinking” rather than on “go to the X menu and choose Y tool” you'll win. Maybe some examples will help clarify what I mean:

• If you talk about keyboard shortcuts, try to lure your students into experimenting with them (customizing, discovering new ones etc.) instead of just listing existing shortcuts and closing the subject :). • If you talk about e.g. image tonal adjustment try to move (if possible) to using “curves” as soon as possible. It's one of the most universal tools out there and one of the most powerfull to that. • If possible, make your students do the same task, using similar tools but in different applications. This should lessen the possibility of one's sticking to one-app-way-of-doing-things (much like using strange variable names on math ;)).
• If possible, don't take rundowns on the contents of menus. Instead choose consecutive exercises to be practical, to use each time some new tools and to emphasize method rather than click-here-to-get-that-ism.
• Be extra careful about teaching filters. One's natural tendency, I think, is to use different filters extensively and aggressively in one's works. The trick is to show your students how to use filters to enhance their images in nondestructive way. • If possible, leave some subjects unsaid and let your students search their own way of getting demanded result. Only after they're done show them (again: if possible and most of the time possible it is) a couple of different solutions (won't leave your student with “I did it wrong way” feeling). Also, try to survey your students about their ways of completing the task–they can be interesting and non-standard. • Always try to explain, in comparative manner, why this or that tool or filter was used, e.g.: “it's faster to use X”, “it's safer to use X” and so on.
• Encourage your students to use internet to find tutorials and solutions.

Well… sorry for such a long list. I work for a small publishing house and I'm using most of these tips when I'm to take care of some interns (which happens once in a couple of months). I put these points here only because I truly hope they'll be of help to you, so please, don't take me as a pompous prick ;), even 'though they may sound “ex cathedra”.

My best regards! thebodzio

Grokking the GIMP is good, but is rather venerable at this point. Two of my favorites are:
http://www.amazon.com/Beginning-GIMP-Professional-Akkana-Peck/dp/1430210702/ref=sr_1_2?ie=UTF8&qid=1299561503&sr=8-2 and
http://www.amazon.com/GIMP-2-6-Photographers-Editing-Software/dp/1933952490/ref=sr_1_1?ie=UTF8&qid=1299561503&sr=8-1

On Mon, Mar 7, 2011 at 12:34 PM, Debi Rapson wrote:

Our school system appears to be headed for using GIMP as a way of teaching our students about graphics.

Can you point me in the direction of where I would go to get GOOD tutorial information about GIMP so that I can properly teach it?

Can you point me in the direction of a list of places that actually use GIMP for photo retouching and graphics creation. We are trying to give our kids real-world skills and we need to be able to point to real places that are using GIMP for photo retouching and graphics resolution. If I am going to teach using this software I need as much ammunition as possible to make this seem exciting and something that the kids will WANT to learn to use.

Thank you.

Debi Rapson Memorial High School
Art & Technology Dept
603-624-6378

_______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

El 07/03/11 21:34, Debi Rapson escribió:

Our school system appears to be headed for using GIMP as a way of teaching our students about graphics.

Can you point me in the direction of where I would go to get GOOD tutorial information about GIMP so that I can properly teach it?

Hello Debi,

I have made some tutorials. They are shorted by difficulty levels, then, you can start from low to advanced:

http://www.jesusda.com/docs/tutoriales-gimp/

You can find some e-books here too:

http://www.jesusda.com/docs/ebooks/

And some additional material here:

http://www.jesusda.com/docs/

I hope this helps you. Salu2 de jEsuSdA 8)

Can you point me in the direction of a list of places that actually use GIMP for photo retouching and graphics creation. We are trying to give our kids real-world skills and we need to be able to point to real places that are using GIMP for photo retouching and graphics resolution. If I am going to teach using this software I need as much ammunition as possible to make this seem exciting and something that the kids will WANT to learn to use.

Thank you.

Debi Rapson Memorial High School
Art& Technology Dept
603-624-6378

_______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Debi Rapson mansd.org> writes:

Can you point me in the direction of a list of places that actually use GIMP for photo retouching and graphics creation.

Hmm. GIMP is not well suited for professional photo retouching - it lack the necessary CMYK color model (among other things). I'm not sure what the focus of your program is but if you're looking for real-world use I would look more into video game art creation or online content.

2011/3/8 Michael Grosberg

Debi Rapson mansd.org> writes:

Can you point me in the direction of a list of places that actually use GIMP for photo retouching and graphics creation.

Hmm. GIMP is not well suited for professional photo retouching - it lack the
necessary CMYK color model (among other things). I'm not sure what the focus
of your program is but if you're looking for real-world use I would look more
into video game art creation or online content.

Could you explain why retouching photos should be made in CMYK rather than RGB?

On 03/08/2011 08:46 AM, Olivier wrote:

2011/3/8 Michael Grosberg >

Debi Rapson mansd.org > writes:

> Can you point me in the direction of a list of places that actually use
> GIMP for photo retouching and graphics creation.

Hmm. GIMP is not well suited for professional photo retouching - it lack the
necessary CMYK color model (among other things). I'm not sure what the focus
of your program is but if you're looking for real-world use I would look more
into video game art creation or online content.

Could you explain why retouching photos should be made in CMYK rather than RGB?

Could you explain why retouching photos should be made in RGB rather than HSV/HSL :)

or better yet: Lab? ;]

Anyway CMYK is neccessary too...

W dniu 2011-03-08 10:08 użytkownik "Ofnuts" napisał:

On 03/08/2011 08:46 AM, Olivier wrote:

2011/3/8 Michael Grosberg

...

Could you explain why retouching photos should be made in RGB rather than HSV/HSL :)

Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

We are not speaking about the same thing. The fact that you want to change some channels in some color model does not mean that the internal representation of images must be based on this color model. You need tools for generating a proper CMYK representation of you image, suited to your printing shop hardware, but that does not mean that the image you handle must use this representation from the beginning.

RGB is the internal representation of the images. It's also a color model, not especially suitable for manipulating colors. Thus you need tools that handle the image in more convenient color spaces. When you define a color using the color chooser, I suppose you work in HSV, not RGB?

2011/3/8 Bogdan Szczurek

or better yet: Lab? ;]

Anyway CMYK is neccessary too...

W dniu 2011-03-08 10:08 użytkownik "Ofnuts" napisał:

On 03/08/2011 08:46 AM, Olivier wrote:

2011/3/8 Michael Grosberg

>>...
Could you explain why retouching photos should be made in RGB rather than HSV/HSL :)

_______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

_______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Olivier Lecarme

Olivier gmail.com> writes:

2011/3/8 Michael Grosberg gmail.com>

Debi Rapson mansd.org> writes:

Can you point me in the direction of a list of places that actually use GIMP for photo retouching and graphics creation.

Hmm. GIMP is not well suited for professional photo retouching - it lack the necessary CMYK color model (among other things). I'm not sure what the focus of your program is but if you're looking for real-world use I would look more into video game art creation or online content.

Could you explain why retouching photos should be made in CMYK rather than RGB?

Photo retouching is usually done by print magazines. It stands to reason that they would use tools that are able to work with CMYK.

As for the other things... Modern Photographic work also relies on a higher bit depth. Photoshop is able to process raw camera input as opposed to GIMP which has to first convert it to 8-bit before being able to work on the image. There are also various selection tools, color adjustment tools and retouching tools (such as the healing brush) that work better in Photoshop.

We are not speaking about the same thing. The fact that you want to change some channels in some color model does not mean that the internal representation of images must be based on this color model.

True, it doesn't.

You need tools
for generating a proper CMYK representation of you image, suited to your printing shop hardware, but that does not mean that the image you handle must use this representation from the beginning.

I agree, it doesn't have to, yet it is convenient to use such representation when the image is to be send to print house.

RGB is the internal representation of the images.

That's untrue.

It's also a color model,

I'm not sure if it's right to try to set apart "internal representation" and "color model".

not especially suitable for manipulating colors.

I agree, but also it's easy to use in digital environment.

Thus you need tools that handle the image in more convenient color spaces.

Meaning: tools that convert image to different color space for the time of their application. Which, by the way, can be quite tricky step.

When you define a color
using the color chooser, I suppose you work in HSV, not RGB?

In fact, most of the time I use CMYK color chooser. Choice of color model often depends on your "notion" of that model. I prefer to use the same color model in my chooser that is the color model of my image. Using e.g. HSV chooser for RGB image can be deceitful since some color values can be silently changed by CMS. I prefer to use e.g. Lab for color adjustment and after I'm done with my modifications convert image to destination workspace. That way I've got full control over things that happen to my colors during conversion.

Anyway, I believe we should be able to use different color models used to represent color samples stored in images not because it's "just a nice thing" but because there's one silent assumption about every color model: every color model is bound with some workspace not necessarily bijective in regard to other workspaces.

Best regards! thebodzio

On 3/8/11, Bogdan Szczurek wrote:

When you define a color
using the color chooser, I suppose you work in HSV, not RGB?

In fact, most of the time I use CMYK color chooser.

Since we got carried away from the topic anyway, I keep hearing users complaining about various bits of GIMP still not color managed, most notoriously -- filter preview and sample points. The latter is sort of critical to those who uses separate+ and/or CMYKTool after editing things in GIMP. That makes one wonder if it will be addressed in 2.8 or later.

Alexandre Prokoudine http://libregraphicsworld.org

On Tue, Mar 8, 2011 at 12:28 PM, Michael Grosberg wrote:

Olivier gmail.com> writes:

2011/3/8 Michael Grosberg gmail.com>

Debi Rapson mansd.org> writes:

Can you point me in the direction of a list of places that actually use GIMP for photo retouching and graphics creation.

Hmm. GIMP is not well suited for professional photo retouching - it lack the necessary CMYK color model (among other things). I'm not sure what the focus of your program is but if you're looking for real-world use I would look more into video game art creation or online content.

Could you explain why retouching photos should be made in CMYK rather than RGB?

Photo retouching is usually done by print magazines. It stands to reason that they would use tools that are able to work with CMYK.

If I may interfere :). In my work I use CMYK on daily basis and I think the question "why photos should be retouched in CMYK" is not the right one to ask. One could do that but it's not the point. CMYK is not needed because it's nice to retouch images but because it provides fine control over cyan, magenta, yellow and black color components in four color professional print. One could only relay on color management in print workflow, but oftentimes it's insufficient. There are (not so rare) cases when CMS doesn't yield expected results—I mean: conversion can be done all right according to theory but in spite of that it's better to manually decide how some colors end up looking like. Sometimes one need to add or remove some "paint" from reproduction before it's going to be printed. Example: you need to have nice black background. Most of the times CMS will try to simulate that with all colors while it's better to use e.g. just full black and cyan. Another example: you need to do some trapping. Sometimes it can be done in RIP but you need to trust that to RIP itself and print house. These are only a couple of arguments, leaving aside quite similar cases of printing with paints different than C, M, Y and K.

Best regards! thebodzio

On Tue, Mar 8, 2011 at 2:30 PM, Alexandre Prokoudine wrote:

On 3/8/11, Bogdan Szczurek wrote:

When you define a color
using the color chooser, I suppose you work in HSV, not RGB?

In fact, most of the time I use CMYK color chooser.

Since we got carried away from the topic anyway, I keep hearing users complaining about various bits of GIMP still not color managed, most notoriously -- filter preview and sample points. The latter is sort of critical to those who uses separate+ and/or CMYKTool after editing things in GIMP. That makes one wonder if it will be addressed in 2.8 or later.

I think that we could touch here a broader problem of system wide color management. I think leaving color management to every single graphics editor separately is a no-no. It just makes keeping color managed workflow somewhat a nightmare.

On 3/8/11, Bogdan Szczurek wrote:

Since we got carried away from the topic anyway, I keep hearing users complaining about various bits of GIMP still not color managed, most notoriously -- filter preview and sample points. The latter is sort of critical to those who uses separate+ and/or CMYKTool after editing things in GIMP. That makes one wonder if it will be addressed in 2.8 or later.

I think that we could touch here a broader problem of system wide color management. I think leaving color management to every single graphics editor separately is a no-no.

Oh, but you don't have to do it :) GNOME Color Manager already provides D-Bus methods to request stuff like working color space profile. Any D-Bus enabled app (and GIMP is one) can do that. For 2.8, however, simply fixing what's already there would be enough.

(Albeit I heard from users who deal with DTP that they actually like advanced cms display filter: http://registry.gimp.org/node/24944)

Alexandre Prokoudine http://libregraphicsworld.org

On Tue, Mar 8, 2011 at 1:33 PM, Bogdan Szczurek wrote:

have nice black background. Most of the times CMS will try to simulate that with all colors while it's better to use e.g. just full black and cyan. Another example: you need to do some trapping. Sometimes it can be done in RIP but you need to trust that to RIP itself and print house. These are only a couple of arguments, leaving aside quite similar cases of printing with paints different than C, M, Y and K.

There are use cases where direct control over the separated result to CMYK is desired, this is however the corner cases and not the generic sense, it is my impression that a lot of people are editing in CMYK without understanding color management at all, effectively circumventing proper color management to happen. In the few cases where you need to include text or vector elements on top (or embedded within) an image and want to ensure a matching color with the (adjusted) photo,. or do other things to avoid problems with registration problems yes I see this as beneficial. To edit photos in a device specific (or even geography specified least common denominator CMYK profile) by default is however in my opinion not good advice.

Considering the use cases where fine grained control over the resulting offset plates/actual ink used for C,M,Y,K to be a subset of the more general cases where individual ink control is desired (spot-colors (including metallic, glossy and other overprints) as well as duo tone and more).

This the direction I have encouraged GIMP to move in on the UI level. This distances it from color managed, photo retouching etc. In the foreseeable future I see GEGL as primarily aiming to provide the core to do color manipulation, processing and image processing in colorimetrically managed (RGB) color spaces; with almost enforced strict working spaces for the algorithms to ensure predictability. The ability to do separation to CMYK, spot colors and more with associated processing on such will most easily be done as abstractions implemented using a planar approach where each ink is represented by a graylevel buffer.

/Øyvind Kolås

«The future is already here. It's just not very evenly distributed»
                                                 -- William Gibson
http://pippin.gimp.org/                            http://ffii.org/
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

On Tue, Mar 8, 2011 at 3:23 PM, Alexandre Prokoudine wrote:

On 3/8/11, Bogdan Szczurek wrote:

Since we got carried away from the topic anyway, I keep hearing users complaining about various bits of GIMP still not color managed, most notoriously -- filter preview and sample points. The latter is sort of critical to those who uses separate+ and/or CMYKTool after editing things in GIMP. That makes one wonder if it will be addressed in 2.8 or later.

I think that we could touch here a broader problem of system wide color management. I think leaving color management to every single graphics editor separately is a no-no.

Oh, but you don't have to do it :) GNOME Color Manager already provides D-Bus methods to request stuff like working color space profile. Any D-Bus enabled app (and GIMP is one) can do that. For 2.8, however, simply fixing what's already there would be enough.

I didn't know that (obviously ;)). It's nice, but I've got a hunch that such thing should be placed "lower" than DM. My ideal would be even something placed deeper than "display manager"/X.org.

I'd love to e.g. make my X theme using HSV or Lab color tuples. Also, such thing could take color management and color model support entirely of off applications shoulders.

(Albeit I heard from users who deal with DTP that they actually like advanced cms display filter: http://registry.gimp.org/node/24944)

Hmmm… I'm not sure of the reason of having that.

Best regards! thebodzio

On Tue, Mar 8, 2011 at 3:34 PM, Øyvind Kolås wrote:

On Tue, Mar 8, 2011 at 1:33 PM, Bogdan Szczurek wrote:

have nice black background. Most of the times CMS will try to simulate that with all colors while it's better to use e.g. just full black and cyan. Another example: you need to do some trapping. Sometimes it can be done in RIP but you need to trust that to RIP itself and print house. These are only a couple of arguments, leaving aside quite similar cases of printing with paints different than C, M, Y and K.

There are use cases where direct control over the separated result to CMYK is desired, this is however the corner cases and not the generic sense,

True enough, but I'm living on "that edge" ;).

it is my impression that a lot of people are editing in CMYK without understanding color management at all, effectively circumventing proper color management to happen.

I believe, color management is one of the most misunderstood and non-understood subjects out there generally :).

In the few cases
where you need to include text or vector elements on top (or embedded within) an image and want to ensure a matching color with the (adjusted) photo,. or do other things to avoid problems with registration problems yes I see this as beneficial. To edit photos in a device specific (or even geography specified least common denominator CMYK profile) by default is however in my opinion not good advice.

I don't see it different.

Considering the use cases where fine grained control over the resulting offset plates/actual ink used for C,M,Y,K to be a subset of the more general cases where individual ink control is desired (spot-colors (including metallic, glossy and other overprints) as well as duo tone and more).

I love that notion! I think of it similarly. Yet there's one thing in print specific color models that's notoriously neglected in color managed systems: image isn't magically put on some white (what is white exactly? ;)) universal material. Image goes through CtP (most of the time nowadays), machine and is placed on material of different characteristics. So, what is really needed for good color management is the profile of each of these stages, or at least whole process. Of course there are some "standard" profiles (e.g. FOGRA) but they all fall short when one is to use for example uncoated, dark red paper. I know, I know… egde case, yet as I said before I'm quite often on such edge :).

This the direction I have encouraged GIMP to move in on the UI level. This distances it from color managed, photo retouching etc. In the foreseeable future I see GEGL as primarily aiming to provide the core to do color manipulation, processing and image processing in colorimetrically managed (RGB) color spaces;

I also have high hopes for GEGL, but I'd rather have it use some more abstract color model for that. I know it's not so simple—maybe even undoable–that way, but I do like the idea of color model that has complete coverage of visible spectrum.

with almost enforced
strict working spaces for the algorithms to ensure predictability. The ability to do separation to CMYK, spot colors and more with associated processing on such will most easily be done as abstractions implemented using a planar approach where each ink is represented by a graylevel buffer.

True enough, but we mustn't forget about target material characteristics when considering print (and soft proofing), paint printing order and their attributes (opacity among them too).

Best regards! thebodzio

On Tue, Mar 8, 2011 at 3:12 PM, Bogdan Szczurek wrote:

Considering the use cases where fine grained control over the resulting offset plates/actual ink used for C,M,Y,K to be a subset of the more general cases where individual ink control is desired (spot-colors (including metallic, glossy and other overprints) as well as duo tone and more).

I also have high hopes for GEGL, but I'd rather have it use some more abstract color model for that. I know it's not so simple—maybe even undoable–that way, but I do like the idea of color model that has complete coverage of visible spectrum.

Using a color model with full coverage of the visual spectrum would be an extension along the lines of RGB and the responses of the human visual system/physics, entirely additive. Spectral processing is not similar to subtractive models like CMYK models needed for simulating print, mixing aspects, subsurface scattering, ink interactions and more (some of which are better indirectly modeled by ICC transforms backed by actual test-runs).

with almost enforced
strict working spaces for the algorithms to ensure predictability. The ability to do separation to CMYK, spot colors and more with associated processing on such will most easily be done as abstractions implemented using a planar approach where each ink is represented by a graylevel buffer.

True enough, but we mustn't forget about target material characteristics when considering print (and soft proofing), paint printing order and their attributes (opacity among them too).

All of these, like the simulation of glossiness or reflectiveness of metallic inks are things for the final separation/composite/simulation though - which very well can take into account both substrate and perhaps even an animated illuminant ;) Such soft-proofing would not be a space that GEGL itself would be doing processing in however, even though it might have op(s) to take the individual grey level buffers to create an RGB simulation to be shown on a display,. taking into account the RGB profile.

Allowing the user to configure a largeish set of predefinable inks for separation and simulation/softproofing would possibly allow some very nice workflows in GIMP and other softwares using GEGL.

Implementing the capabilities of doing such workflows is something that only can happen after GIMP itself has more naive initial support for storing its image data in GeglBuffers of higher bit depths. So if someone wants to play with, research and make prototypes for such a thing it would be a nice and welcome addition.

/Øyvind K.

«The future is already here. It's just not very evenly distributed»
                                                 -- William Gibson
http://pippin.gimp.org/                            http://ffii.org/
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

On Tue, Mar 8, 2011 at 11:28 AM, Michael Grosberg wrote:

Olivier gmail.com> writes:

2011/3/8 Michael Grosberg gmail.com> Could you explain why retouching photos should be made in CMYK rather than RGB?

Photo retouching is usually done by print magazines. It stands to reason that they would use tools that are able to work with CMYK.

Please see my longer response about why doing this _in_ CMYK is usually wrong, premature optimization by using device dependendt color spaces if the result might go to many different printers, profiles etc.

As for the other things...
Modern Photographic work also relies on a higher bit depth. Photoshop is able to process raw camera input as opposed to GIMP which has to first convert it to 8-bit before being able to work on the image.

Some of these are true, and GIMP is working towards lifting some of these limitations by migrating to GEGL.

There are also various selection tools, color adjustment tools and retouching tools (such as the healing brush) that work better in Photoshop.

These concepts do transfer to GIMP, and if one is generally empowering students with the ability to do manipulation on images.. teaching them how to do it with GIMP gives them both a skill and an option of a tool they can use without a fee; as well as have the freedom to improve in the other ways free software does. Pointing out that some things work better in Photoshop doesn't seem constructive in this discussion.

/Øyvind Kolås

«The future is already here. It's just not very evenly distributed»
                                                 -- William Gibson
http://pippin.gimp.org/                            http://ffii.org/
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

On Tue, Mar 8, 2011 at 3:12 PM, Bogdan Szczurek wrote:

Considering the use cases where fine grained control over the resulting offset plates/actual ink used for C,M,Y,K to be a subset of the more general cases where individual ink control is desired (spot-colors (including metallic, glossy and other overprints) as well as duo tone and more).

I also have high hopes for GEGL, but I'd rather have it use some more abstract color model for that. I know it's not so simple—maybe even undoable–that way, but I do like the idea of color model that has complete coverage of visible spectrum.

Using a color model with full coverage of the visual spectrum would be an extension along the lines of RGB and the responses of the human visual system/physics, entirely additive.

Not entirely along the lines I'm afraid. First of all it strongly depends which RGB we're talking about. Even if we take scRGB into account there's still some considerable parts of visible spectrum that can not be described by scRGB's triad. I know scRGB is tempting for it's quite broad and seems easy to implement in RGB dominated world, but I've got a premonition that using device agnostic color space would pay off more. But again–I don't know that :).

Spectral processing is not
similar to subtractive models like CMYK

I can't agree more.

models needed for simulating
print, mixing aspects, subsurface scattering, ink interactions and more (some of which are better indirectly modeled by ICC transforms backed by actual test-runs).

Some effects can be modelled that way (maybe even all). Other thing is if they actually are. Getting specific paper profile is most of the time undoable. Maybe something could be done in that matter? For example instead of painfully standard “color settings” dialog in preferences and “assign profile”, “convert to profile” options some new layout would work better? Maybe instead of going to a kind of “image mode” menu, we should go to “color workspace” menu with all available profiles listed there? The truth is that whenever we use color model that is unable to describe whole visible spectrum we are using some cutout of this spectrum, a working space. Giving an option to just convert image to “grayscale” or “CMYK” seems to blur that truth and IMHO tries to bury color management concept.

with almost enforced
strict working spaces for the algorithms to ensure predictability. The ability to do separation to CMYK, spot colors and more with associated processing on such will most easily be done as abstractions implemented using a planar approach where each ink is represented by a graylevel buffer.

True enough, but we mustn't forget about target material characteristics when considering print (and soft proofing), paint printing order and their attributes (opacity among them too).

All of these, like the simulation of glossiness or reflectiveness of metallic inks are things for the final separation/composite/simulation though - which very well can take into account both substrate and perhaps even an animated illuminant ;)

Tempting… tempting… :)

Such soft-proofing would not
be a space that GEGL itself would be doing processing in however, even though it might have op(s) to take the individual grey level buffers to create an RGB simulation to be shown on a display,. taking into account the RGB profile.

Allowing the user to configure a largeish set of predefinable inks for separation and simulation/softproofing would possibly allow some very nice workflows in GIMP and other softwares using GEGL.

Yup! That's what I hope for too.

Implementing the capabilities of doing such workflows is something that only can happen after GIMP itself has more naive initial support for storing its image data in GeglBuffers of higher bit depths. So if someone wants to play with, research and make prototypes for such a thing it would be a nice and welcome addition.

I don't think that higher bit depths are more important for transformations than for storing color samples. If image is to be displayed, most of the time it'll end up being crammed into 3 8-bit values :). If it's about to be printed most often it'll be pushed into finite (and not so big) number of possible raster point sizes. I think transformations are really the things that are to benefit most from bigger number of possible sample values. Images of course too, but not everytime.

Best regards!
thebodzio

On 03/08/2011 07:50 PM, Bogdan Szczurek wrote:

On Tue, Mar 8, 2011 at 3:12 PM, Bogdan Szczurek wrote:

I also have high hopes for GEGL, but I'd rather have it use some more abstract color model for that. I know it's not so simple—maybe even undoable–that way, but I do like the idea of color model that has complete coverage of visible spectrum.

Using a color model with full coverage of the visual spectrum would be an extension along the lines of RGB and the responses of the human visual system/physics, entirely additive.

Not entirely along the lines I'm afraid. First of all it strongly depends which RGB we're talking about. Even if we take scRGB into account there's still some considerable parts of visible spectrum that can not be described by scRGB's triad. I know scRGB is tempting for it's quite broad and seems easy to implement in RGB dominated world, but I've got a premonition that using device agnostic color space would pay off more. But again–I don't know that :).

If all you want is a color space that can encode all visible colors, i.e. the entire CIEXYZ color space, RGB is fine. Transforming from CIEXYZ to RGB (and vice versa) is a simple matrix multiplication, where the matrix depends on the primaries and white point chosen. It's just that sometimes the RGB components will be negative and sometimes greater than 1.0, but each color that can be perceived by a human can be encoded in such a boundless RGB color space.

If you want a color model that doesn't lose the information about the spectral power distribution of the stimulus, then RGB won't do, but from your reply above it doesn't sound like that is what you meant.

/ Martin

Øyvind Kolås gimp.org> writes:

On Tue, Mar 8, 2011 at 11:28 AM, Michael Grosberg gmail.com> wrote:

Olivier gmail.com> writes:

2011/3/8 Michael Grosberg gmail.com>

These concepts do transfer to GIMP, and if one is generally empowering students with the ability to do manipulation on images.. teaching them how to do it with GIMP gives them both a skill and an option of a tool they can use without a fee; as well as have the freedom to improve in the other ways free software does. Pointing out that some things work better in Photoshop doesn't seem constructive in this discussion.

You are forgetting what the discussion is about, I think :-) The original poster asked, among other things, for examples of GIMP being used for photo-retouching in the real world. I replied that perhaps it was better to look for places that use GIMP for video game art creation, and mentioned some reasons why GIMP isn't, to the best of my knowledge, used by photo retouching professionals. I did not intend to discourage the teaching of GIMP, only to point the OP in a direction where they are more likely to find a real professional who uses GIMP. It is, as you said, completely possible to teach the basic skills using GIMP. But "photo retouching" isn't the only thing GIMP can do, and I don't see why the need to focus on it. What about web graphics? digital painting? Texture art? I'm sure the artists who worked on Sintel would amaze the students with their Gimping skills.

On 3/8/11, Michael Grosberg wrote:

But "photo retouching" isn't the only thing GIMP can do, and I don't see why the need to focus on it. What about web graphics? digital painting? Texture art? I'm sure the artists who worked on Sintel would amaze the students with their Gimping skills.

There is, in fact, a whole DVD on digital painting by Sintel art director based around tweaked version of GIMP:

http://www.blender3d.org/e-shop/product_info_n.php?products_id=122

Alexandre Prokoudine http://libregraphicsworld.org

Who said this could not be done in Gimp? Some examples of Works i created with Gimp that are under CC:

Retouching: * http://commons.wikimedia.org/wiki/File:Snow_leopard_portrait.jpg (Original)
*
http://commons.wikimedia.org/wiki/File:Snow_leopard_portrait-2010-07-09.jpg (Retouched)
*
http://commons.wikimedia.org/wiki/File:MarineCorpsCompany_F-2-24_KhalidiyahSandstorm_2008.jpg (Original with wrong colors)
*
http://commons.wikimedia.org/w/index.php?title=File:MarineCorpsCompany_F-2-24_KhalidiyahSandstorm_2008_edit.jpg (Color Corrected version)
*
http://commons.wikimedia.org/w/index.php?title=File:Rana_esculenta_on_Nymphaea_edit.JPG (Original is linked on page)

Drawings (may contain nudity): *
http://commons.wikimedia.org/wiki/File:On_the_edge_-_free_world_version.jpg * http://commons.wikimedia.org/w/index.php?title=File:Dojikko.png

Am 08.03.2011 20:29, schrieb Michael Grosberg:

Øyvind Kolås gimp.org> writes:

On Tue, Mar 8, 2011 at 11:28 AM, Michael Grosberg gmail.com> wrote:

Olivier gmail.com> writes:

2011/3/8 Michael Grosberg gmail.com>

These concepts do transfer to GIMP, and if one is generally empowering students with the ability to do manipulation on images.. teaching them how to do it with GIMP gives them both a skill and an option of a tool they can use without a fee; as well as have the freedom to improve in the other ways free software does. Pointing out that some things work better in Photoshop doesn't seem constructive in this discussion.

You are forgetting what the discussion is about, I think :-) The original poster asked, among other things, for examples of GIMP being used for photo-retouching in the real world. I replied that perhaps it was better to look for places that use GIMP for video game art creation, and mentioned some reasons why GIMP isn't, to the best of my knowledge, used by photo retouching professionals. I did not intend to discourage the teaching of GIMP, only to point the OP in a direction where they are more likely to find a real professional who uses GIMP. It is, as you said, completely possible to teach the basic skills using GIMP. But "photo retouching" isn't the only thing GIMP can do, and I don't see why the need to focus on it. What about web graphics? digital painting? Texture art? I'm sure the artists who worked on Sintel would amaze the students with their Gimping skills.

_______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

On 03/08/2011 07:50 PM, Bogdan Szczurek wrote:

On Tue, Mar 8, 2011 at 3:12 PM, Bogdan Szczurek wrote:

I also have high hopes for GEGL, but I'd rather have it use some more abstract color model for that. I know it's not so simple—maybe even undoable–that way, but I do like the idea of color model that has complete coverage of visible spectrum.

Using a color model with full coverage of the visual spectrum would be an extension along the lines of RGB and the responses of the human visual system/physics, entirely additive.

Not entirely along the lines I'm afraid. First of all it strongly depends which RGB we're talking about. Even if we take scRGB into account there's still some considerable parts of visible spectrum that can not be described by scRGB's triad. I know scRGB is tempting for it's quite broad and seems easy to implement in RGB dominated world, but I've got a premonition that using device agnostic color space would pay off more. But again–I don't know that :).

If all you want is a color space that can encode all visible colors, i.e. the entire CIEXYZ color space, RGB is fine. Transforming from CIEXYZ to RGB (and vice versa) is a simple matrix multiplication, where the matrix depends on the primaries and white point chosen. It's just that sometimes the RGB components will be negative and sometimes greater than 1.0, but each color that can be perceived by a human can be encoded in such a boundless RGB color space.

Yes, but why use RGB at all if one can use e.g. XYZ from the start? So "wide" RGB would also require greater than 8 bit depths to work satisfactorily (HSV, HSL or Lab do quite nicely even with 8 bits per component). I think one consolation is possible backward compatibility with some other RGB spaces, but isn't BC a b**ch? ;) Besides there's a trouble of defining such “new” RGB workspace: what white point should be choosen and what primaries (all have to be defined in some absolute color coordinates BTW)? Whatever space would be choosen we wouldn't escape color conversions in color managed workflow, so while I'm not RGB enemy I fail to see the reason to stick to it especially since there are “wider” color spaces that are more intuitive to work with.

If you want a color model that doesn't lose the information about the spectral power distribution of the stimulus, then RGB won't do, but from your reply above it doesn't sound like that is what you meant.

No, I didn't, but still I think RGB “could do” since it's able to describe absolute color.

Well… I don't know if my longing is good or not, or if that way is better—I'm just thinking aloud :).

My best! thebodzio

On Tue, Mar 8, 2011 at 7:47 PM, Bogdan Szczurek wrote:

Yes, but why use RGB at all if one can use e.g. XYZ from the start? So "wide" RGB would also require greater than 8 bit depths to work satisfactorily (HSV, HSL or Lab do quite nicely even with 8 bits per component). I think one consolation is possible backward compatibility with some other RGB spaces, but isn't BC a b**ch? ;) Besides there's a trouble of defining such “new” RGB workspace: what white point should be choosen and what primaries (all have to be defined in some absolute color coordinates BTW)? Whatever space would be choosen we wouldn't escape color conversions in color managed workflow, so while I'm not RGB enemy I fail to see the reason to stick to it especially since there are “wider” color spaces that are more intuitive to work with.

It is a matter of which well defined color space the operations desired provide sensible outputs. For some types of operations doing them in premultiplied linear light RGB is superior to doing them in sRGB, CIE Lab or other more or less perceptual spaces, for other operations the opposite is true. My stance is that the sliders on an operations should be predictable and always do the same thing for the colorimetrically absolute same color - whis is why the operations of GEGL request temporary working buffers in their preferred working space (this is where babl does the; optimized; conversions you correctly state have to happen) rather than blindly handling incoming numbers. The RGB space defined by and used by babl uses the same primaries as sRGB, and has well defined conversions to CIE Lab, Xyz and others.

The preferred^Wenforced working space of some operations in GEGL might need some scrutinization and review, though for compositing; gaussian blurs; interpolation etc I think the current choice of linear light RGB.

GEGL also does not support working in an internal 8bit or 16bit mode, it is floating point with high precision and additional headroom/footroom (wide gamut/HDR) for all temporary buffers, if the desired output is 8bit it happens when displayed or exported. Operations like for instance unsharp-mask does not work correctly if termporary results are clipped.

/Ø

«The future is already here. It's just not very evenly distributed»
                                                 -- William Gibson
http://pippin.gimp.org/                            http://ffii.org/
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

On Tue, Mar 8, 2011 at 7:47 PM, Bogdan Szczurek wrote:

Yes, but why use RGB at all if one can use e.g. XYZ from the start? So "wide" RGB would also require greater than 8 bit depths to work satisfactorily (HSV, HSL or Lab do quite nicely even with 8 bits per component). I think one consolation is possible backward compatibility with some other RGB spaces, but isn't BC a b**ch? ;) Besides there's a trouble of defining such “new” RGB workspace: what white point should be choosen and what primaries (all have to be defined in some absolute color coordinates BTW)? Whatever space would be choosen we wouldn't escape color conversions in color managed workflow, so while I'm not RGB enemy I fail to see the reason to stick to it especially since there are “wider” color spaces that are more intuitive to work with.

It is a matter of which well defined color space the operations desired provide sensible outputs. For some types of operations doing them in premultiplied linear light RGB is superior to doing them in sRGB, CIE Lab or other more or less perceptual spaces, for other operations the opposite is true. My stance is that the sliders on an operations should be predictable and always do the same thing for the colorimetrically absolute same color - whis is why the operations of GEGL request temporary working buffers in their preferred working space (this is where babl does the; optimized; conversions you correctly state have to happen) rather than blindly handling incoming numbers. The RGB space defined by and used by babl uses the same primaries as sRGB, and has well defined conversions to CIE Lab, Xyz and others.

The preferred^Wenforced working space of some operations in GEGL might need some scrutinization and review, though for compositing; gaussian blurs; interpolation etc I think the current choice of linear light RGB.

GEGL also does not support working in an internal 8bit or 16bit mode, it is floating point with high precision and additional headroom/footroom (wide gamut/HDR) for all temporary buffers, if the desired output is 8bit it happens when displayed or exported. Operations like for instance unsharp-mask does not work correctly if termporary results are clipped.

/Ø

«The future is already here. It's just not very evenly distributed»
                                                 -- William Gibson
http://pippin.gimp.org/                            http://ffii.org/
_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

Yes, but why use RGB at all if one can use e.g. XYZ from the start? So "wide" RGB would also require greater than 8 bit depths to work satisfactorily (HSV, HSL or Lab do quite nicely even with 8 bits per component). I think one consolation is possible backward compatibility with some other RGB spaces, but isn't BC a b**ch? ;) Besides there's a trouble of defining such “new” RGB workspace: what white point should be choosen and what primaries (all have to be defined in some absolute color coordinates BTW)? Whatever space would be choosen we wouldn't escape color conversions in color managed workflow, so while I'm not RGB enemy I fail to see the reason to stick to it especially since there are “wider” color spaces that are more intuitive to work with.

It is a matter of which well defined color space the operations desired provide sensible outputs. For some types of operations doing them in premultiplied linear light RGB is superior to doing them in sRGB, CIE Lab or other more or less perceptual spaces, for other operations the opposite is true. My stance is that the sliders on an operations should be predictable and always do the same thing for the colorimetrically absolute same color - whis is why the operations of GEGL request temporary working buffers in their preferred working space (this is where babl does the; optimized; conversions you correctly state have to happen) rather than blindly handling incoming numbers.

All of it seems reasonable to me :).

The RGB space defined by and used by babl uses the same primaries as sRGB, and has well defined conversions to CIE Lab, Xyz and others.

Docs state it as “scRGB”. I don't argue about well defined conversion to absolute color coordinates (every color model have them, I should think). My only concern is about 20% of visible spectrum missing from scRGB. If operation yields a color from that absent 20% of spectrum, that color have to be “pushed” into available space. That's the obvious. What isn't is how often it happens (are some statistics available?) and how serious is that for color reproduction? If it's less than a couple of pixels then I'm calmed down :).

The preferred^Wenforced working space of some operations in GEGL might need some scrutinization and review, though for compositing; gaussian blurs; interpolation etc I think the current choice of linear light RGB.

GEGL also does not support working in an internal 8bit or 16bit mode, it is floating point with high precision and additional headroom/footroom (wide gamut/HDR) for all temporary buffers, if the desired output is 8bit it happens when displayed or exported. Operations like for instance unsharp-mask does not work correctly if termporary results are clipped.

I can only say that I back that up.

Best regards! thebodzio

These concepts do transfer to GIMP, and if one is generally empowering students with the ability to do manipulation on images.. teaching them how to do it with GIMP gives them both a skill and an option of a tool they can use without a fee; as well as have the freedom to improve in the other ways free software does. Pointing out that some things work better in Photoshop doesn't seem constructive in this discussion.

Indeed.
I was baffled to see how some GIMP people started to downplay GIMP as not suitable for this particular need. It's a school teacher trying to get kids into the basics of image manipulation, not a high grade training for the print industry!
GIMP is absolutely suitable for this task, and it can be used in real world environments too. I use it everyday for my professional design work. I have to work around some edge cases, of course, but for most of my work it is usable (and I send works to different print providers in a daily basis).
I don't care much about CMYK since I use intermediate/late binding, but the lack of higher bitdepth is indeed a hurdle when I work with narrow range monochrome gradients or alpha channels. Anyway, I don't see how some gradient banding or the loss of precision with some filters could be a real concern for kids learning the basics of image manipulation, at least to the point of considering to replace GIMP, which is free, with an expensive commercial application. And even in that case, GIMP uses the same principles than Photoshop, so you can use it to learn to work layers, blending modes, masks, filters, selections, levels, curves, color balance, cloning, healing, etc. It's all there.

Apart from that, I'm with pippin about the premature CMYK conversion. I came out of the University (where I studied graphic design) with a rather limited knowledge about color management, thinking that early binding was the only way to work for print and that with the right CMYK values I would get perfect Pantone colors :-p When I switched to free software and met GIMP I had to learn some basics again to work without CMYK and the quality of my prints improved a lot, because that time I knew what I was doing. Of course there are cases when the access to CMYK separations is useful, but I would have preferred that they teach me to work with color management properly and learn to tweak CYMK later.