@lists.XCF.Berkeley.EDU
Sent: Wed, March 16, 2011 6:10:33 AM
Subject: Re: [Gimp-developer] [Bug 325564] Use CIE LCH instead of HSL for
layer
mode Color
On 03/15/2011 08:47 PM, Charlie De wrote:
Why?? Rupert Weber finished this last September and you promised it would
be
in
2.8. Is this how
Martin,
Could you please demonstrate your sincerity by escalating the 'bug' to
critical?
It would demonstrate commitment to really having this in 2.10, rather than just
'looking at it'. I think you owe it to the developer to make that gesture at
the
very least.
Good luck with all the work
Why?? Rupert Weber finished this last September and you promised it would be in
2.8. Is this how you show respect for the most stellar effort by a new talent?
Shame, truly, shame on you. It's now been 5 years since the issue was first
reported, you're going to add another year even though the
Hello all,
I would like to make a request if I may for the keyboard shortcut, the key that
corresponds to the underlined letter, for the Don't Save button in Save/Save As
dialogs to be standardised, preferrably to the d key. At present, this is
inconsistent, in some instances the key is n.
As an end user with no expertise in what is being said in this discussion I
would like to ask three questions:
1. Why such focus on Lab, which seems to be problematic? Why can't YCbCr ITU
R470 or R709 be used? They work without issues for luminance transfer in
Decompose/Recompose. I'm sure
From Rupert:
(as far as I can tell, the current Decompose Lab functions are
broken, anyway).
What makes you say that? And how severe is the problem?
Right this minute I'm writing a script with LAB Decompose...
Charlie
___
...@leguanease.org
To: gimp-developer@lists.XCF.Berkeley.EDU
Sent: Mon, August 9, 2010 4:45:00 PM
Subject: Re: [Gimp-developer] Getting new layer modes fit for inclusion
On 08/09/2010 04:16 PM, Charlie De wrote:
From Rupert:
(as far as I can tell, the current Decompose Lab functions
From Martin:
I think the displayed names should be like above, and the API names
should have a LCH prefix or suffix. I think the old ones should have
display names with (compatibility) appended, and only be shown when an
XCF that uses these modes have been loaded. The API names should
From Martin:
I think the names needs to suggest that new files should avoid using
those layer modes.
Other alternatives:
(compat.)
(legacy)
(obsolete)
(broken)
(old)
Good point! Then (obsolete) is best. The abbreviation of compat. to be
avoided; legacy is too figurative, has
Rupert, that's wonderful news on a Sunday morning! Thank you so much for your
effort.
I'm not so good at understanding patches and things... If this is accepted,
would it mean it would be available natively, without GEGL projection?
Since LAB uses a perception-based definition of lightness,
From: Martin Nordholts ense...@gmail.com :
Since this is the second time you mention this, I feel I have to step in
and say that I think it is a really bad idea. We want to improve the
usability of GIMP, and forcing users to use a configure flag to make
GIMP work like they want is not a
From: Rupert Weber g...@leguanease.org
I wrote a patch that might help fix the situation.
Thanks so much for working on this! I'm one of the people who'd greatly
appreciate the fix. In fact, your effort is more than I dared hope for, I was
resigned to the idea that the GEGL route was
From Alexia:
What you are saying is that we should maintain a fork for you... I
doubt thats going to happen. You can easily maintain your own patch
set yourself however. Its been done before. Not a complete fork but a
patch set distributed separately.
No, certainly not just for me. The fix
#1: Add additional color spaces to the color manipulation tools
(HSV/HSL/HSY/RGB/Lab/LMS/CMYK/etc/etc), where appropriate.
If by this you mean that one could choose the colour space and the individual
channels in which the command or tool is applied, then this is an excellent
idea. It
From Alexandre:
There are many ways to make yourself useful for the project.
I'm trying to do just that.
Someone, an end user, emailed me off-list, talking about how they'd be upset
with a new rendering, talking of lost files.
Let me offer a cheap and simple solution. Release an incremental
Compile and end-user. Not all en-users compile their version of Gimp.
Bumping the version number in XCF and implementing the compatibility would
probably be better.
Of course. But I had the impression the development cost of such a solution
and
the need to keep XCF unchanged were major
From Alexandre:
If you ask users here and now what they want, you are likely to hear:
In your list of priorities people might come up with, none described broken
essential functionality. Fixing those should be highest priority.
From Tobias:
Wrong. This is open source. That implies that whoever
So go fix it in gegl. I think it was decided 4 years ago what is going to
happen to the layer mode bugs.
And my point is that wasn't such a good decision precisely because it took 4
years to get it fixed. As stated, an earlier native fix would have brought the
benefit to GEGL. It's
Just in case, not everyone in this list is a GIMP developer. There are
ways and ways to be involved in the project, so there's not much point
counting opinions just because they were expressed. We all have our
own ideas how GIMP could evolve, what bugs should be fixed first and
so on, but
Since we released stable versions with this broken behavior we now have
to maintain backward compatibility to it. It is considered very
important that you can open your old XCF files in a new version of GIMP
and get the same result as in the version you created them in.
I suggest that
which has been addressed when using GEGL.
Seth
On Mon, Jul 26, 2010 at 6:33 AM, Charlie De charlieco...@yahoo.com wrote:
Hello all,
I've joined up with this list to make an important suggestion for improvement.
In short, the Color and Value blending, transfer modes in GIMP do not work
Martin,
If you provide a patch that improves Color mode compositing when using
GEGL, I would be happy to review it.
Alas, all I can provide is the algorithm, I'm not a C or C++ coder.
We can't do this change in native GIMP because it would break rendering
of XCF files that relies
Second of all, why would it take long to regain multi-threading when
we start using GEGL for real? I expect us to make use of a
multi-threaded GEGL in the first GEGLifixed GIMP release.
Music to my ears!
Good luck with the coding, your efforts are greatly appreciated.
Charlie
Hello all,
I've joined up with this list to make an important suggestion for improvement.
In short, the Color and Value blending, transfer modes in GIMP do not work as
they should. The problem is compounded by the fact that there seems to be no
application on Linux where these transfer
24 matches
Mail list logo
