date:20110308

or better yet: Lab? ;]

Anyway CMYK is neccessary too...

W dniu 2011-03-08 10:08 użytkownik Ofnuts ofn...@laposte.net napisał:

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

 2011/3/8 Michael Grosberg grosberg.mich...@gmail.com
...
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

2011-03-08 Thread 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 thebod...@gmail.com

 or better yet: Lab? ;]

 Anyway CMYK is neccessary too...

 W dniu 2011-03-08 10:08 użytkownik Ofnuts ofn...@laposte.net napisał:

 On 03/08/2011 08:46 AM, Olivier wrote:
 
  2011/3/8 Michael Grosberg grosberg.mich...@gmail.com
  ...
 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

2011-03-08 Thread Michael Grosberg

Olivier olecarme at gmail.com writes:

 
 
 2011/3/8 Michael Grosberg grosberg.michael at gmail.com
 
 Debi Rapson drapson at 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

 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

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

On Tue, Mar 8, 2011 at 12:28 PM, Michael Grosberg
grosberg.mich...@gmail.com wrote:
 Olivier olecarme at gmail.com writes:



 2011/3/8 Michael Grosberg grosberg.michael at gmail.com

 Debi Rapson drapson at 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

On Tue, Mar 8, 2011 at 2:30 PM, Alexandre Prokoudine
alexandre.prokoud...@gmail.com 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

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

On Tue, Mar 8, 2011 at 1:33 PM, Bogdan Szczurek thebod...@gmail.com 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

On Tue, Mar 8, 2011 at 3:23 PM, Alexandre Prokoudine
alexandre.prokoud...@gmail.com 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

On Tue, Mar 8, 2011 at 3:34 PM, Øyvind Kolås pip...@gimp.org wrote:
 On Tue, Mar 8, 2011 at 1:33 PM, Bogdan Szczurek thebod...@gmail.com 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

On Tue, Mar 8, 2011 at 3:12 PM, Bogdan Szczurek thebod...@gmail.com 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

On Tue, Mar 8, 2011 at 11:28 AM, Michael Grosberg
grosberg.mich...@gmail.com wrote:
Olivier olecarme at gmail.com writes:
2011/3/8 Michael Grosberg grosberg.michael at 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.

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

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] Google Summer of Code 2011 - Project Ideas/Suggestions

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] GIMP vs Photoshop

 On Tue, Mar 8, 2011 at 3:12 PM, Bogdan Szczurek thebod...@gmail.com
 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

 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

2011-03-08 Thread Martin Nordholts

On 03/08/2011 07:50 PM, Bogdan Szczurek wrote:
 On Tue, Mar 8, 2011 at 3:12 PM, Bogdan Szczurekthebod...@gmail.com
 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

 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] Google Summer of Code 2011 - Project Ideas/Suggestions

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] GIMP vs Photoshop

2011-03-08 Thread Michael Grosberg

Øyvind Kolås pippin at gimp.org writes:

 
 On Tue, Mar 8, 2011 at 11:28 AM, Michael Grosberg
 grosberg.michael at gmail.com wrote:
  Olivier olecarme at gmail.com writes:
  2011/3/8 Michael Grosberg grosberg.michael at 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

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] GIMP vs Photoshop

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.

plug mode=shameless

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

/plug

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

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åspippinat  gimp.org  writes:

 On Tue, Mar 8, 2011 at 11:28 AM, Michael Grosberg
 grosberg.michaelat  gmail.com  wrote:
 Olivierolecarmeat  gmail.com  writes:
 2011/3/8 Michael Grosberggrosberg.michaelat  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

 On 03/08/2011 07:50 PM, Bogdan Szczurek wrote:
  On Tue, Mar 8, 2011 at 3:12 PM, Bogdan
  Szczurekthebod...@gmail.com 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] Google Summer of Code 2011 - Project Ideas/Suggestions

  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

On Tue, Mar 8, 2011 at 7:47 PM, Bogdan Szczurek thebod...@gmail.com 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

  - 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] Google Summer of Code 2011 - Project Ideas/Suggestions

 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

On Tue, Mar 8, 2011 at 8:00 PM, Bogdan Szczurek thebod...@gmail.com 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] GIMP vs Photoshop

  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

 On Tue, Mar 8, 2011 at 8:00 PM, Bogdan Szczurek thebod...@gmail.com
 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] Google Summer of Code 2011 - Project Ideas/Suggestions