On Thu, Mar 26, 2009 at 11:21 AM, <gimp-developer-request@xxxxxxxxxxxxxxxxxxxxxx> wrote:
Send Gimp-developer mailing list submissions to
gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxx
You can reach the person managing the list at
gimp-developer-owner@xxxxxxxxxxxxxxxxxxxxxx
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" <superluser@xxxxxxxxxxxxxxx>
Subject: Re: GIMP PDF export plugin
To: graeme@xxxxxxxxxxxxx
Cc: gimp-developer <gimp-developer@xxxxxxxxxxxxxxxxxxxxxx>
Message-ID: <alpine.LNX.1.00.0903251935200.31469@localhost>
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 |
| <superluser@xxxxxxxxxxxxxxx> <http://www.needsfoodbadly.com> |
--
------------------------------
Message: 2
Date: Thu, 26 Mar 2009 02:12:03 +0100
From: yahvuu <yahvuu@xxxxxxxxx>
Subject: Re: a good student UI project...
To: peter sikking <peter@xxxxxxxxxxxx>
Cc: GIMP Developer <gimp-developer@xxxxxxxxxxxxxxxxxxxxxx>
Message-ID: <49CAD663.9060400@xxxxxxxxx>
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 <gespertino@xxxxxxxxx>
Subject: Re: GIMP PDF export plugin
To: gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
Message-ID: <1238030019.8040.5.camel@ohweb01a>
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" <superluser@xxxxxxxxxxxxxxx>
Subject: Re: GIMP PDF export plugin
To: Guillermo Espertino <gespertino@xxxxxxxxx>
Cc: gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
Message-ID: <alpine.LNX.1.00.0903252119201.31469@localhost>
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 |
| <superluser@xxxxxxxxxxxxxxx> <http://www.needsfoodbadly.com> |
--
------------------------------
Message: 5
Date: Thu, 26 Mar 2009 12:51:15 +1100
From: Graeme Gill <graeme2@xxxxxxxxxxxxx>
Subject: Re: GIMP PDF export plugin
To: gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
Message-ID: <49CADF93.80902@xxxxxxxxxxxxx>
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 <louis_desjardins@xxxxxxxxxxxxxx>
Subject: Re: GIMP PDF export plugin
To: gespertino@xxxxxxxxx
Cc: gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
Message-ID: <49CAF4A7.506@xxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxxxxx
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
_______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
