On Thu, Mar 26, 2009 at 11:21 AM, <
gimp-developer-requ...@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-requ...@lists.xcf.berkeley.edu
>
> You can reach the person managing the list at
>        gimp-developer-ow...@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" <superlu...@frontiernet.net>
> Subject: Re: [Gimp-developer] GIMP PDF export plugin
> To: gra...@argyllcms.com
> Cc: gimp-developer <gimp-developer@lists.XCF.Berkeley.EDU>
> Message-ID: <alpine.lnx.1.00.0903251935200.31...@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 |
> | <superlu...@frontiernet.net> <http://www.needsfoodbadly.com> |
>                                                               --
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 26 Mar 2009 02:12:03 +0100
> From: yahvuu <yah...@gmail.com>
> Subject: Re: [Gimp-developer] a good student UI project...
> To: peter sikking <pe...@mmiworks.net>
> Cc: GIMP Developer <gimp-developer@lists.XCF.Berkeley.EDU>
> Message-ID: <49cad663.9060...@gmail.com>
> 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 <gespert...@gmail.com>
> Subject: Re: [Gimp-developer] GIMP PDF export plugin
> To: gimp-developer@lists.XCF.Berkeley.EDU
> Message-ID: <1238030019.8040.5.ca...@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" <superlu...@frontiernet.net>
> Subject: Re: [Gimp-developer] GIMP PDF export plugin
> To: Guillermo Espertino <gespert...@gmail.com>
> Cc: gimp-developer@lists.XCF.Berkeley.EDU
> Message-ID: <alpine.lnx.1.00.0903252119201.31...@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 |
> | <superlu...@frontiernet.net> <http://www.needsfoodbadly.com> |
>                                                               --
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 26 Mar 2009 12:51:15 +1100
> From: Graeme Gill <grae...@argyllcms.com>
> Subject: Re: [Gimp-developer] GIMP PDF export plugin
> To: gimp-developer@lists.XCF.Berkeley.EDU
> Message-ID: <49cadf93.80...@argyllcms.com>
> 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_desjard...@mardigrafe.com>
> Subject: Re: [Gimp-developer] GIMP PDF export plugin
> To: gespert...@gmail.com
> Cc: gimp-developer@lists.XCF.Berkeley.EDU
> Message-ID: <49caf4a7....@mardigrafe.com>
> 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
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Reply via email to