Re: [Gimp-developer] Overlay Mode - fix.
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 be able to choose proper modes from the menu. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Overlay Mode - fix.
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 ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Overlay Mode - fix.
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 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 be able to choose proper modes from the menu. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Overlay Mode - fix.
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 mi...@gimp.org 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 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 be able to choose proper modes from the menu. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Overlay Mode - fix.
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 breaks compatibility: Existing Artwork stored in XCF files will change apperance depending on the Gimp version. We can't have that. 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. That'd be the way to go forward with this issue. Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Overlay Mode - fix.
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 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. Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Overlay Mode - fix.
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 wrote: 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 breaks compatibility: Existing Artwork stored in XCF files will change apperance depending on the Gimp version. We can't have that. 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. That'd be the way to go forward with this issue. Bye, Simon ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Overlay Mode - fix.
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 and all being blended in linear light, is there any other layer mode that changes? I was thinking about the simplest way to tackle this problem, and if those are the only differences this might work: If the file was created with 2.8 or earlier, show a warning and offer opening the file anyway or using the legacy mode. If the user chooses legacy: - Promote the file to high bit depth. - open it normally (afaik this would convert the colorspace to the working space and linearize every layer) - add a gamma correction operation to all the layers applying the sRGB TRC (1D LUTs?) - blend - Linearize the composite prior the last color-management op. - Regarding the Overlay operation: Just replace it using the soft light mode instead. Correct me if I'm wrong, but in GIMP 2.8 and previous versions both modes seem to provide the same result. Probably applying gamma correction to inputs that were linearized from a gamma corrected source sounds redundant, but this is supposed to be a legacy mode, a compatibility layer, so the reduced efficiency would be probably justified. If this is possible, switching from legacy to the new native linear blending would mean just bypassing the gamma correction nodes. I'm not a coder and I don't know anything about the GIMP/GEGL internals, so I tried using the logic I'd use with a compositing software. If this is a stupid oversimplification you're entitled to make me STFU :-) Gez ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Overlay Mode - fix.
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 channel):
float srgb_to_linearrgb(float c)
{
if(c 0.04045)
return (c 0.0)? 0.0: c * (1.0/12.92);
else
return pow((c + 0.055)*(1.0/1.055), 2.4);
}
float linearrgb_to_srgb(float c)
{
if(c 0.0031308)
return (c 0.0)? 0.0: c * 12.92;
else
return 1.055 * pow(c, 1.0/2.4) - 0.055;
}
So, now we have these 2 methods which can convert from sRGB to linearRGB and
from linear RGB to sRGB.
--
For example we have 2 layers:
layer1 and layer2.
layer1.r = srgb_to_linearrgb(layer1.r); // convert srgb input to liner rgb
layer1.g = srgb_to_linearrgb(layer1.g);
layer1.b = srgb_to_linearrgb(layer1.b);
layer2.r = srgb_to_linearrgb(layer2.r);
layer2.g = srgb_to_linearrgb(layer2.g);
layer2.b = srgb_to_linearrgb(layer2.b);
output = layer1*layer2; //this is a formula example to multyply
output.r =linearrgb_to_srgb(output.r ); // convert linear output to srgb
output.g= linearrgb_to_srgb(output.g);
output.b =linearrgb_to_srgb(output.b );
--
What do you say about it?
But i think Photoshop does not convert anything to linear...
Also if you want i can ask Krita devs about this issue. They can help.
Втр 13 Ноя 2012 18:37:19 от Michael Natterer mi...@gimp.org:
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 all new files.
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 implementation) around and assign a new one to the fixed
Overlay. Then we hide the Legacy Overlay in the menu (unless it is
used).
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
This however needs to be done. Just exchanging the math in the overlay
operation won't cut it.
Bye,
Simon
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Overlay Mode - fix.
On Wed, Nov 14, 2012 at 3:29 AM, Øyvind Kolås pip...@gimp.org 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 conversion that can be cached, more correct code could be: const Babl *fish = babl_fish (babl_format (R'G'B'A u8), babl_format (RGBA float)); .. babl_process (fish, source_buffer, destination_buffer, pixel_count); -- @hodefoting ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
