[Gimp-developer] GIMP Developer Meeting #2 - March 14th 2011

[LightningIsMyName]

Hello,

The next GIMP developer meeting (users are also welcome!) will take
place Monday, March 14th 2011, on 10:00 PM CET (GMT+1).
The agenda can be found here:
http://gimp-wiki.who.ee/index.php/Hacking:Dev_Meeting_14_Mar_2011

Right now, the main topics are:
* Reviewing last meeting's decision
* Serious discussion of GIMP's programming language
* 2.8 - Get it out!

Proposals for more topics to discuss will be accepted by replying to this email.

The meeting will be in the same place as the previous time (gathering
will be done on the GIMP irc irc://irc.gimp.org/#gimp and the actual
meeting will take place in a seperate channel that will be announced
on the main channel), at the same good hour :)

Logs and summaries of the previous meeting can be found here:
http://gimp-wiki.who.ee/index.php/Hacking:Dev_Meeting_28_Feb_2011

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

Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions

[Tobias Oelgarte]

Am 08.03.2011 21:07, schrieb Bogdan Szczurek:
>> I really miss some basic vector functionality in Gimp. In my last
>> works i used Inkscape and Gimp together. Drawing sharp outlines in
>> Inkscape, exporting them to PNG and imported them into Gimp again, to
>> work with brushes and colors. Basically i used Inkscape to create
>> Alpha-Layers for accurate strokes. The exporting and importing was
>> some kind of pain. Just the ability to create basic shapes (Bezier
>> contours), would be a great improvement. It doesn't need to provide
>> anything. But it should be as simple as the Polygon-Tool and the
>> Node-Tool from Inkscape. That would basically all i would need.
>> Opening Inkscape, drawing a simple Shape (outline), exporting it,
>> importing it and then fill it in Gimp is not a comfortable way.
> Skippping back and forth from Inkscape to GIMP doesn't sound good to me
> either, but wasn't existing “path” tool sufficient in your case? Don't
> get me wrong, I'm just trying to understand the task you were up to do.
>
> My best!
> thebodzio
At first i have to note, that the usage of the current path tool in Gimp 
is a pain. Its really hard, needlessly complicated  to work with. The 
behavior of Inkscape is way superior, even if it is not perfect. Also it 
is hard to manage multiple paths at once. I won't say that Gimp is 
missing a feature you could use for the same things, but i just don't 
want to use it, since it takes me longer to work with it as Skipping 
back and forth between Inkscape and Gimp... (not a good sign for useability)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions

[Bogdan Szczurek]

> On Tue, Mar 8, 2011 at 8:00 PM, Bogdan Szczurek 
> wrote:
> >> > I've got a dream about visual editing program consisting of
> >> > different components, each taking care of one of presentation
> >> > aspects with one underlaying rendering engine (target aware
> >> > angine—I don't like cairo's “I don't care what's on the end”
> >> > attitude ;)).
> >>
> >> It's what we, utter geeks, call a framework :)
> >
> > That adds +10 to "coolness" but don't let everybody know ;)
> >
> >> Deneba/ACD Canvas was an attempt to create such one, but it was
> >> done on top of software started in mid 80s. Sometimes a whole week
> >> passes when I don't wake up in cold sweat seeing it in my dreams.
> >
> > Funny stuff… :). But seriously, sometimes it's good for somebody to
> > try a thing that didn't work out last time. Because of that
> > stubborness we're able to fly by airplanes nowadays ;).
> >
> > I consider idea of one flexible uberapp much more sensible and
> > appealing than implementing wee bit of “alien world” in different
> > apps—just seems half-solution for me.
> 
> So do I,. and a "framework" that can make something like that happen
> is called GEGL ;)

I'm happy to hear that! :)

> http://pippin.gimp.org/tmp/gegl-foo/
> 
> Buried in history of the GEGL repo is a GTK+ based UI with at various
> revisions both freehand painting with simple dynamics, as well as..
> node based both bezier and spiro curve editing bits, integrated with
> generic layer filters and more.. it is/was not really that much code,
> but it was sloppy code thrown together with left-over pieces from a
> video editor.
> 
> I am from time to time toying with resurrecting that project as a
> minimal thing show-casing what is possible to achieve. If I do get
> around to do that I would probably avoid doing it with C though, so it
> would be a complete rewrite and not really a resurrection.

Best regards!
thebodzio


signature.asc
Description: PGP signature
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP vs Photoshop

[Bogdan Szczurek]

> > Yes, but why use RGB at all if one can use e.g. XYZ from the start?
> > So "wide" RGB would also require greater than 8 bit depths to work
> > satisfactorily (HSV, HSL or Lab do quite nicely even with 8 bits per
> > component). I think one consolation is possible backward
> > compatibility with some other RGB spaces, but isn't BC a b**ch? ;)
> > Besides there's a trouble of defining such “new” RGB workspace:
> > what white point should be choosen and what primaries (all have to
> > be defined in some absolute color coordinates BTW)?  Whatever space
> > would be choosen we wouldn't escape color conversions in color
> > managed workflow, so while I'm not RGB enemy I fail to see the
> > reason to stick to it especially since there are “wider” color
> > spaces that are more intuitive to work with.
> 
> It is a matter of which well defined color space the operations
> desired provide sensible outputs. For some types of operations doing
> them in premultiplied linear light RGB is superior to doing them in
> sRGB, CIE Lab or other more or less perceptual spaces, for other
> operations the opposite is true. My stance is that the sliders on an
> operations should be predictable and always do the same thing for the
> colorimetrically absolute same color - whis is why the operations of
> GEGL request temporary working buffers in their preferred working
> space (this is where babl does the; optimized; conversions you
> correctly state have to happen) rather than blindly handling incoming
> numbers.

All of it seems reasonable to me :).

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

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

> The preferred^Wenforced working space of some operations in GEGL might
> need some scrutinization and review, though for compositing; gaussian
> blurs; interpolation etc I think the current choice of linear light
> RGB.
> 
> GEGL also does not support working in an internal 8bit or 16bit mode,
> it is floating point with high precision and additional
> headroom/footroom (wide gamut/HDR) for all temporary buffers, if the
> desired output is 8bit it happens when displayed or exported.
> Operations like for instance unsharp-mask does not work correctly if
> termporary results are clipped.

I can only say that I back that up.

Best regards!
thebodzio


signature.asc
Description: PGP signature
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions

[Øyvind Kolås]

On Tue, Mar 8, 2011 at 8:00 PM, Bogdan Szczurek  wrote:
>> > I've got a dream about visual editing program consisting of
>> > different components, each taking care of one of presentation
>> > aspects with one underlaying rendering engine (target aware
>> > angine—I don't like cairo's “I don't care what's on the end”
>> > attitude ;)).
>>
>> It's what we, utter geeks, call a framework :)
>
> That adds +10 to "coolness" but don't let everybody know ;)
>
>> Deneba/ACD Canvas was an attempt to create such one, but it was done
>> on top of software started in mid 80s. Sometimes a whole week passes
>> when I don't wake up in cold sweat seeing it in my dreams.
>
> Funny stuff… :). But seriously, sometimes it's good for somebody to try
> a thing that didn't work out last time. Because of that stubborness
> we're able to fly by airplanes nowadays ;).
>
> I consider idea of one flexible uberapp much more sensible and
> appealing than implementing wee bit of “alien world” in different
> apps—just seems half-solution for me.

So do I,. and a "framework" that can make something like that happen
is called GEGL ;)

http://pippin.gimp.org/tmp/gegl-foo/

Buried in history of the GEGL repo is a GTK+ based UI with at various
revisions both freehand painting with simple dynamics, as well as..
node based both bezier and spiro curve editing bits, integrated with
generic layer filters and more.. it is/was not really that much code,
but it was sloppy code thrown together with left-over pieces from a
video editor.

I am from time to time toying with resurrecting that project as a
minimal thing show-casing what is possible to achieve. If I do get
around to do that I would probably avoid doing it with C though, so it
would be a complete rewrite and not really a resurrection.

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

Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions

[Bogdan Szczurek]

> I really miss some basic vector functionality in Gimp. In my last
> works i used Inkscape and Gimp together. Drawing sharp outlines in
> Inkscape, exporting them to PNG and imported them into Gimp again, to
> work with brushes and colors. Basically i used Inkscape to create
> Alpha-Layers for accurate strokes. The exporting and importing was
> some kind of pain. Just the ability to create basic shapes (Bezier
> contours), would be a great improvement. It doesn't need to provide
> anything. But it should be as simple as the Polygon-Tool and the
> Node-Tool from Inkscape. That would basically all i would need.
> Opening Inkscape, drawing a simple Shape (outline), exporting it,
> importing it and then fill it in Gimp is not a comfortable way.

Skippping back and forth from Inkscape to GIMP doesn't sound good to me
either, but wasn't existing “path” tool sufficient in your case? Don't
get me wrong, I'm just trying to understand the task you were up to do.

My best!
thebodzio


signature.asc
Description: PGP signature
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions

[Bogdan Szczurek]

> >> - vector layers and drawing geometric primitives [1]
> >
> > I'm not convinced of the notion of vector layers. Sure they can be
> > nice addition but I fear they'll end up being quite frustrating. I
> > think so because to make them as ellastic and usable as in vector
> > graphics editors one'd have to double such editor in GIMP. If one
> > won't do that then there's a danger of whole tool being not much
> > more than a toy. I'm not generally enemy of the idea, but I've got
> > my fears and doubts if it hase to be done that way.
> 
> There are, in fact, different proposal, if you read the page. Each of
> the three groups came up with a different idea. So there is not *one*
> way, but actually three ways for you to have fears and doubts about
> :)

Oh dear! ;)

> > I've got a dream about visual editing program consisting of
> > different components, each taking care of one of presentation
> > aspects with one underlaying rendering engine (target aware
> > angine—I don't like cairo's “I don't care what's on the end”
> > attitude ;)).
> 
> It's what we, utter geeks, call a framework :)

That adds +10 to "coolness" but don't let everybody know ;)

> Deneba/ACD Canvas was an attempt to create such one, but it was done
> on top of software started in mid 80s. Sometimes a whole week passes
> when I don't wake up in cold sweat seeing it in my dreams.

Funny stuff… :). But seriously, sometimes it's good for somebody to try
a thing that didn't work out last time. Because of that stubborness
we're able to fly by airplanes nowadays ;).

I consider idea of one flexible uberapp much more sensible and
appealing than implementing wee bit of “alien world” in different
apps—just seems half-solution for me.

Best!
thebodzio


signature.asc
Description: PGP signature
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP vs Photoshop

[Øyvind Kolås]

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

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

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

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

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

Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions

[Bogdan Szczurek]

> >> I could think of fully hardware accelerated rendering. Most modern
> >> hardware provides accelerated rendering and many tools could be
> >> speed up  significantly. The CPU just doesn't scale well when it
> >> comes to current  image resolutions and some brush types (smooth,
> >> smear, etc.). Also the  performance to display multiple layers or
> >> adjusting them could be much  faster.
> >
> > I think it would be more of a wish for GEGL as the GIMP's engine of
> > tomorrow ;).
> 
> "Awww, well, come on over, baby, step into my time machine." (c) GFR

buehhehehehe :D

Best!
thebodzio


signature.asc
Description: PGP signature
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP vs Photoshop

[Bogdan Szczurek]

> On 03/08/2011 07:50 PM, Bogdan Szczurek wrote:
> >> On Tue, Mar 8, 2011 at 3:12 PM, Bogdan
> >> Szczurek wrote:
> >>> I also have high hopes for GEGL, but I'd rather have it use some
> >>> more abstract color model for that. I know it's not so
> >>> simple—maybe even undoable–that way, but I do like the idea of
> >>> color model that has complete coverage of visible spectrum.
> >>
> >> Using a color model with full coverage of the visual spectrum
> >> would be an extension along the lines of RGB and the responses of
> >> the human visual system/physics, entirely additive.
> >
> > Not entirely along the lines I'm afraid. First of all it strongly
> > depends which RGB we're talking about. Even if we take scRGB into
> > account there's still some considerable parts of visible spectrum
> > that can not be described by scRGB's triad. I know scRGB is
> > tempting for it's quite broad and seems easy to implement in RGB
> > dominated world, but I've got a premonition that using device
> > agnostic color space would pay off more. But again–I don't know
> > that :).
> 
> 
> If all you want is a color space that can encode all visible colors, 
> i.e. the entire CIEXYZ color space, RGB is fine. Transforming from 
> CIEXYZ to RGB (and vice versa) is a simple matrix multiplication,
> where the matrix depends on the primaries and white point chosen.
> It's just that sometimes the RGB components will be negative and
> sometimes greater than 1.0, but each color that can be perceived by a
> human can be encoded in such a boundless RGB color space.

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

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

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

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

My best!
thebodzio


signature.asc
Description: PGP signature
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP vs Photoshop

[Tobias Oelgarte]

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

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

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

Am 08.03.2011 20:29, schrieb Michael Grosberg:
> Øyvind Kolås  gimp.org>  writes:
>
>> On Tue, Mar 8, 2011 at 11:28 AM, Michael Grosberg
>>   gmail.com>  wrote:
>>> Olivier  gmail.com>  writes:
 2011/3/8 Michael Grosberg  gmail.com>
>> These concepts do transfer to GIMP, and if one is generally empowering
>> students with the ability to do manipulation on images.. teaching them
>> how to do it with GIMP gives them both a skill and an option of a tool
>> they can use without a fee; as well as have the freedom to improve in
>> the other ways free software does. Pointing out that some things work
>> better in Photoshop doesn't seem constructive in this discussion.
> You are forgetting what the discussion is about, I think :-)
> The original poster asked, among other things, for examples of GIMP being used
> for photo-retouching in the real world. I replied that perhaps it was better
> to look for places that use GIMP for video game art creation, and mentioned
> some reasons why GIMP isn't, to the best of my knowledge, used by photo
> retouching professionals. I did not intend to discourage the teaching of GIMP,
> only to point the OP in a direction where they are more likely to find a real
> professional who uses GIMP. It is, as you said, completely possible to teach
> the basic skills using GIMP. But "photo retouching" isn't the only thing GIMP
> can do, and I don't see why the need to focus on it. What about web graphics?
> digital painting? Texture art? I'm sure the artists who worked on Sintel would
> amaze the students with their Gimping skills.
>
> ___
> Gimp-developer mailing list
> Gimp-developer@lists.XCF.Berkeley.EDU
> https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

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

Re: [Gimp-developer] GIMP vs Photoshop

[Alexandre Prokoudine]

On 3/8/11, Michael Grosberg wrote:

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



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

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



Alexandre Prokoudine
http://libregraphicsworld.org
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions

[Tobias Oelgarte]

I really miss some basic vector functionality in Gimp. In my last works 
i used Inkscape and Gimp together. Drawing sharp outlines in Inkscape, 
exporting them to PNG and imported them into Gimp again, to work with 
brushes and colors. Basically i used Inkscape to create Alpha-Layers for 
accurate strokes. The exporting and importing was some kind of pain. 
Just the ability to create basic shapes (Bezier contours), would be a 
great improvement. It doesn't need to provide anything. But it should be 
as simple as the Polygon-Tool and the Node-Tool from Inkscape. That 
would basically all i would need. Opening Inkscape, drawing a simple 
Shape (outline), exporting it, importing it and then fill it in Gimp is 
not a comfortable way.


Am 08.03.2011 20:23, schrieb Bogdan Szczurek:

On 2/13/11, LightningIsMyName wrote:


I'm starting this thread to list ideas for Google Summer of Code
2011, for the GIMP project. Since in the last year collecting ideas
was done partially by the mailing list, let's try it again this
year and keep most ideas here.

In 2009 and 2010 guiguru did GIMP related usability workshops that
haven't resulted in a spec yet (the 2008 one has), but some useful
material presumably is available:

- vector layers and drawing geometric primitives [1]

I'm not convinced of the notion of vector layers. Sure they can be nice
addition but I fear they'll end up being quite frustrating. I think so
because to make them as ellastic and usable as in vector graphics
editors one'd have to double such editor in GIMP. If one won't do that
then there's a danger of whole tool being not much more than a toy. I'm
not generally enemy of the idea, but I've got my fears and doubts if it
hase to be done that way.

I've got a dream about visual editing program consisting of different
components, each taking care of one of presentation aspects with one
underlaying rendering engine (target aware angine—I don't like cairo's
“I don't care what's on the end” attitude ;)). Such program would load
dynamically a set of editing tools if needed and only the needed. So if
one's editing vector there'll be full blown toolset for that–no
compromises, no implementation doubling. If one's to typeset a book,
there would be loaded typesetting engine loaded with all controls
available and so on. But I digress :).


- unification of selection tools (no reports from it, IIRC)

[1] http://blog.mmiworks.net/2009_07_01_archive.html

Could those be GSoC projects as well? At least unification of
selection tools could become a project to povide infrastructure for
gegl based selection tools (or am I missing an existing one?).

I think that could do some good :).


Another idea was, IIRC, an on-canvas iWarp implementation on top of
improved gegl op implemented last GSoC for cage transform so that it
worked out of cage.

I like that :).

Best regards!
thebodzio


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


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

Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions

[Alexandre Prokoudine]

On 3/8/11, Bogdan Szczurek wrote:

>> - vector layers and drawing geometric primitives [1]
>
> I'm not convinced of the notion of vector layers. Sure they can be nice
> addition but I fear they'll end up being quite frustrating. I think so
> because to make them as ellastic and usable as in vector graphics
> editors one'd have to double such editor in GIMP. If one won't do that
> then there's a danger of whole tool being not much more than a toy. I'm
> not generally enemy of the idea, but I've got my fears and doubts if it
> hase to be done that way.

There are, in fact, different proposal, if you read the page. Each of
the three groups came up with a different idea. So there is not *one*
way, but actually three ways for you to have fears and doubts about
:)

> I've got a dream about visual editing program consisting of different
> components, each taking care of one of presentation aspects with one
> underlaying rendering engine (target aware angine—I don't like cairo's
> “I don't care what's on the end” attitude ;)).

It's what we, utter geeks, call a framework :)

Deneba/ACD Canvas was an attempt to create such one, but it was done
on top of software started in mid 80s. Sometimes a whole week passes
when I don't wake up in cold sweat seeing it in my dreams.

Alexandre Prokoudine
http://libregraphicsworld.org
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP vs Photoshop

[Michael Grosberg]

Øyvind Kolås  gimp.org> writes:

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

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

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

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

Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions

[Alexandre Prokoudine]

On 3/8/11, Bogdan Szczurek wrote:

>> I could think of fully hardware accelerated rendering. Most modern
>> hardware provides accelerated rendering and many tools could be speed
>> up  significantly. The CPU just doesn't scale well when it comes to
>> current  image resolutions and some brush types (smooth, smear,
>> etc.). Also the  performance to display multiple layers or adjusting
>> them could be much  faster.
>
> I think it would be more of a wish for GEGL as the GIMP's engine of
> tomorrow ;).

"Awww, well, come on over, baby, step into my time machine." (c) GFR

http://git.gnome.org/browse/gegl/log/?h=gsoc2009-gpu

Alexandre Prokoudine
http://libregraphicsworld.org
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions

[Bogdan Szczurek]

> On 2/13/11, LightningIsMyName wrote:
> 
> > I'm starting this thread to list ideas for Google Summer of Code
> > 2011, for the GIMP project. Since in the last year collecting ideas
> > was done partially by the mailing list, let's try it again this
> > year and keep most ideas here.
> 
> In 2009 and 2010 guiguru did GIMP related usability workshops that
> haven't resulted in a spec yet (the 2008 one has), but some useful
> material presumably is available:
> 
> - vector layers and drawing geometric primitives [1]

I'm not convinced of the notion of vector layers. Sure they can be nice
addition but I fear they'll end up being quite frustrating. I think so
because to make them as ellastic and usable as in vector graphics
editors one'd have to double such editor in GIMP. If one won't do that
then there's a danger of whole tool being not much more than a toy. I'm
not generally enemy of the idea, but I've got my fears and doubts if it
hase to be done that way.

I've got a dream about visual editing program consisting of different
components, each taking care of one of presentation aspects with one
underlaying rendering engine (target aware angine—I don't like cairo's
“I don't care what's on the end” attitude ;)). Such program would load
dynamically a set of editing tools if needed and only the needed. So if
one's editing vector there'll be full blown toolset for that–no
compromises, no implementation doubling. If one's to typeset a book,
there would be loaded typesetting engine loaded with all controls
available and so on. But I digress :).

> - unification of selection tools (no reports from it, IIRC)
> 
> [1] http://blog.mmiworks.net/2009_07_01_archive.html
> 
> Could those be GSoC projects as well? At least unification of
> selection tools could become a project to povide infrastructure for
> gegl based selection tools (or am I missing an existing one?).

I think that could do some good :).

> Another idea was, IIRC, an on-canvas iWarp implementation on top of
> improved gegl op implemented last GSoC for cage transform so that it
> worked out of cage.

I like that :).

Best regards!
thebodzio


signature.asc
Description: PGP signature
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP vs Photoshop

[Martin Nordholts]

On 03/08/2011 07:50 PM, Bogdan Szczurek wrote:
>> On Tue, Mar 8, 2011 at 3:12 PM, Bogdan Szczurek
>> wrote:
>>> I also have high hopes for GEGL, but I'd rather have it use some
>>> more abstract color model for that. I know it's not so simple—maybe
>>> even undoable–that way, but I do like the idea of color model that
>>> has complete coverage of visible spectrum.
>>
>> Using a color model with full coverage of the visual spectrum would be
>> an extension along the lines of RGB and the responses of the human
>> visual system/physics, entirely additive.
>
> Not entirely along the lines I'm afraid. First of all it strongly
> depends which RGB we're talking about. Even if we take scRGB into
> account there's still some considerable parts of visible spectrum that
> can not be described by scRGB's triad. I know scRGB is tempting for
> it's quite broad and seems easy to implement in RGB dominated world,
> but I've got a premonition that using device agnostic color space would
> pay off more. But again–I don't know that :).


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

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

  / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions

[Bogdan Szczurek]

> I could think of fully hardware accelerated rendering. Most modern
> hardware provides accelerated rendering and many tools could be speed
> up  significantly. The CPU just doesn't scale well when it comes to
> current  image resolutions and some brush types (smooth, smear,
> etc.). Also the  performance to display multiple layers or adjusting
> them could be much  faster.

I think it would be more of a wish for GEGL as the GIMP's engine of
tomorrow ;).

My best!
thebodzio


signature.asc
Description: PGP signature
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP vs Photoshop

[Bogdan Szczurek]

> On Tue, Mar 8, 2011 at 3:12 PM, Bogdan Szczurek 
> wrote:
> >> Considering the use cases where fine grained control over the
> >> resulting offset plates/actual ink used for C,M,Y,K to be a subset
> >> of the more general cases where individual ink control is desired
> >> (spot-colors (including metallic, glossy and other overprints) as
> >> well as duo tone and more).
> > I also have high hopes for GEGL, but I'd rather have it use some
> > more abstract color model for that. I know it's not so simple—maybe
> > even undoable–that way, but I do like the idea of color model that
> > has complete coverage of visible spectrum.
> 
> Using a color model with full coverage of the visual spectrum would be
> an extension along the lines of RGB and the responses of the human
> visual system/physics, entirely additive.

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

> Spectral processing is not
> similar to subtractive models like CMYK

I can't agree more.

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

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

> >> with almost enforced
> >> strict working spaces for the algorithms to ensure predictability.
> >> The ability to do separation to CMYK, spot colors and more with
> >> associated processing on such will most easily be done as
> >> abstractions implemented using a planar approach where each ink is
> >> represented by a graylevel buffer.
> >
> > True enough, but we mustn't forget about target material
> > characteristics when considering print (and soft proofing), paint
> > printing order and their attributes (opacity among them too).
> 
> All of these, like the simulation of glossiness or reflectiveness of
> metallic inks are things for the final separation/composite/simulation
> though - which very well can take into account both substrate and
> perhaps even an animated illuminant ;)

Tempting… tempting… :)

> Such soft-proofing would not
> be a space that GEGL itself would be doing processing in however, even
> though it might have op(s) to take the individual grey level buffers
> to create an RGB simulation to be shown on a display,. taking into
> account the RGB profile.
> 
> Allowing the user to configure a largeish set of predefinable inks for
> separation and simulation/softproofing would possibly allow some very
> nice workflows in GIMP and other softwares using GEGL.

Yup! That's what I hope for too.

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

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

Best regards!
thebodzio


signature.asc
Description: PGP signature
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions

[Tobias Oelgarte]

I could think of fully hardware accelerated rendering. Most modern  hardware 
provides accelerated rendering and many tools could be speed up  significantly. 
The CPU just doesn't scale well when it comes to current  image resolutions and 
some brush types (smooth, smear, etc.). Also the  performance to display 
multiple layers or adjusting them could be much  faster.

Just remembering my last work (a drawing), that i barely could finish, since it 
got  very slow over time.

Am 08.03.2011 19:21, schrieb Alexandre Prokoudine:
> On 2/13/11, LightningIsMyName wrote:
>
>> I'm starting this thread to list ideas for Google Summer of Code 2011,
>> for the GIMP project. Since in the last year collecting ideas was done
>> partially by the mailing list, let's try it again this year and keep
>> most ideas here.
> In 2009 and 2010 guiguru did GIMP related usability workshops that
> haven't resulted in a spec yet (the 2008 one has), but some useful
> material presumably is available:
>
> - vector layers and drawing geometric primitives [1]
> - unification of selection tools (no reports from it, IIRC)
>
> [1] http://blog.mmiworks.net/2009_07_01_archive.html
>
> Could those be GSoC projects as well? At least unification of
> selection tools could become a project to povide infrastructure for
> gegl based selection tools (or am I missing an existing one?).
>
> Another idea was, IIRC, an on-canvas iWarp implementation on top of
> improved gegl op implemented last GSoC for cage transform so that it
> worked out of cage.
>
> Alexandre Prokoudine
> http://libregraphicsworld.org
> ___
> Gimp-developer mailing list
> Gimp-developer@lists.XCF.Berkeley.EDU
> https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
>
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions

[Alexandre Prokoudine]

On 2/13/11, LightningIsMyName wrote:

> I'm starting this thread to list ideas for Google Summer of Code 2011,
> for the GIMP project. Since in the last year collecting ideas was done
> partially by the mailing list, let's try it again this year and keep
> most ideas here.

In 2009 and 2010 guiguru did GIMP related usability workshops that
haven't resulted in a spec yet (the 2008 one has), but some useful
material presumably is available:

- vector layers and drawing geometric primitives [1]
- unification of selection tools (no reports from it, IIRC)

[1] http://blog.mmiworks.net/2009_07_01_archive.html

Could those be GSoC projects as well? At least unification of
selection tools could become a project to povide infrastructure for
gegl based selection tools (or am I missing an existing one?).

Another idea was, IIRC, an on-canvas iWarp implementation on top of
improved gegl op implemented last GSoC for cage transform so that it
worked out of cage.

Alexandre Prokoudine
http://libregraphicsworld.org
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP vs Photoshop

[Øyvind Kolås]

On Tue, Mar 8, 2011 at 11:28 AM, Michael Grosberg
 wrote:
> Olivier  gmail.com> writes:
>> 2011/3/8 Michael Grosberg  gmail.com>
>> Could you explain why retouching photos should be made in CMYK rather than 
>> RGB?
>
> Photo retouching is usually done by print magazines. It stands to reason that
> they would use tools that are able to work with CMYK.

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

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

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

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

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

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

Re: [Gimp-developer] GIMP vs Photoshop

[Øyvind Kolås]

On Tue, Mar 8, 2011 at 3:12 PM, Bogdan Szczurek  wrote:
>> Considering the use cases where fine grained control over the
>> resulting offset plates/actual ink used for C,M,Y,K to be a subset of
>> the more general cases where individual ink control is desired
>> (spot-colors (including metallic, glossy and other overprints) as well
>> as duo tone and more).
> I also have high hopes for GEGL, but I'd rather have it use some more
> abstract color model for that. I know it's not so simple—maybe even
> undoable–that way, but I do like the idea of color model that has
> complete coverage of visible spectrum.

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

>> with almost enforced
>> strict working spaces for the algorithms to ensure predictability. The
>> ability to do separation to CMYK, spot colors and more with associated
>> processing on such will most easily be done as abstractions
>> implemented using a planar approach where each ink is represented by a
>> graylevel buffer.
>
> True enough, but we mustn't forget about target material
> characteristics when considering print (and soft proofing), paint
> printing order and their attributes (opacity among them too).

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

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

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

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

Re: [Gimp-developer] GIMP vs Photoshop

[Bogdan Szczurek]

On Tue, Mar 8, 2011 at 3:34 PM, Øyvind Kolås  wrote:
> On Tue, Mar 8, 2011 at 1:33 PM, Bogdan Szczurek  wrote:
>> have nice black background. Most of the times CMS will try to simulate
>> that with all colors while it's better to use e.g. just full black and
>> cyan. Another example: you need to do some trapping. Sometimes it can
>> be done in RIP but you need to trust that to RIP itself and print
>> house. These are only a couple of arguments, leaving aside quite
>> similar cases of printing with paints different than C, M, Y and K.
>
> There are use cases where direct control over the separated result to
> CMYK is desired, this is however the corner cases and not the generic
> sense,

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

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

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

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

I don't see it different.

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

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

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

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

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

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

Best regards!
thebodzio
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP vs Photoshop

[Bogdan Szczurek]

On Tue, Mar 8, 2011 at 3:23 PM, Alexandre Prokoudine
 wrote:
> On 3/8/11, Bogdan Szczurek wrote:
>
>>> Since we got carried away from the topic anyway, I keep hearing users
>>> complaining about various bits of GIMP still not color managed, most
>>> notoriously -- filter preview and sample points. The latter is sort of
>>> critical to those who uses separate+ and/or CMYKTool after editing
>>> things in GIMP. That makes one wonder if it will be addressed in 2.8
>>> or later.
>>
>> I think that we could touch here a broader problem of system wide
>> color management. I think leaving color management to every single
>> graphics editor separately is a no-no.
>
> Oh, but you don't have to do it :) GNOME Color Manager already
> provides D-Bus methods to request stuff like working color space
> profile. Any D-Bus enabled app (and GIMP is one) can do that. For 2.8,
> however, simply fixing what's already there would be enough.

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

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

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

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

Best regards!
thebodzio
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP vs Photoshop

[Øyvind Kolås]

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

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

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

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

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

Re: [Gimp-developer] GIMP vs Photoshop

[Alexandre Prokoudine]

On 3/8/11, Bogdan Szczurek wrote:

>> Since we got carried away from the topic anyway, I keep hearing users
>> complaining about various bits of GIMP still not color managed, most
>> notoriously -- filter preview and sample points. The latter is sort of
>> critical to those who uses separate+ and/or CMYKTool after editing
>> things in GIMP. That makes one wonder if it will be addressed in 2.8
>> or later.
>
> I think that we could touch here a broader problem of system wide
> color management. I think leaving color management to every single
> graphics editor separately is a no-no.

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

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

Alexandre Prokoudine
http://libregraphicsworld.org
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP vs Photoshop

[Bogdan Szczurek]

On Tue, Mar 8, 2011 at 2:30 PM, Alexandre Prokoudine
 wrote:
> On 3/8/11, Bogdan Szczurek wrote:
>
>>> When you define a color
>>> using the color chooser, I suppose you work in HSV, not RGB?
>>
>> In fact, most of the time I use CMYK color chooser.
>
> Since we got carried away from the topic anyway, I keep hearing users
> complaining about various bits of GIMP still not color managed, most
> notoriously -- filter preview and sample points. The latter is sort of
> critical to those who uses separate+ and/or CMYKTool after editing
> things in GIMP. That makes one wonder if it will be addressed in 2.8
> or later.

I think that we could touch here a broader problem of system wide
color management. I think leaving color management to every single
graphics editor separately is a no-no. It just makes keeping color
managed workflow somewhat a nightmare.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP vs Photoshop

[Bogdan Szczurek]

On Tue, Mar 8, 2011 at 12:28 PM, Michael Grosberg
 wrote:
> Olivier  gmail.com> writes:
>
>>
>>
>> 2011/3/8 Michael Grosberg  gmail.com>
>>
>> Debi Rapson  mansd.org> writes:
>> > Can you point me in the direction of a list of places that actually use
>> > GIMP for photo retouching and graphics creation.
>> Hmm. GIMP is not well suited for professional photo retouching - it lack the
>> necessary CMYK color model (among other things). I'm not sure what the focus
>> of your program is but if you're looking for real-world use I would look more
>> into video game art creation or online content.
>>
>>
>> Could you explain why retouching photos should be made in CMYK rather than 
>> RGB?
>
> Photo retouching is usually done by print magazines. It stands to reason that
> they would use tools that are able to work with CMYK.

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

Best regards!
thebodzio
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP vs Photoshop

[Alexandre Prokoudine]

On 3/8/11, Bogdan Szczurek wrote:

>> When you define a color
>> using the color chooser, I suppose you work in HSV, not RGB?
>
> In fact, most of the time I use CMYK color chooser.

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

Alexandre Prokoudine
http://libregraphicsworld.org
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP vs Photoshop

[Bogdan Szczurek]

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

True, it doesn't.

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

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

> RGB is the internal representation of the images.

That's untrue.

> It's also a color model,

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

> not especially suitable for manipulating colors.

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

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

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

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

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

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

Best regards!
thebodzio
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP vs Photoshop

[Michael Grosberg]

Olivier  gmail.com> writes:

> 
> 
> 2011/3/8 Michael Grosberg  gmail.com>
> 
> Debi Rapson  mansd.org> writes:
> > Can you point me in the direction of a list of places that actually use
> > GIMP for photo retouching and graphics creation.
> Hmm. GIMP is not well suited for professional photo retouching - it lack the
> necessary CMYK color model (among other things). I'm not sure what the focus
> of your program is but if you're looking for real-world use I would look more
> into video game art creation or online content.
> 
> 
> Could you explain why retouching photos should be made in CMYK rather than 
> RGB?

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

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






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

Re: [Gimp-developer] GIMP vs Photoshop

[Olivier]

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

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

2011/3/8 Bogdan Szczurek 

> or better yet: Lab? ;]
>
> Anyway CMYK is neccessary too...
>
> W dniu 2011-03-08 10:08 użytkownik "Ofnuts"  napisał:
>
> On 03/08/2011 08:46 AM, Olivier wrote:
> >
> > 2011/3/8 Michael Grosberg 
>  >>...
> Could you explain why retouching photos should be made in RGB rather than
> HSV/HSL :)
>
> ___
> Gimp-developer mailing list
> Gimp-developer@lists.XCF.Berkeley.EDU
> https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
>
>
> ___
> Gimp-developer mailing list
> Gimp-developer@lists.XCF.Berkeley.EDU
> https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
>
>


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

Re: [Gimp-developer] GIMP vs Photoshop

[Bogdan Szczurek]

or better yet: Lab? ;]

Anyway CMYK is neccessary too...

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

On 03/08/2011 08:46 AM, Olivier wrote:
>
> 2011/3/8 Michael Grosberg 
>>...
Could you explain why retouching photos should be made in RGB rather than
HSV/HSL :)

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

Re: [Gimp-developer] GIMP vs Photoshop

[Ofnuts]

On 03/08/2011 08:46 AM, Olivier wrote:
2011/3/8 Michael Grosberg >


Debi Rapson  mansd.org > writes:

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

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


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





Could you explain why retouching photos should be made in RGB rather 
than HSV/HSL :)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer