thanks.

On Fri, Mar 27, 2009 at 1:36 AM, < gimp-developer-request@lists.xcf.berkeley.edu> wrote:

Send Gimp-developer mailing list submissions to gimp-developer@lists.XCF.Berkeley.EDU

To subscribe or unsubscribe via the World Wide Web, visit https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer or, via email, send a message with subject or body 'help' to gimp-developer-request@lists.XCF.Berkeley.EDU

You can reach the person managing the list at gimp-developer-owner@lists.XCF.Berkeley.EDU

When replying, please edit your Subject line so it is more specific than "Re: Contents of Gimp-developer digest..."

Today's Topics:

1. Re: GIMP PDF export plugin (Andrew A. Gill) 2. Re: GIMP PDF export plugin (Andrew A. Gill) 3. Re: a good student UI project... (Alexandre Prokoudine) 4. Re: a good student UI project... (David Gowers) 5. Re: a good student UI project... (Irena Damsky) 6. Re: a good student UI project... (yahvuu)

----------------------------------------------------------------------

Message: 1 Date: Thu, 26 Mar 2009 03:40:09 -0400 (EDT) From: "Andrew A. Gill"
Subject: Re: [Gimp-developer] GIMP PDF export plugin To: Martin Nordholts
Cc: gimp-developer
Message-ID:
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Thu, 26 Mar 2009, Martin Nordholts wrote:

I must say I find this a bit arrogant.

Maybe. Probably.

But I think it's time for me a a user to stop telling developers what I need and to start asking what you need to make that happen.

I think it's time to stop looking at this from the position of nebulous wants and desires and to start looking at the end product and asking what restrictions need to be placed on its development. Where does it connect to the rest of the program? How does it interact with the rest of the program? When we know that, we'll be able to start figuring out how best to implememt it.

Supporting someone that is inexperienced with hacking on the GIMP core

I'm not asking for support. I'm just asking you what the shape of the hole is that the CMYK peg must fit into.

I'm not really suggesting that I tackle the problem, but in my experience, the first response to ``You should have feature X'' is usually ``You forgot to attach the patch.'' Talk is cheap, and somebody needs to offer to help.

-- | Andrew A. Gill To ensure continued quality of service, | | this e-mail is being monitored by the NSA | | |
--

------------------------------

Message: 2 Date: Thu, 26 Mar 2009 05:16:20 -0400 (EDT) From: "Andrew A. Gill"
Subject: Re: [Gimp-developer] GIMP PDF export plugin To: Vincent Lordier
Cc: GIMP Developer
Message-ID:
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII

On Wed, 25 Mar 2009, Vincent Lordier wrote:

Hello happy CMYK warriors,

This is valuable input you're giving actually How about collecting these use cases for prepress in the wiki here http://wiki.gimp.org/gimp/ ?

Well, I'm a man of my word and so I just contributed my wiki attempt to do my part to change this from pie-in-the-sky dreaming.

There's an incomplete draft here:

I still need to come up with a good color correction example and a good rich black example, but I should sleep now.

-- | Andrew A. Gill To ensure continued quality of service, | | this e-mail is being monitored by the NSA | | |
--

------------------------------

Message: 3 Date: Thu, 26 Mar 2009 12:32:31 +0300 From: Alexandre Prokoudine
Subject: Re: [Gimp-developer] a good student UI project... To: GIMP Developer
Message-ID:

Content-Type: text/plain; charset=ISO-8859-1

On Thu, Mar 26, 2009 at 4:12 AM, yahvuu wrote:

levels, curves - could support the user's intention more directly: ? ? ? ? ? ? ? ? ? - mark places in the image, which should be

brighter/darker,

? ? ? ? ? ? ? ? ? ? or have more/less contrast or modified colors ? ? ? ? ? ? ? ? ? - the whitepoint, graypoint pickers could be adjustable

markers

? ? ? ? ? ? ? ? ? ? on the image. Or a completely different method for

whitebalance?

? ? ? ? ? ? ? ? ? - if tones are getting compressed, better control of

where the

? ? ? ? ? ? ? ? ? ? clipping happens (separately for each of R,G,B,

Value)

Yup, on-canvas level/curves. Excellent point.

Another idea: Gradient fill tool that has color stops editable on canvas (a-la Inkscape).

Alexandre

------------------------------

Message: 4 Date: Thu, 26 Mar 2009 20:29:48 +1030 From: David Gowers
Subject: Re: [Gimp-developer] a good student UI project... To: Alexandre Prokoudine
Cc: GIMP Developer
Message-ID:

Content-Type: text/plain; charset=ISO-8859-1

gradation map - nearly the same: map image points to positions in the

gradient
Yahvuu, you probably need to clarify: how is this different from Colors->Map->Gradient Map?

On Thu, Mar 26, 2009 at 8:02 PM, Alexandre Prokoudine wrote:

On Thu, Mar 26, 2009 at 4:12 AM, yahvuu wrote:

levels, curves - could support the user's intention more directly: ? ? ? ? ? ? ? ? ? - mark places in the image, which should be

brighter/darker,

? ? ? ? ? ? ? ? ? ? or have more/less contrast or modified colors ? ? ? ? ? ? ? ? ? - the whitepoint, graypoint pickers could be

adjustable markers

? ? ? ? ? ? ? ? ? ? on the image. Or a completely different method for

whitebalance?

? ? ? ? ? ? ? ? ? - if tones are getting compressed, better control of

where the

? ? ? ? ? ? ? ? ? ? clipping happens (separately for each of R,G,B,

Value)
Better? We already have exact control of clipping for each of R,G,B,Value , so do you mean a change in the quality of clipping control? I think this needs to be more specific

Yup, on-canvas level/curves. Excellent point.

Another idea: Gradient fill tool that has color stops editable on canvas (a-la Inkscape).

If I had this, I'd probably delete all my gradients :) IMO this is a much more usable way in general, and premade gradients cover only a small subset of use cases.

David

------------------------------

Message: 5 Date: Thu, 26 Mar 2009 18:51:30 +0200 From: Irena Damsky
Subject: Re: [Gimp-developer] a good student UI project... To: peter sikking
Cc: GIMP Developer
Message-ID:

Content-Type: text/plain; charset="iso-8859-1"

Peter Hi,

I think you should post this question to the GIMP-USERS list. I find it extremely useful to ask the users themselves what do they want to be a part of a package they are using...

Irena

On Wed, Mar 25, 2009 at 10:38 PM, peter sikking wrote:

hi all,

at the end of may I am again teaching an interaction design course at the FH Voralrberg (university of applied sciences).

here is the plan: the course is in the form of a design project, and the students work in small teams on a UI concept for GIMP. all (4) teams work on the same design problem. after the thing is over and they got their grades, I will take the overall concept further using their ideas and then spec a solution.

so now we need a design problem. the course is short but intense, 3 days with me full-time to work up a solutions model and then they take some days to finish their presentation.

so now huge redesign problems, more something like a compact tool. (like the free/poly select tool), or a tricky interactive dialog (like, combined brightness/contrast + levels + curves).

please post your suggestions what we could do.

--ps

founder + principal interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

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

--
Irena Damsky
irena.damsky@gmail.com
057-8165528
052-3294417
you can also find me on MSN: ira_damsky@hotmail.com

Smile! and the world will smile with you! Cry! and you'll cry alone...
-------------- next part -------------- An HTML attachment was scrubbed...
URL:
/lists/gimp-developer/attachments/20090326/58e3c3be/attachment-0001.html

------------------------------

Message: 6 Date: Thu, 26 Mar 2009 18:37:39 +0100 From: yahvuu
Subject: Re: [Gimp-developer] a good student UI project... To: GIMP Developer
Message-ID:
Content-Type: text/plain; charset=ISO-8859-1

hi,

David Gowers schrieb:

gradation map - nearly the same: map image points to positions in the

gradient

Yahvuu, you probably need to clarify: how is this different from Colors->Map->Gradient Map?

sorry for the misspelling. Exactly Colors->Map->Gradient Map is what i meant.
Here again, a balance between emphasizing certain photo areas and adjusting the global tone is desired.

On Thu, Mar 26, 2009 at 4:12 AM, yahvuu wrote:

- if tones are getting compressed, better control of

where the

clipping happens (separately for each of R,G,B,

Value)

Better? We already have exact control of clipping for each of R,G,B,Value , so do you mean a change in the quality of clipping control? I think this needs to be more specific

Indeed, clipping is under full control right now. Applying the on-canvas idea,
it's interface could be supplemented by marking the border between important
image regions and those regions which can be color-clipped without regret.

More useful would be augmented feedback: - how harsh does the clipping start? - which details get lost?
- is one of R,G,B clipping early?
Something more advanced than letting the clipped pixels blink could be interesting here.

greetings, peter

------------------------------

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

End of Gimp-developer Digest, Vol 78, Issue 51 **********************************************

On Thu, Mar 26, 2009 at 3:04 PM, < gimp-developer-request@lists.xcf.berkeley.edu> wrote:

Send Gimp-developer mailing list submissions to gimp-developer@lists.XCF.Berkeley.EDU

To subscribe or unsubscribe via the World Wide Web, visit https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer or, via email, send a message with subject or body 'help' to gimp-developer-request@lists.XCF.Berkeley.EDU

You can reach the person managing the list at gimp-developer-owner@lists.XCF.Berkeley.EDU

When replying, please edit your Subject line so it is more specific than "Re: Contents of Gimp-developer digest..."

Today's Topics:

1. Re: GIMP PDF export plugin (Andrew A. Gill) 2. Re: GIMP PDF export plugin (Louis Desjardins) 3. Re: GIMP PDF export plugin (Andrew A. Gill) 4. Re: GIMP PDF export plugin (Louis Desjardins) 5. Re: Dockable Dialogs Should be Dockable Everywhere (Martin Nordholts)
6. Re: Dockable Dialogs Should be Dockable Everywhere (Graeme Gill) 7. Re: GIMP PDF export plugin (Martin Nordholts)

----------------------------------------------------------------------

Message: 1 Date: Wed, 25 Mar 2009 23:45:41 -0400 (EDT) From: "Andrew A. Gill"
Subject: Re: [Gimp-developer] GIMP PDF export plugin To: Louis Desjardins
Cc: gimp-developer ,
gespertino@gmail.com
Message-ID:
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Wed, 25 Mar 2009, Louis Desjardins wrote:

To this point I don?t believe it?s that important to start figuring out whether the case is as good an example as it possibly can. I guess we are not at all trying to make the trial of the use of CMYK in the printing industry! (Now, that would be a total waste of time!) For those interested I bet a full glass of beer ? available at LGM! ? that they can find without too much efforts plenty of explanations about CMYK use in the printing industry on the web. Even non-offset printing go by CMYK and inkjet printing involves CMYK plus Light Cyan, Light Mangenta and/or Vivid Magenta and some Black variations. Somehow, somewhere in the process these printers need to convert the data so the printer can use one of the CMYK inks that?s in the machine, be it toner or printing ink. There is no way to ignore this reality.

I am informed that some CcMmYK printers accept only RGB data. In such cases, it would be better not to convert to CMYK, since it will only have to be converted back to RGB before it goes to the device.

--
| Andrew A. Gill To ensure continued quality of service, | | this e-mail is being monitored by the NSA | | |
--

------------------------------

Message: 2 Date: Wed, 25 Mar 2009 23:59:02 -0400 From: Louis Desjardins
Subject: Re: [Gimp-developer] GIMP PDF export plugin To: "Andrew A. Gill"
Cc: gimp-developer ,
gespertino@gmail.com
Message-ID:
Content-Type: text/plain; charset=windows-1252; format=flowed

Andrew A. Gill a ?crit :

On Wed, 25 Mar 2009, Louis Desjardins wrote:

To this point I don?t believe it?s that important to start figuring out whether the case is as good an example as it possibly can. I guess we are not at all trying to make the trial of the use of CMYK in the printing industry! (Now, that would be a total waste of time!) For those interested I bet a full glass of beer ? available at LGM! ? that they can find without too much efforts plenty of explanations about CMYK use in the printing industry on the web. Even non-offset printing go by CMYK and inkjet printing involves CMYK plus Light Cyan, Light Mangenta and/or Vivid Magenta and some Black variations. Somehow, somewhere in the process these printers need to convert the data so the printer can use one of the CMYK inks that?s in the machine, be it toner or printing ink. There is no way to ignore this reality.

I am informed that some CcMmYK printers accept only RGB data. In such cases, it would be better not to convert to CMYK, since it will only have to be converted back to RGB before it goes to the device.

This mostly depends on the RIP that is attached to the printer but really, this doesn?t prove the point of the need of CMYK editing ability to be wrong, does it?

Louis

------------------------------

Message: 3 Date: Thu, 26 Mar 2009 00:10:01 -0400 (EDT) From: "Andrew A. Gill"
Subject: Re: [Gimp-developer] GIMP PDF export plugin To: Louis Desjardins
Cc: gimp-developer
Message-ID:
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Wed, 25 Mar 2009, Louis Desjardins wrote:

This mostly depends on the RIP that is attached to the printer but

really,

this doesn?t prove the point of the need of CMYK editing ability to be

wrong,

does it?

On the contrary.

Just trying to give people all the facts. I find it helps to avoid being accused of partisanship.

-- | Andrew A. Gill To ensure continued quality of service, | | this e-mail is being monitored by the NSA | | |
--

------------------------------

Message: 4 Date: Thu, 26 Mar 2009 00:16:06 -0400 From: Louis Desjardins
Subject: Re: [Gimp-developer] GIMP PDF export plugin To: "Andrew A. Gill"
Cc: gimp-developer
Message-ID:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Andrew A. Gill a ?crit :

On Wed, 25 Mar 2009, Louis Desjardins wrote:

This mostly depends on the RIP that is attached to the printer but really, this doesn?t prove the point of the need of CMYK editing ability to be wrong, does it?

On the contrary.

Just trying to give people all the facts. I find it helps to avoid being accused of partisanship.

:-)

Ok!

------------------------------

Message: 5 Date: Thu, 26 Mar 2009 07:15:45 +0100 From: Martin Nordholts
Subject: Re: [Gimp-developer] Dockable Dialogs Should be Dockable Everywhere
To: drizzt
Cc: gimp-developer@lists.xcf.berkeley.edu Message-ID:
Content-Type: text/plain; charset=ISO-8859-1

drizzt wrote:

Hi all !

This is a long post, replying to many previous posts, and adding some

parts

from IRC chats, and some even from discussions with Gimp developers.

Hi,

Long it was, for sure. Sorry but if you don't want the GIMP UI to evolve and change, don't upgrade to new versions.

Basic rules of interaction design applies to both open source and commercial projects. Now, open source and commercial projects can have completely different goals, and often have, but basic rules of interaction design still applies. With all due respect it to me sounds like you have not looked into interaction design at all and is just ranting based on your highly personal preferences. Looking into the world of interaction design will give you valuable insights. I recommend you to read the book "The Inmates Are Running the Asylum" by Alan Cooper. It is not a handbook on how to design interactive systems, but more of an eye-opener of what's wrong with todays products and processes as far as interaction design goes. In that book he addresses a lot of the points you are making.

BR, Martin

------------------------------

Message: 6 Date: Thu, 26 Mar 2009 17:49:45 +1100 From: Graeme Gill
Subject: Re: [Gimp-developer] Dockable Dialogs Should be Dockable Everywhere
To: gimp-developer@lists.xcf.berkeley.edu Message-ID:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Martin Nordholts wrote:

world of interaction design will give you valuable insights. I recommend you to read the book "The Inmates Are Running the Asylum" by Alan Cooper. It is not a handbook on how to design interactive systems, but

I wouldn't bother. Whatever insights are contained in this book are completely clouded by the outright mistakes and predudice it containts. It is little more than a rant in itself.

Graeme Gill.

------------------------------

Message: 7 Date: Thu, 26 Mar 2009 08:05:03 +0100 From: Martin Nordholts
Subject: Re: [Gimp-developer] GIMP PDF export plugin To: "Andrew A. Gill"
Cc: gimp-developer ,
graeme@argyllcms.com
Message-ID:
Content-Type: text/plain; charset=ISO-8859-1

Andrew A. Gill wrote:

[from here out, `you' refers to core GIMP developers]

We want you to succeed, and all you need to do to succeed is to address some of the issues that users need. If you're telling us that GIMP has no intention of ever providing those things, we'll find another product. Maybe Krita when it becomes vaguely stable, or maybe a fork.

With all the excellent input from people in the printing industry, including you, I think it is as clear as it can be. GIMP needs to support editing in the CMYK color space. Support for editing only in the RGB color space will simply not be enough. The details on _how_ to support this is still an open question, but that we _need_ to is to me just unquestionable.

Here's a thought: I can code. I'm sure others on this list can, too. Why don't you tell us what you would require for a CMYK mode to be incorporated into the trunk of GIMP. We can all read the API, but you can tell us what coding standards we need, what toes we can't step on and why other attempts to add similar functionality (like Cinepaint nee FilmGimp) foundered, and what we can do to avoid making those same mistakes.

If you tell us what we need to do, we can do it. That's the point of Open Source!

If you don't, people are going to get sick of the excuses and simply move on to develop this functionality somewhere else.

From the outside, GIMP is seen as a shining example of what open

source is capable of. Inside the OSS movement, it's seen much like the XFree86 guys--constantly bickering about the same issues. I'm sure that you'd have no trouble getting developers to work on a flagship product if they were convinced that it would end some of the internal conflicts in OSS.

I must say I find this a bit arrogant. Supporting someone that is inexperienced with hacking on the GIMP core to implement CMYK, which arguably is the toughest task one can currently take on as far as GIMP hacking goes, would be both very boring and very time consuming. That is not something I want to spend my spare time on. If you want to help implement better support for CMYK you should start working on and looking into the GIMP code. After working on the code for a while you will get your own ideas on how to implement CMYK in the best way.

I've been contributing code to GIMP for quite a while now, and I don't know yet know exactly how to implement support for CMYK editing in the best way. All I know is that GEGL will be a much better base for this than the legacy code. So if you want to help getting CMYK into GIMP, helping with the integration of GEGL will be a good start.

Best regards, Martin

------------------------------

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

End of Gimp-developer Digest, Vol 78, Issue 50 **********************************************

On Thu, Mar 26, 2009 at 11:21 AM, < gimp-developer-request@lists.xcf.berkeley.edu> wrote:

Send Gimp-developer mailing list submissions to gimp-developer@lists.XCF.Berkeley.EDU

To subscribe or unsubscribe via the World Wide Web, visit https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer or, via email, send a message with subject or body 'help' to gimp-developer-request@lists.XCF.Berkeley.EDU

You can reach the person managing the list at gimp-developer-owner@lists.XCF.Berkeley.EDU

When replying, please edit your Subject line so it is more specific than "Re: Contents of Gimp-developer digest..."

Today's Topics:

1. Re: GIMP PDF export plugin (Andrew A. Gill) 2. Re: a good student UI project... (yahvuu) 3. Re: GIMP PDF export plugin (Guillermo Espertino) 4. Re: GIMP PDF export plugin (Andrew A. Gill) 5. Re: GIMP PDF export plugin (Graeme Gill) 6. Re: GIMP PDF export plugin (Louis Desjardins)

----------------------------------------------------------------------

Message: 1 Date: Wed, 25 Mar 2009 20:40:25 -0400 (EDT) From: "Andrew A. Gill"
Subject: Re: [Gimp-developer] GIMP PDF export plugin To: graeme@argyllcms.com
Cc: gimp-developer
Message-ID:
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII

On Thu, 26 Mar 2009, Graeme Gill wrote:

As I understand it, Scribus is not a pixel editor, it is a page layout package, rather a different thing altogether.

For the record, Scribus does allow pixel editing.

When you right click on an image and select Edit Image, it opens the image in GIMP.

I think that's pretty strong evidence that there's no intent to do raster editing in Scribus itself.

I really don't think people working in the graphic arts are going to want to master two different pixel editing packages, simply because one of them doesn't support anything other than RGB. If they're in the Linux sphere, then I guess they need to go and look at using Krita instead.

FYI, Krita is extremely buggy. It has an SDI, which some people (e.g. me) don't like, but the code will improve and there may be improvements in the interface. Krita may indeed surpass GIMP. Sad, really, since I think GIMP can be the better product.

[from here out, `you' refers to core GIMP developers]

We want you to succeed, and all you need to do to succeed is to address some of the issues that users need. If you're telling us that GIMP has no intention of ever providing those things, we'll find another product. Maybe Krita when it becomes vaguely stable, or maybe a fork.

But you've got the time to do it before the others catch up, and you've got GEGL, the toolset to do it right.

Here's a thought: I can code. I'm sure others on this list can, too. Why don't you tell us what you would require for a CMYK mode to be incorporated into the trunk of GIMP. We can all read the API, but you can tell us what coding standards we need, what toes we can't step on and why other attempts to add similar functionality (like Cinepaint nee FilmGimp) foundered, and what we can do to avoid making those same mistakes.

If you tell us what we need to do, we can do it. That's the point of Open Source!

If you don't, people are going to get sick of the excuses and simply move on to develop this functionality somewhere else.

From the outside, GIMP is seen as a shining example of what open

source is capable of. Inside the OSS movement, it's seen much like the XFree86 guys--constantly bickering about the same issues. I'm sure that you'd have no trouble getting developers to work on a flagship product if they were convinced that it would end some of the internal conflicts in OSS.

-- | Andrew A. Gill To ensure continued quality of service, | | this e-mail is being monitored by the NSA | | |
--

------------------------------

Message: 2 Date: Thu, 26 Mar 2009 02:12:03 +0100 From: yahvuu
Subject: Re: [Gimp-developer] a good student UI project... To: peter sikking
Cc: GIMP Developer
Message-ID:
Content-Type: text/plain; charset=ISO-8859-1

Hi Peter,

some ideas from a typical photo workflow:

perspective correction - select some prominent lines from the image and "get them straight"

alignment of horizon line - in cooperation with an automated guess?

crop & rotate, set - virtual photography ala google earth? aspect ratio perhaps even with composition aids (rule of thirds, Westhoff's Diagonal Method, etc)

levels, curves - could support the user's intention more directly: - mark places in the image, which should be brighter/darker,
or have more/less contrast or modified colors - the whitepoint, graypoint pickers could be adjustable markers
on the image. Or a completely different method for whitebalance?
- if tones are getting compressed, better control of where the
clipping happens (separately for each of R,G,B, Value)

gradation map - nearly the same: map image points to positions in the gradient

greetings,
peter

------------------------------

Message: 3 Date: Wed, 25 Mar 2009 22:13:39 -0300 From: Guillermo Espertino
Subject: Re: [Gimp-developer] GIMP PDF export plugin To: gimp-developer@lists.XCF.Berkeley.EDU Message-ID:
Content-Type: text/plain

Even though I agree that most of the CMYK cases mentioned use CMYK almost as spot colors, I can think of a very common usage scenario in Graphic Design where you need to be able to edit CMYK directly:

Corporate colors. Most frequently Pantones. Brands have their corporate colors and ask designers to use them, but they can not always afford extra spot passes in offset press, so the colors have to be converted to the most aproximate CMYK combination (the Pantone Bridge catalog is for that).

So you have to adjust the color of a photograph of a sign, a truck and a producto of your client to their corporate CMYK color.

It's a photograph, you need CMYK, you can't use spot.

This is a very common scenario, and it's a task for a image manipulation program.

Gez.

------------------------------

Message: 4 Date: Wed, 25 Mar 2009 21:45:17 -0400 (EDT) From: "Andrew A. Gill"
Subject: Re: [Gimp-developer] GIMP PDF export plugin To: Guillermo Espertino
Cc: gimp-developer@lists.XCF.Berkeley.EDU Message-ID:
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Wed, 25 Mar 2009, Guillermo Espertino wrote:

Even though I agree that most of the CMYK cases mentioned use CMYK almost as spot colors, I can think of a very common usage scenario in Graphic Design where you need to be able to edit CMYK directly:

Corporate colors. Most frequently Pantones. Brands have their corporate colors and ask designers to use them, but they can not always afford extra spot passes in offset press, so the colors have to be converted to the most aproximate CMYK combination (the Pantone Bridge catalog is for that).

So you have to adjust the color of a photograph of a sign, a truck and a producto of your client to their corporate CMYK color.

It's a photograph, you need CMYK, you can't use spot.

This is a very common scenario, and it's a task for a image manipulation program.

Sadly for the cause of CMYK, that's not really a good example. That's a better example for the need for Pantone and other color matching system support.

Which GIMP will eventually need, but I'm thinking that day will come a decade or two from now, hopefully when there's an open source rival for Pantone.

(I actually plan to take that task on, myself in a few years, as part of some research)

--
| Andrew A. Gill To ensure continued quality of service, | | this e-mail is being monitored by the NSA | | |
--

------------------------------

Message: 5 Date: Thu, 26 Mar 2009 12:51:15 +1100 From: Graeme Gill
Subject: Re: [Gimp-developer] GIMP PDF export plugin To: gimp-developer@lists.XCF.Berkeley.EDU Message-ID:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

yahvuu wrote:

Chris Mohler schrieb:

I can express any CMYK color in RGB - but not the other way around.

now i'm confused :)

Is CMYK->RGB->CMYK roundtrip safe?

It depends on the gamuts of the respective colorspaces. These are all device dependent colorspaces, so their gamuts depend on the device in question. A gamut can be described by a 3 Dimensional volume, and in general two gamuts will have some region in common, a region unique to one gamut, and
a different region unique to the other gamut. This is often the case with RGB and CMYK spaces (ie. sRGB and a typical offset press).

Whether CMYK->RGB->CMYK is roundtrip safe depends on whether the RGB space fully encompasses the CMYK space, or (if it does not), if the gamut mapping is being reversed through the transformations. Some people deliberately use a very large RGB gamut working space to avoid clipping CMYK colors.

Note that by definition you loose the black inking information though such a conversion, as well as a degree of fidelity.

A traditional graphic arts workflow often looks something like:

Capture in RGB

Edit/adjust in RGB and/or Lab

Convert/Separate to CMYK

Adjust in CMYK

Layout/Compose/Add non-image elements in CMYK.

Convert to RGB for soft preview.

Print the CMYK.

Although there are other more complicated ones, including late binding (separating for the particular output device after layout/composition).

Graeme Gill.

------------------------------

Message: 6 Date: Wed, 25 Mar 2009 23:21:11 -0400 From: Louis Desjardins
Subject: Re: [Gimp-developer] GIMP PDF export plugin To: gespertino@gmail.com
Cc: gimp-developer@lists.XCF.Berkeley.EDU Message-ID:
Content-Type: text/plain; charset=windows-1252; format=flowed

Guillermo Espertino a ?crit :

Even though I agree that most of the CMYK cases mentioned use CMYK almost as spot colors, I can think of a very common usage scenario in Graphic Design where you need to be able to edit CMYK directly:

Corporate colors. Most frequently Pantones. Brands have their corporate colors and ask designers to use them, but they can not always afford extra spot passes in offset press, so the colors have to be converted to the most aproximate CMYK combination (the Pantone Bridge catalog is for that).

So you have to adjust the color of a photograph of a sign, a truck and a producto of your client to their corporate CMYK color.

It's a photograph, you need CMYK, you can't use spot.

This is a very common scenario, and it's a task for a image manipulation program.

I cannot agree more. It?s day-to-day work, day-to-day reality.

We could add dozens of examples, I guess.

To this point I don?t believe it?s that important to start figuring out whether the case is as good an example as it possibly can. I guess we are not at all trying to make the trial of the use of CMYK in the printing industry! (Now, that would be a total waste of time!) For those interested I bet a full glass of beer ? available at LGM! ? that they can find without too much efforts plenty of explanations about CMYK use in the printing industry on the web. Even non-offset printing go by CMYK and inkjet printing involves CMYK plus Light Cyan, Light Mangenta and/or Vivid Magenta and some Black variations. Somehow, somewhere in the process these printers need to convert the data so the printer can use one of the CMYK inks that?s in the machine, be it toner or printing ink. There is no way to ignore this reality.

We?re back to the basics of color reality. It?s either a projection of light or a reflexion of light. I mean, there are good books on the subject. This part is easy.

At this point in the discussion, it would be great to hear if the quality of the information provided so far in terms of explanations and examples is enough to lead someone or a group of developers in the GIMP team to envision how this CMYK capability would be implemented into GIMP and into what kind of developing frame (time, resource, GSoC, etc.)?

If we do need further examples, I am ready to provide more info, although I find the examples so far to be really on target.

Cheers!

Louis

Gez.

------------------------------

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

End of Gimp-developer Digest, Vol 78, Issue 49 **********************************************

On Thu, Mar 26, 2009 at 7:40 AM, < gimp-developer-request@lists.xcf.berkeley.edu> wrote:

Send Gimp-developer mailing list submissions to gimp-developer@lists.XCF.Berkeley.EDU

To subscribe or unsubscribe via the World Wide Web, visit https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer or, via email, send a message with subject or body 'help' to gimp-developer-request@lists.XCF.Berkeley.EDU

You can reach the person managing the list at gimp-developer-owner@lists.XCF.Berkeley.EDU

When replying, please edit your Subject line so it is more specific than "Re: Contents of Gimp-developer digest..."

Today's Topics:

1. Re: Dockable Dialogs Should be Dockable Everywhere (Alexandre Prokoudine)
2. Re: GIMP PDF export plugin (Andrew A. Gill) 3. Re: GIMP PDF export plugin (Andrew A. Gill) 4. Re: GIMP PDF export plugin (Graeme Gill) 5. a good student UI project... (Nicolas Robidoux) 6. a good student UI project... (Nicolas Robidoux)

----------------------------------------------------------------------

Message: 1 Date: Thu, 26 Mar 2009 01:16:04 +0300 From: Alexandre Prokoudine
Subject: Re: [Gimp-developer] Dockable Dialogs Should be Dockable Everywhere
To: GIMP Developer
Message-ID:

Content-Type: text/plain; charset=ISO-8859-1

On Thu, Mar 26, 2009 at 12:52 AM, drizzt wrote:

A tool should work out of box and help getting the work done right away.

But if each time you take your tool out of the box, it's behavior has changed, you cannot use it. So maybe you are creating a thing new users

can

play with, but please keep in mind that there are people currently using

the

tool !!!

I feel justified to reply only to this one, but it basically covers all of your email. You seem to be separating users into two groups: 1) those who like GIMP the way it is now and do not want any other UI and 2) new users who don't care what the previous UI looked like. And you seem to be in the first group. Too bad, because this distinction is incorrect. There's plenty of actual GIMP users who desperately want a better UI , a lot of users who kind of don't mind a new UI and a whole lot of users who don't know yet how much they will love a new UI.

Now regarding old tool/new tool. Do you know what is one of most disgusting things in applications like ACD Canvas that are over 20 years old? It's the ugly way their developers never ever refine them. Just like you say they keep all the old tools, all the old behaviours, everything they don't feel comfortable to throw away. And it piles up. How about "A" hotkey that is in use by three (sic!) different tools depending on tool group? How about 3-level nested toolbox? How about separate erasers for bitmap and vector objects? These applications become a horror to use for both old-timers and novices.

Now please give this a lot of thought before replying.

P.S. Shouting is of no help in this list.

Alexandre

------------------------------

Message: 2 Date: Wed, 25 Mar 2009 18:20:46 -0400 (EDT) From: "Andrew A. Gill"
Subject: Re: [Gimp-developer] GIMP PDF export plugin To: peter sikking
Cc: GIMP Developer ,
scribus@lists.scribus.info
Message-ID:
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII

On Wed, 25 Mar 2009, peter sikking wrote:

Alexandre Prokoudine wrote:

There was a somewhat heated discussion of this thread at linuxgraphics.ru forum and here are several examples from people who deal with prepress work on daily basis:

1. Client brings an image for poster in CMYK which needs color correction. Urgent work, not time to ask him to redo it. Double color space conversion is out of question. So he had to use Photoshop from VMWare.

2. You have a newspaper where first page should have a two-color photo: black (C=0%M=0%Y=0%Kt mention prepress needs explicitly.

A vision is an expression of the project of what they want the software to be.

There is choice in there, and the user community cannot demand that GIMP does certain things. For instance making web mockups (including the required html + css generation) is explicitly not supported.

Now what about that prepress. I think it is fairly safe to say that scribus' vision is to be prepress-king and GIMP should watch it not to want to overlap too much in that department. Everything in the above examples that reeks of newspaper, publications or multiple pages is a job for scribus. They want to do this.

Scribus is vector-based, not raster based.

I do not believe that Scribus has any intent to be allow raster-based editing, but I could be wrong.

I have CC'd the Scribus list. Let us hear their opinions. Does Scribus intend to allow people to tackle the problems listed above?

Or would you be able to trap the following image with Scribus?

The vision does speak about creating original art and I am all for it to bring this original art to the printing press. And not via the print dialog (I am also mr. openPrinting) but those printing presses that have operators. From the description above you can see what is should be like: first you create the art, then you bring it to the press. Mix master tape (in rgb) and then cut the lp (in cmyk).

As someone who works in prepress, I can tell you that when we take it from original artwork to press, we have to run any raster artwork through Photoshop or a competing product.

-- | Andrew A. Gill To ensure continued quality of service, | | this e-mail is being monitored by the NSA | | |
--

------------------------------

Message: 3 Date: Wed, 25 Mar 2009 18:21:09 -0400 (EDT) From: "Andrew A. Gill"
Subject: Re: [Gimp-developer] GIMP PDF export plugin To: Alexandre Prokoudine
Cc: GIMP Developer
Message-ID:
Content-Type: text/plain; charset="iso-8859-15"

On Wed, 25 Mar 2009, Alexandre Prokoudine wrote:

On Wed, Mar 25, 2009 at 7:27 PM, Andrew A. Gill wrote:

Agreed. ?I don't think anyone here is looking for a Photoshop clone (I

know

that I personally hate PS for a variety of reasons), but we do realize

that

it has to compete with Photoshop, and not addressing the issues of large sections of the design market when your competitor does is probably not

the

best move.

Do we realize that? :)

It is true that GIMP is usually seen as to-be-photoshop-substitution and its maturity in various areas in fact is the reason why people switch to GIMP. However GIMP doesn't seem to be driven by a will to make Photoshop die, die, die :)

It's a product that has similar features. It's a competing product.

(Personally, I want to make Photoshop die, die, die, but that's mainly because of a deep loathing for the UI.)

-- | Andrew A. Gill To ensure continued quality of service, | | this e-mail is being monitored by the NSA | | |
--

------------------------------

Message: 4 Date: Thu, 26 Mar 2009 10:19:12 +1100 From: Graeme Gill
Subject: Re: [Gimp-developer] GIMP PDF export plugin To: gimp-developer@lists.XCF.Berkeley.EDU Message-ID:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

peter sikking wrote:

Now what about that prepress. I think it is fairly safe to say that scribus' vision is to be prepress-king and GIMP should watch it not to want to overlap too much in that department. Everything in the above examples that reeks of newspaper, publications or multiple pages is a job for scribus. They want to do this.

As I understand it, Scribus is not a pixel editor, it is a page layout package, rather a different thing altogether.

So you're saying that Scribus should add a pixel editing package to their application, so that they can support CMYK and other non-RGB color spaces, duplicating an awful lot of what's in GIMP ?

The vision does speak about creating original art and I am all for it to bring this original art to the printing press. And not via the print dialog (I am also mr. openPrinting) but those printing presses that have operators. From the description above you can see what is should be like: first you create the art, then you bring it to the press. Mix master tape (in rgb) and then cut the lp (in cmyk).

I really don't think people working in the graphic arts are going to want to master two different pixel editing packages, simply because one of them doesn't support anything other than RGB. If they're in the Linux sphere, then I guess they need to go and look at using Krita instead.

[ ie. handling CMYK and other colorspaces is a superset capability, with RGB being a subset, and the colorspace is orthogonal to the pixel manipulation capabilities ]

Graeme Gill.

------------------------------

Message: 5 Date: Wed, 25 Mar 2009 19:32:24 -0400 From: Nicolas Robidoux
Subject: [Gimp-developer] a good student UI project... To: peter sikking
Cc: GIMP Developer
Message-ID:
Content-Type: text/plain; charset=us-ascii

Peter:

Here is a suggestion UI project for training purpose:

Right now, in GEGL, you have access to the whole 2-parameter family of cubic splines for resampling, as well as bilinear.

Pick three representatives, say Catmull-Rom ("lots" of halo), smoothing B-Splines ("lots" of blur) and bilinear ("lots" of jaggies).

(Instead of bilinear you could use nohalo a.k.a. gegl-sampler-sharp.c.)

If you want to stick to what's already in the Gimp you could use lanczos, cubic and bilinear.

Now: Any location within a triangle defines barycentric coordinates, which in term define a "blending" of the three methods.

Construct an interface which mimicks

http://www.cambridgeincolour.com/tutorials/digital-photo-enlargement.htm

except that instead of using it as a descriptive tool, we use it as a way of "picking your blend of poison."

Now, I don't know how attractive it is to ask people to pick a method by focusing on their weaknesses, but it certainly is a realistic way.

Also note that this interface would allow one to drive any triad of resampling methods which can be compared and characterized in terms of the three common artifacts.

Nicolas Robidoux Laurentian University

------------------------------

Message: 6 Date: Wed, 25 Mar 2009 19:39:57 -0400 From: Nicolas Robidoux
Subject: [Gimp-developer] a good student UI project... To: peter sikking , GIMP Developer

Message-ID:
Content-Type: text/plain; charset=us-ascii

Peter:

Of course, you could also use the interface to choose between three cubic methods, which makes a lot of sense within GEGL (the "jaggy" one would be lagrangian bicubic).

Nicolas Robidoux Universite Laurentienne

------------------------------

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

End of Gimp-developer Digest, Vol 78, Issue 48 **********************************************

On Fri, Mar 27, 2009 at 4:58 AM, < gimp-developer-request@lists.xcf.berkeley.edu> wrote:

Send Gimp-developer mailing list submissions to gimp-developer@lists.XCF.Berkeley.EDU

To subscribe or unsubscribe via the World Wide Web, visit https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer or, via email, send a message with subject or body 'help' to gimp-developer-request@lists.XCF.Berkeley.EDU

You can reach the person managing the list at gimp-developer-owner@lists.XCF.Berkeley.EDU

When replying, please edit your Subject line so it is more specific than "Re: Contents of Gimp-developer digest..."

Today's Topics:

1. Re: Gimp-developer Digest, Vol 78, Issue 48 (Hollywoodkiller Movies)

----------------------------------------------------------------------

Message: 1 Date: Fri, 27 Mar 2009 04:57:59 +0800 From: Hollywoodkiller Movies
Subject: Re: [Gimp-developer] Gimp-developer Digest, Vol 78, Issue 48 To: gimp-developer@lists.xcf.berkeley.edu Message-ID:

Content-Type: text/plain; charset="iso-8859-1"

On Thu, Mar 26, 2009 at 7:40 AM, < gimp-developer-request@lists.xcf.berkeley.edu> wrote:

Send Gimp-developer mailing list submissions to gimp-developer@lists.XCF.Berkeley.EDU

To subscribe or unsubscribe via the World Wide Web, visit https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer or, via email, send a message with subject or body 'help' to gimp-developer-request@lists.XCF.Berkeley.EDU

You can reach the person managing the list at gimp-developer-owner@lists.XCF.Berkeley.EDU

When replying, please edit your Subject line so it is more specific than "Re: Contents of Gimp-developer digest..."

Today's Topics:

1. Re: Dockable Dialogs Should be Dockable Everywhere (Alexandre Prokoudine)
2. Re: GIMP PDF export plugin (Andrew A. Gill) 3. Re: GIMP PDF export plugin (Andrew A. Gill) 4. Re: GIMP PDF export plugin (Graeme Gill) 5. a good student UI project... (Nicolas Robidoux) 6. a good student UI project... (Nicolas Robidoux)

----------------------------------------------------------------------

Message: 1 Date: Thu, 26 Mar 2009 01:16:04 +0300 From: Alexandre Prokoudine
Subject: Re: [Gimp-developer] Dockable Dialogs Should be Dockable Everywhere
To: GIMP Developer
Message-ID:

Content-Type: text/plain; charset=ISO-8859-1

On Thu, Mar 26, 2009 at 12:52 AM, drizzt wrote:

A tool should work out of box and help getting the work done right

away.

But if each time you take your tool out of the box, it's behavior has changed, you cannot use it. So maybe you are creating a thing new users

can

play with, but please keep in mind that there are people currently

using

the

tool !!!

I feel justified to reply only to this one, but it basically covers all of your email. You seem to be separating users into two groups: 1) those who like GIMP the way it is now and do not want any other UI and 2) new users who don't care what the previous UI looked like. And you seem to be in the first group. Too bad, because this distinction is incorrect. There's plenty of actual GIMP users who desperately want a better UI , a lot of users who kind of don't mind a new UI and a whole lot of users who don't know yet how much they will love a new UI.

Now regarding old tool/new tool. Do you know what is one of most disgusting things in applications like ACD Canvas that are over 20 years old? It's the ugly way their developers never ever refine them. Just like you say they keep all the old tools, all the old behaviours, everything they don't feel comfortable to throw away. And it piles up. How about "A" hotkey that is in use by three (sic!) different tools depending on tool group? How about 3-level nested toolbox? How about separate erasers for bitmap and vector objects? These applications become a horror to use for both old-timers and novices.

Now please give this a lot of thought before replying.

P.S. Shouting is of no help in this list.

Alexandre

------------------------------

Message: 2 Date: Wed, 25 Mar 2009 18:20:46 -0400 (EDT) From: "Andrew A. Gill"
Subject: Re: [Gimp-developer] GIMP PDF export plugin To: peter sikking
Cc: GIMP Developer ,
scribus@lists.scribus.info
Message-ID:
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII

On Wed, 25 Mar 2009, peter sikking wrote:

Alexandre Prokoudine wrote:

There was a somewhat heated discussion of this thread at linuxgraphics.ru forum and here are several examples from people who deal with prepress work on daily basis:

1. Client brings an image for poster in CMYK which needs color correction. Urgent work, not time to ask him to redo it. Double color space conversion is out of question. So he had to use Photoshop from VMWare.

2. You have a newspaper where first page should have a two-color photo: black (C=0%M=0%Y=0%Kt mention prepress needs explicitly.

A vision is an expression of the project of what they want the software to be.

There is choice in there, and the user community cannot demand that GIMP does certain things. For instance making web mockups (including the required html + css generation) is explicitly not supported.

Now what about that prepress. I think it is fairly safe to say that scribus' vision is to be prepress-king and GIMP should watch it not to want to overlap too much in that department. Everything in the above examples that reeks of newspaper, publications or multiple pages is a job for scribus. They want to do this.

Scribus is vector-based, not raster based.

I do not believe that Scribus has any intent to be allow raster-based editing, but I could be wrong.

I have CC'd the Scribus list. Let us hear their opinions. Does Scribus intend to allow people to tackle the problems listed above?

Or would you be able to trap the following image with Scribus?

The vision does speak about creating original art and I am all for it to bring this original art to the printing press. And not via the print dialog (I am also mr. openPrinting) but those printing presses that have operators. From the description above you can see what is should be like: first you create the art, then you bring it to the press. Mix master tape (in rgb) and then cut the lp (in cmyk).

As someone who works in prepress, I can tell you that when we take it from original artwork to press, we have to run any raster artwork through Photoshop or a competing product.

-- | Andrew A. Gill To ensure continued quality of service, | | this e-mail is being monitored by the NSA | | |
--

------------------------------

Message: 3 Date: Wed, 25 Mar 2009 18:21:09 -0400 (EDT) From: "Andrew A. Gill"
Subject: Re: [Gimp-developer] GIMP PDF export plugin To: Alexandre Prokoudine
Cc: GIMP Developer
Message-ID:
Content-Type: text/plain; charset="iso-8859-15"

On Wed, 25 Mar 2009, Alexandre Prokoudine wrote:

On Wed, Mar 25, 2009 at 7:27 PM, Andrew A. Gill wrote:

Agreed. ?I don't think anyone here is looking for a Photoshop clone (I

know

that I personally hate PS for a variety of reasons), but we do realize

that

it has to compete with Photoshop, and not addressing the issues of

large

sections of the design market when your competitor does is probably

not

the

best move.

Do we realize that? :)

It is true that GIMP is usually seen as to-be-photoshop-substitution and its maturity in various areas in fact is the reason why people switch to GIMP. However GIMP doesn't seem to be driven by a will to make Photoshop die, die, die :)

It's a product that has similar features. It's a competing product.

(Personally, I want to make Photoshop die, die, die, but that's mainly because of a deep loathing for the UI.)

-- | Andrew A. Gill To ensure continued quality of service, | | this e-mail is being monitored by the NSA | | |
--

------------------------------

Message: 4 Date: Thu, 26 Mar 2009 10:19:12 +1100 From: Graeme Gill
Subject: Re: [Gimp-developer] GIMP PDF export plugin To: gimp-developer@lists.XCF.Berkeley.EDU Message-ID:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

peter sikking wrote:

Now what about that prepress. I think it is fairly safe to say that scribus' vision is to be prepress-king and GIMP should watch it not to want to overlap too much in that department. Everything in the above examples that reeks of newspaper, publications or multiple pages is a job for scribus. They want to do this.

As I understand it, Scribus is not a pixel editor, it is a page layout package, rather a different thing altogether.

So you're saying that Scribus should add a pixel editing package to their application, so that they can support CMYK and other non-RGB color spaces, duplicating an awful lot of what's in GIMP ?

The vision does speak about creating original art and I am all for it to bring this original art to the printing press. And not via the print dialog (I am also mr. openPrinting) but those printing presses that have operators. From the description above you can see what is should be like: first you create the art, then you bring it to the press. Mix master tape (in rgb) and then cut the lp (in cmyk).

I really don't think people working in the graphic arts are going to want to master two different pixel editing packages, simply because one of them doesn't support anything other than RGB. If they're in the Linux sphere, then I guess they need to go and look at using Krita instead.

[ ie. handling CMYK and other colorspaces is a superset capability, with RGB being a subset, and the colorspace is orthogonal to the pixel manipulation capabilities ]

Graeme Gill.

------------------------------

Message: 5 Date: Wed, 25 Mar 2009 19:32:24 -0400 From: Nicolas Robidoux
Subject: [Gimp-developer] a good student UI project... To: peter sikking
Cc: GIMP Developer
Message-ID:
Content-Type: text/plain; charset=us-ascii

Peter:

Here is a suggestion UI project for training purpose:

Right now, in GEGL, you have access to the whole 2-parameter family of cubic splines for resampling, as well as bilinear.

Pick three representatives, say Catmull-Rom ("lots" of halo), smoothing B-Splines ("lots" of blur) and bilinear ("lots" of jaggies).

(Instead of bilinear you could use nohalo a.k.a. gegl-sampler-sharp.c.)

If you want to stick to what's already in the Gimp you could use lanczos, cubic and bilinear.

Now: Any location within a triangle defines barycentric coordinates, which in term define a "blending" of the three methods.

Construct an interface which mimicks

http://www.cambridgeincolour.com/tutorials/digital-photo-enlargement.htm

except that instead of using it as a descriptive tool, we use it as a way of "picking your blend of poison."

Now, I don't know how attractive it is to ask people to pick a method by focusing on their weaknesses, but it certainly is a realistic way.

Also note that this interface would allow one to drive any triad of resampling methods which can be compared and characterized in terms of the three common artifacts.

Nicolas Robidoux Laurentian University

------------------------------

Message: 6 Date: Wed, 25 Mar 2009 19:39:57 -0400 From: Nicolas Robidoux
Subject: [Gimp-developer] a good student UI project... To: peter sikking , GIMP Developer

Message-ID:
Content-Type: text/plain; charset=us-ascii

Peter:

Of course, you could also use the interface to choose between three cubic methods, which makes a lot of sense within GEGL (the "jaggy" one would be lagrangian bicubic).

Nicolas Robidoux Universite Laurentienne

------------------------------

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

End of Gimp-developer Digest, Vol 78, Issue 48 **********************************************

--
http://www.watch-movies-online-hollywoodkiller.com -------------- next part -------------- An HTML attachment was scrubbed...
URL: /lists/gimp-developer/attachments/20090327/82530429/attachment.html

------------------------------

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

End of Gimp-developer Digest, Vol 78, Issue 54 **********************************************

On Fri, Mar 27, 2009 at 4:57 AM, < gimp-developer-request@lists.xcf.berkeley.edu> wrote:

Send Gimp-developer mailing list submissions to gimp-developer@lists.XCF.Berkeley.EDU

To subscribe or unsubscribe via the World Wide Web, visit https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer or, via email, send a message with subject or body 'help' to gimp-developer-request@lists.XCF.Berkeley.EDU

You can reach the person managing the list at gimp-developer-owner@lists.XCF.Berkeley.EDU

When replying, please edit your Subject line so it is more specific than "Re: Contents of Gimp-developer digest..."

Today's Topics:

1. Re: Gimp-developer Digest, Vol 78, Issue 49 (Hollywoodkiller Movies)

----------------------------------------------------------------------

Message: 1 Date: Fri, 27 Mar 2009 04:57:44 +0800 From: Hollywoodkiller Movies
Subject: Re: [Gimp-developer] Gimp-developer Digest, Vol 78, Issue 49 To: gimp-developer@lists.xcf.berkeley.edu Message-ID:

Content-Type: text/plain; charset="iso-8859-1"

On Thu, Mar 26, 2009 at 11:21 AM, < gimp-developer-request@lists.xcf.berkeley.edu> wrote:

Send Gimp-developer mailing list submissions to gimp-developer@lists.XCF.Berkeley.EDU

To subscribe or unsubscribe via the World Wide Web, visit https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer or, via email, send a message with subject or body 'help' to gimp-developer-request@lists.XCF.Berkeley.EDU

You can reach the person managing the list at gimp-developer-owner@lists.XCF.Berkeley.EDU

When replying, please edit your Subject line so it is more specific than "Re: Contents of Gimp-developer digest..."

Today's Topics:

1. Re: GIMP PDF export plugin (Andrew A. Gill) 2. Re: a good student UI project... (yahvuu) 3. Re: GIMP PDF export plugin (Guillermo Espertino) 4. Re: GIMP PDF export plugin (Andrew A. Gill) 5. Re: GIMP PDF export plugin (Graeme Gill) 6. Re: GIMP PDF export plugin (Louis Desjardins)

----------------------------------------------------------------------

Message: 1 Date: Wed, 25 Mar 2009 20:40:25 -0400 (EDT) From: "Andrew A. Gill"
Subject: Re: [Gimp-developer] GIMP PDF export plugin To: graeme@argyllcms.com
Cc: gimp-developer
Message-ID:
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII

On Thu, 26 Mar 2009, Graeme Gill wrote:

As I understand it, Scribus is not a pixel editor, it is a page layout package, rather a different thing altogether.

For the record, Scribus does allow pixel editing.

When you right click on an image and select Edit Image, it opens the image in GIMP.

I think that's pretty strong evidence that there's no intent to do raster editing in Scribus itself.

I really don't think people working in the graphic arts are going to want to master two different pixel editing packages, simply because one of them doesn't support anything other than RGB. If they're in the Linux sphere, then I guess they need to go and look at using Krita instead.

FYI, Krita is extremely buggy. It has an SDI, which some people (e.g. me) don't like, but the code will improve and there may be improvements in the interface. Krita may indeed surpass GIMP. Sad, really, since I think GIMP can be the better product.

[from here out, `you' refers to core GIMP developers]

We want you to succeed, and all you need to do to succeed is to address some of the issues that users need. If you're telling us that GIMP has no intention of ever providing those things, we'll find another product. Maybe Krita when it becomes vaguely stable, or maybe a fork.

But you've got the time to do it before the others catch up, and you've got GEGL, the toolset to do it right.

Here's a thought: I can code. I'm sure others on this list can, too. Why don't you tell us what you would require for a CMYK mode to be incorporated into the trunk of GIMP. We can all read the API, but you can tell us what coding standards we need, what toes we can't step on and why other attempts to add similar functionality (like Cinepaint nee FilmGimp) foundered, and what we can do to avoid making those same mistakes.

If you tell us what we need to do, we can do it. That's the point of Open Source!

If you don't, people are going to get sick of the excuses and simply move on to develop this functionality somewhere else.

From the outside, GIMP is seen as a shining example of what open

source is capable of. Inside the OSS movement, it's seen much like the XFree86 guys--constantly bickering about the same issues. I'm sure that you'd have no trouble getting developers to work on a flagship product if they were convinced that it would end some of the internal conflicts in OSS.

-- | Andrew A. Gill To ensure continued quality of service, | | this e-mail is being monitored by the NSA | | |
--

------------------------------

Message: 2 Date: Thu, 26 Mar 2009 02:12:03 +0100 From: yahvuu
Subject: Re: [Gimp-developer] a good student UI project... To: peter sikking
Cc: GIMP Developer
Message-ID:
Content-Type: text/plain; charset=ISO-8859-1

Hi Peter,

some ideas from a typical photo workflow:

perspective correction - select some prominent lines from the image and "get them straight"

alignment of horizon line - in cooperation with an automated guess?

crop & rotate, set - virtual photography ala google earth? aspect ratio perhaps even with composition aids (rule of thirds, Westhoff's Diagonal Method, etc)

levels, curves - could support the user's intention more directly: - mark places in the image, which should be brighter/darker,
or have more/less contrast or modified colors - the whitepoint, graypoint pickers could be adjustable markers
on the image. Or a completely different method for whitebalance?
- if tones are getting compressed, better control of where the
clipping happens (separately for each of R,G,B,

Value)

gradation map - nearly the same: map image points to positions in the gradient

greetings,
peter

------------------------------

Message: 3 Date: Wed, 25 Mar 2009 22:13:39 -0300 From: Guillermo Espertino
Subject: Re: [Gimp-developer] GIMP PDF export plugin To: gimp-developer@lists.XCF.Berkeley.EDU Message-ID:
Content-Type: text/plain

Even though I agree that most of the CMYK cases mentioned use CMYK almost as spot colors, I can think of a very common usage scenario in Graphic Design where you need to be able to edit CMYK directly:

Corporate colors. Most frequently Pantones. Brands have their corporate colors and ask designers to use them, but they can not always afford extra spot passes in offset press, so the colors have to be converted to the most aproximate CMYK combination (the Pantone Bridge catalog is for that).

So you have to adjust the color of a photograph of a sign, a truck and a producto of your client to their corporate CMYK color.

It's a photograph, you need CMYK, you can't use spot.

This is a very common scenario, and it's a task for a image manipulation program.

Gez.

------------------------------

Message: 4 Date: Wed, 25 Mar 2009 21:45:17 -0400 (EDT) From: "Andrew A. Gill"
Subject: Re: [Gimp-developer] GIMP PDF export plugin To: Guillermo Espertino
Cc: gimp-developer@lists.XCF.Berkeley.EDU Message-ID:
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Wed, 25 Mar 2009, Guillermo Espertino wrote:

Even though I agree that most of the CMYK cases mentioned use CMYK almost as spot colors, I can think of a very common usage scenario in Graphic Design where you need to be able to edit CMYK directly:

Corporate colors. Most frequently Pantones. Brands have their corporate colors and ask designers to use them, but they can not always afford extra spot passes in offset press, so the colors have to be converted to the most aproximate CMYK combination (the Pantone Bridge catalog is for that).

So you have to adjust the color of a photograph of a sign, a truck and

a

producto of your client to their corporate CMYK color.

It's a photograph, you need CMYK, you can't use spot.

This is a very common scenario, and it's a task for a image

manipulation

program.

Sadly for the cause of CMYK, that's not really a good example. That's a better example for the need for Pantone and other color matching system support.

Which GIMP will eventually need, but I'm thinking that day will come a decade or two from now, hopefully when there's an open source rival for Pantone.

(I actually plan to take that task on, myself in a few years, as part of some research)

--
| Andrew A. Gill To ensure continued quality of service, | | this e-mail is being monitored by the NSA | | |
--

------------------------------

Message: 5 Date: Thu, 26 Mar 2009 12:51:15 +1100 From: Graeme Gill
Subject: Re: [Gimp-developer] GIMP PDF export plugin To: gimp-developer@lists.XCF.Berkeley.EDU Message-ID:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

yahvuu wrote:

Chris Mohler schrieb:

I can express any CMYK color in RGB - but not the other way around.

now i'm confused :)

Is CMYK->RGB->CMYK roundtrip safe?

It depends on the gamuts of the respective colorspaces. These are all device dependent colorspaces, so their gamuts depend on the device in question. A gamut can be described by a 3 Dimensional volume, and in general two gamuts will have some region in common, a region unique to one gamut, and
a different region unique to the other gamut. This is often the case with RGB and CMYK spaces (ie. sRGB and a typical offset press).

Whether CMYK->RGB->CMYK is roundtrip safe depends on whether the RGB space fully encompasses the CMYK space, or (if it does not), if the gamut mapping is being reversed through the transformations. Some people deliberately use a very large RGB gamut working space to avoid clipping CMYK colors.

Note that by definition you loose the black inking information though such a conversion, as well as a degree of fidelity.

A traditional graphic arts workflow often looks something like:

Capture in RGB

Edit/adjust in RGB and/or Lab

Convert/Separate to CMYK

Adjust in CMYK

Layout/Compose/Add non-image elements in CMYK.

Convert to RGB for soft preview.

Print the CMYK.

Although there are other more complicated ones, including late binding (separating for the particular output device after layout/composition).

Graeme Gill.

------------------------------

Message: 6 Date: Wed, 25 Mar 2009 23:21:11 -0400 From: Louis Desjardins
Subject: Re: [Gimp-developer] GIMP PDF export plugin To: gespertino@gmail.com
Cc: gimp-developer@lists.XCF.Berkeley.EDU Message-ID:
Content-Type: text/plain; charset=windows-1252; format=flowed

Guillermo Espertino a ?crit :

Even though I agree that most of the CMYK cases mentioned use CMYK almost as spot colors, I can think of a very common usage scenario in Graphic Design where you need to be able to edit CMYK directly:

Corporate colors. Most frequently Pantones. Brands have their corporate colors and ask designers to use them, but they can not always afford extra spot passes in offset press, so the colors have to be converted to the most aproximate CMYK combination (the Pantone Bridge catalog is for that).

So you have to adjust the color of a photograph of a sign, a truck and

a

producto of your client to their corporate CMYK color.

It's a photograph, you need CMYK, you can't use spot.

This is a very common scenario, and it's a task for a image

manipulation

program.

I cannot agree more. It?s day-to-day work, day-to-day reality.

We could add dozens of examples, I guess.

To this point I don?t believe it?s that important to start figuring out whether the case is as good an example as it possibly can. I guess we are not at all trying to make the trial of the use of CMYK in the printing industry! (Now, that would be a total waste of time!) For those interested I bet a full glass of beer ? available at LGM! ? that they can find without too much efforts plenty of explanations about CMYK use in the printing industry on the web. Even non-offset printing go by CMYK and inkjet printing involves CMYK plus Light Cyan, Light Mangenta and/or Vivid Magenta and some Black variations. Somehow, somewhere in the process these printers need to convert the data so the printer can use one of the CMYK inks that?s in the machine, be it toner or printing ink. There is no way to ignore this reality.

We?re back to the basics of color reality. It?s either a projection of light or a reflexion of light. I mean, there are good books on the subject. This part is easy.

At this point in the discussion, it would be great to hear if the quality of the information provided so far in terms of explanations and examples is enough to lead someone or a group of developers in the GIMP team to envision how this CMYK capability would be implemented into GIMP and into what kind of developing frame (time, resource, GSoC, etc.)?

If we do need further examples, I am ready to provide more info, although I find the examples so far to be really on target.

Cheers!

Louis

Gez.

------------------------------

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

End of Gimp-developer Digest, Vol 78, Issue 49 **********************************************

--
http://www.watch-movies-online-hollywoodkiller.com -------------- next part -------------- An HTML attachment was scrubbed...
URL: /lists/gimp-developer/attachments/20090327/937f8ac1/attachment.html

------------------------------

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

End of Gimp-developer Digest, Vol 78, Issue 53 **********************************************