-- cut --
The agrreded idea among GIMP developers is that CMYK as an _image
editing mode_ will not be implemented in GIMP. Where as there maybe
in the future more straightforward ways foreasier CMYK separation and
printing.
That is due to the fact that CMYK is more the mapping to inks of
On Mon, May 23, 2011 at 11:05 AM, Bogdan Szczurek
thebod...@gmail.com wrote:
One final thougt: CMYK support subject was touched more than once
on this list, but I think we should consider much broader view on
the matters of printing. CMYK is only most often used set of
colorants
W dniu 11-04-01 23:55, Marek Rogalski pisze:
Hello, everybody.
I have a quite simple proposal for this year GSoC: make a nice editor
for GEGL pipelines.
Why do we need it: because the GEGL eats XML files. GIMP could eat
them too. It would introduce much greater reusability in the work of
On 03/12/11 00:03, Bogdan Szczurek wrote:
It seems most promising!
Best regards!
thebodzio
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
What
It seems most promising!
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
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
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,
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
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
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
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
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
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
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
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
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
- 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
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
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
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
Our school system appears to be headed for using GIMP as a way of
teaching our students about graphics.
Can you point me in the direction of where I would go to get GOOD
tutorial information about GIMP so that I can properly teach it?
Can you point me in the direction of a list of places
... elision by patrick...
How about having (hideable of course :)) on-canvas infos? IMHO that
would be even fancier. Infos could be aligned with control that
modifies them. Numerical input could be done similarly on-canvas. I
think hovering pointer above e.g. rotation control and
I'm a little uneasy at the moment about the ban working with
numbers for transformations comment.
It would be nice (IMO) to have a dockable that displays the numbers
of the transform tool's current selection and transform, and also
applies numerical input to the transform tool.
Users who have a comment on the list should raise it now. The ideas
list was divided in to two parts, as discussed on IRC.
Developers who wish to make small corrections should feel free to do
so, but please do not move projects between the lists / add/remove
projects or do any other major
And let me throw in another thing. It's been in my head for some
time but now I think it's good to show it to the world. Just in the
matter of shear curiosity: I'd like to see some conceptual
work/code/working example/whatever about automatically configurable
grid processing. It may be
I've begun working on GIMP documentation so GIMP is on my mind a lot
lately. So, I have a suggestion - remove the pencil tool, and
instead, add a checkbox to the brush tool with an antialiased
label.
I'd go even further with that: make “antialiased” one of specific brush
settings, not the
Great thing to bring this up!
cut
Implement the free transform tool
For exact specifications, see:
http://gui.gimp.org/index.php/Transformation_tool_specification
Oh yeah, thumbs up for that! :)
cut
Replace the GimpSizeEntry widget
Right now both the code and the UI is a mess. The
And hi one more time!
Couldn't we have a square (and square fuzzy) brush by default on Gimp
or it's out of the scope/vision/something else of the product?
I think that solid, one-color, vector-based brushes would be even
better to have. They would make square, round, oval and you-name-it
On 2/2/11, Bogdan Szczurek wrote:
different after all. Please don't be mad at me for saying that for I
don't intend to offend anybody.
Nobody's mad at you :)
And I said that to be sure that nobody will be :).
I see where you are coming from, I even spent
some time in the past
On 02/01/2011 06:25 PM, Alexandre Prokoudine wrote:
On Tue, Feb 1, 2011 at 8:16 PM, Michael Grosberg wrote:
I will refrain from expressing my opinion on undocumented,
undiscoverable features.
Now only a help page is needed. I think I'll go and join the
Gimp-Docs mailing list and take
As it was stated before, making applications act similar doesn't
turn out in familiarity, but in a percepction of incompleteness. The
most our applications looks like others, the most former users of
other applications will spot what's missing, perceiving differences as
limitations.
When I
On Tue, 2011-02-01 at 17:16 +, Michael Grosberg wrote:
Alexandre Prokoudine alexandre.prokoudine at gmail.com writes:
*sigh*
http://git.gnome.org/browse/gimp/tree/etc/ps-menurc
Alexandre Prokoudine
http://libregraphicsworld.org
I will refrain from expressing
On Tue, Feb 1, 2011 at 5:17 PM, Michael Grosberg
grosberg.mich...@gmail.com wrote:
Add a single For Photoshop users page to the help file. There,
tell users how to change the menurc file so they have
photoshop-like keys. This won't change the application in any way,
and will enable those
And all this conversation is because you think CTRL+Backspace makes
more sense than CTRL+. (because you're used to that combination) and
you don't want to take 30 seconds of your time to personalize the
accelerators?
Seriously?
If think so then I'm afraid that you didn't read my posts
On Jan 30, 2011, at 12:12 PM, Liam R E Quin wrote:
On Sun, 2011-01-30 at 01:43 +0100, Bogdan Szczurek wrote:
The thing is, that we concluded that permamenet transition or even
occasional use of Gimp would be much more appealing for Ps-bred
guys (like me ;)) if one would have
Furthermore, collaborating with Inkscape *instead* makes a lot of
sense, because GIMP + Inkscape are a usual combo. Blindly reusing
shortcuts from old Adobe products doesn't make a lot of sense.
Blindly—yes. But proposition is not to do it that way. My reason is: I
want to promote GIMP to e.g.
Actually, I intended this thread to be about “Photoshop «compatibility»
mode” (quotation marks to emphasize that I meant only particular kind of
compatibility :)).
I'm afraid the conversation went a bit off-topic since I didn't
suggested changes in _default_ shortcuts scheme for GIMP. What I
Hi!
Lately I've been discussing with a collegue of mine some differences
between Gimp and Photoshop and how long-time Ps user feel when seated
in front of Gimp. I know… I know… the neverending subject, but I'm not
trying to start the flame again, so… please keep your matches and petrol
away ;) —
Hi!
Lately I've been discussing with a collegue of mine some differences
between Gimp and Photoshop and how long-time Ps user feel when
seated in front of Gimp. I know… I know… the neverending subject,
but I'm not trying to start the flame again,
Do you genuinely expect us to believe
I can certainly see that showing size in megapixels can be useful for
our target user base. We're even lucky enough to have the prefect char
'M' free for it. So I have pushed a cleaned up version of your patch
(that only uses 1 decimal) to git master:
That's great news! Thanks for accepting
There's a small thing that I missed in GIMP for some time. That
thing is a megapixel counter to add to window title or status.
Hi!
IMO we need to make it easier than editing a complex format-string to
get this info in the window title.
Well… I haven't thought of that, to be frank,
41 matches
Mail list logo
