Hi again.
I talked to Krita developer "Boud" by IRC and he said many interesting
things about linear RGB.
He said that there is no need to convert to Linear RGB. Krita does not
convert anything. It only mixes layers.
So everything is simplier. You just need to implement my patch and make
"New
I confirm that "GEGL View" dispalyed correctly Overlay mode. As far as I
remember the GEGL color modes were SVG2 format.
It was mentioned here by Martin:
https://bugzilla.gnome.org/show_bug.cgi?id=162395
On 14.11.2012 04:31, Przemyslaw Golab wrote:
Hi,
I remember when using 2.7 and GEGL view
On Wed, Nov 14, 2012 at 3:29 AM, Øyvind Kolås wrote:
> babl_process (babl_format ("R'G'B'A u8"), babl_format ("RGBA float"),
> source_buffer, destination_buffer, n_pixels);
I should have looked up the header or some actual code first, the
first argument of babl_process is a babl-fish for the conv
On Tue, Nov 13, 2012 at 9:14 PM, Paul Geraskin wrote:
> I had some experience in converting sRGB to linear RGB. When I coded in
> GLSL. I have taken this code from blender GLSL shader.
> The main idea is: convert all inputs to linear RGB, then make formula
> calculation, then convert output to sRG
Ups, my e-mail browser folded responses :D
sorry for repeating what already was written ^^'
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Hi,
I remember when using 2.7 and GEGL view (?) was available for testing,
Overlay worked as expected.
Legacy Overlay looks like Soft Light, but GEGL Overlay looks like Overlay.
--
n-pigeon
___
gimp-developer-list mailing list
gimp-developer-list@gnom
I had some experience in converting sRGB to linear RGB. When I coded in GLSL. I
have taken this code from blender GLSL shader.
The main idea is: convert all inputs to linear RGB, then make formula
calculation, then convert output to sRGB.
The methods from blender GLSL shader (it works per channe
El 13/11/12 14:37, Michael Natterer escribió:
The problem is much bigger. Almost *all* of our layer modes
will be "Legacy", and the new modes will operate in linear
light. Just adding a hack for overlay is not going to
fix the root problem.
--mitch
Apart from the different overlay formula an
On Tue, 2012-11-13 at 16:27 +0100, Simon Budig wrote:
> Alexandre Prokoudine (alexandre.prokoud...@gmail.com) wrote:
> > I would suggest to detect XCF version and for files with legacy
> > blending modes rename the mode to "Legacy Overlay" and suggest
> > resaving, while using just "Overlay" for al
I would make it if i was a programmer. Actually, i'm a 3d artist. And i
know a bit Java.
I can fix the formula, but to make entire "C/C++" fix is not my skilled
level i think.
If you are a Gimp developer i think it will take 2-3 hours of your time.
Anyway i'll install kDevelop and Eclipse to
Paul Geraskin (paul_geras...@mail.ru) wrote:
> Is it possible to implement it right now? It seems your solution is
> pretty simple.
Dive into the code and give it a shot. If you need guidance around the
code feel free to ask on IRC.
Bye,
Simon
--
si...@budig.de
Is it possible to implement it right now? It seems your solution is
pretty simple.
On 13.11.2012 19:27, Simon Budig wrote:
There is no need to fiddle around with the XCF version. The layer mode
basically is an enum. We simply keep the old enum value (and the
"buggy" legacy overlay implementat
Thanks Jeff, It also opens correctly from Painter, Krita,
Ora(OpenRaster) *.psd, *.ora files.
Simon,
Can you(core devs) make xcf2.8- notification for Overlay method. And
switch old xcf to "Legacy Overlay" mode.
This will simply solve the issue with old xcf.
On 13.11.2012 19:14, Simon Budig
Alexandre Prokoudine (alexandre.prokoud...@gmail.com) wrote:
> I would suggest to detect XCF version and for files with legacy
> blending modes rename the mode to "Legacy Overlay" and suggest
> resaving, while using just "Overlay" for all new files.
There is no need to fiddle around with the XCF v
On Tue, Nov 13, 2012 at 7:14 PM, Simon Budig wrote:
> However, this does not prevent us from implementing a "proper" overlay
> mode. We just need to keep the old (arguably buggy) blending mode around
> and introduce a *new* one with the proper implementation. Then we change
> labels in the UI.
I
Jeff Maples (grapn...@gmail.com) wrote:
> I agree with Paul on the overlay mode. The patch is excellent, and it
> makes importing files from Photo$hop more consistent. I think it should be
> the default. Just my two cents.
The problem with the approach Paul took in the bug report is, that it
br
I agree with Paul on the overlay mode. The patch is excellent, and it
makes importing files from Photo$hop more consistent. I think it should be
the default. Just my two cents.
On Tue, Nov 13, 2012 at 8:25 AM, Michael Natterer wrote:
> On Tue, 2012-11-13 at 15:47 +0400, Paul Geraskin wrote:
>
On Tue, 2012-11-13 at 15:47 +0400, Paul Geraskin wrote:
> Good! I will wait for that. Interesting when do you plan to release the
> Gimp 2.10?
As usual, when it's done :)
> I hope it will be faster than 2.8. :)
The only way to speed that up is contributing :)
> On 13.11.2012 11:27, Michael Nat
On Tue, Nov 13, 2012 at 3:47 PM, Paul Geraskin wrote:
>
> Good! I will wait for that. Interesting when do you plan to release the Gimp
> 2.10? I hope it will be faster than 2.8. :)
The best way to ensure that is to contribute :)
Alexandre Prokoudine
http://libregraphicsworld.org
_
Good! I will wait for that. Interesting when do you plan to release the
Gimp 2.10? I hope it will be faster than 2.8. :)
On 13.11.2012 11:27, Michael Natterer wrote:
On Tue, 2012-11-13 at 10:43 +0400, Paul Geraskin wrote:
We are in unstable development here. When 2.10 is done, artists
will
20 matches
Mail list logo
