[Gimp-developer] non-destructive editing and adjustment layers
Thanks Liam, however does the current git master support non-destructive editing and/or adjustment layer-like functionality? ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] non-destructive editing and adjustment layers
On Sun, Sep 1, 2013 at 7:16 AM, wrote: > Thanks Liam, however does the current git master support non-destructive > editing and/or adjustment layer-like functionality? It doesn't. Alexandre ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] non-destructive editing and adjustment layers
> > Thanks Liam, however does the current git master support non-destructive > > editing and/or adjustment layer-like functionality? > > It doesn't. > On the website, it says that when gimp is "fully ported" to GEGL, then non-destructive editing will be supported. Am I correct? Then how far is the current git master from the state of full-porting to GEGL? Also, is it true that real 16/32-bit channel support is only achievable when all functions are ported to GEGL? The current git master allows you to create a new image with 32-bit gamma integer or float channel. However internally, will some legacy functions not yet ported to GEGL discards the 32-bit to the old 8-bit? Thanks! ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] non-destructive editing and adjustment layers
On Sun, Sep 1, 2013 at 8:02 AM, wrote: >> > Thanks Liam, however does the current git master support non-destructive >> > editing and/or adjustment layer-like functionality? >> >> It doesn't. >> > > On the website, it says that when gimp is "fully ported" to GEGL, then > non-destructive editing will be supported. Am I correct? You are confused :) Non-destructive editing is _possible_ after the complete port to GEGL. But the complete port to GEGL doesn't automagically enable non-destructive editing. There's more work involved. > Then how far is the current git master from the state of full-porting to GEGL? I hope you are not asking for an ETA, because we have none :) As far as I can tell, most work on rewrite of internals is done. But more plug-ins have to be ported, and, I imagine, there are still cleanups to be made here and there. > Also, is it true that real 16/32-bit channel support is only achievable > when all functions are ported to GEGL? The current git master allows you > to create a new image with 32-bit gamma integer or float channel. However > internally, will some legacy functions not yet ported to GEGL discards the > 32-bit to the old 8-bit? What kind of legacy functions would those be? Alexandre ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] non-destructive editing and adjustment layers
> > > Also, is it true that real 16/32-bit channel support is only achievable > > when all functions are ported to GEGL? The current git master allows you > > to create a new image with 32-bit gamma integer or float channel. However > > internally, will some legacy functions not yet ported to GEGL discards the > > 32-bit to the old 8-bit? > > What kind of legacy functions would those be? > So in another word: do you mean that gimp git master already has full support of 32-bit color channels, and there is nothing inside gimp that silently discards the details of the 32-bit data? If so, then we have already removed the first obstacle for migration to gimp - 8-bit channel :) > > > Then how far is the current git master from the state of full-porting to > > GEGL? > > I hope you are not asking for an ETA, because we have none :) > > As far as I can tell, most work on rewrite of internals is done. But > more plug-ins have to be ported, and, I imagine, there are still > cleanups to be made here and there. So do you mean that the GIMP internal is already running on GEGL, but there are some plugins that have not been migrated to GEGL yet? If so, where can one find the list of plugins that have not yet migrated to GEGL? And what kind of work is required for the adjustment layer function? Does it really need to wait for the complete migration of every plugin to GEGL? And is there already a branch in git for WIP of the adjustment layer? If so, I am keen to have a look :) ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] non-destructive editing and adjustment layers
On Sun, Sep 1, 2013 at 10:54 AM, wrote: > So in another word: do you mean that gimp git master already has full > support of 32-bit color channels, and there is nothing inside gimp > that silently discards the details of the 32-bit data? Some plugins do. > So do you mean that the GIMP internal is already running on GEGL, but > there are some plugins that have not been migrated to GEGL yet? Yes. > If so, where can one find the list of plugins that have not yet migrated > to GEGL? http://wiki.gimp.org/index.php/Hacking:Porting_filters_to_GEGL > And what kind of work is required for the adjustment layer function? Designing a new file format would be a good start. So would designing user interaction be. > Does it really need to wait for the complete migration of every plugin > to GEGL? Given the existing amount of active developers, yes. > And is there already a branch in git for WIP of the > adjustment layer? No. Alexandre ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] non-destructive editing and adjustment layers
> >> So in another word: do you mean that gimp git master already has full >> support of 32-bit color channels, and there is nothing inside gimp >> that silently discards the details of the 32-bit data? > > Some plugins do. > Oops.. then this can be dangerous... you think your data is in 32-bit, but actually it is silently down-cast to 8 bits. Is there a list of such plugins? And do these plugins output a warning message telling users that precision will be lost due to down-casting? ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] non-destructive editing and adjustment layers
On Sun, Sep 1, 2013 at 11:06 AM, wrote: >> >>> So in another word: do you mean that gimp git master already has full >>> support of 32-bit color channels, and there is nothing inside gimp >>> that silently discards the details of the 32-bit data? >> >> Some plugins do. >> > > Oops.. then this can be dangerous... you think your data is in > 32-bit, but actually it is silently down-cast to 8 bits. Dangerous to whom? Git master is barely ever recommended for daily use. > Is there a list of such plugins? I already gave it to you :) Alexandre ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] non-destructive editing and adjustment layers
So in another word: do you mean that gimp git master already has full support of 32-bit color channels, and there is nothing inside gimp that silently discards the details of the 32-bit data? >>> >>> Some plugins do. >>> >> >> Oops.. then this can be dangerous... you think your data is in >> 32-bit, but actually it is silently down-cast to 8 bits. > > Dangerous to whom? Git master is barely ever recommended for daily use. > I mean that whenever a plugin is used on an image with the channel size larger than the plugin can support, gimp should output a warning message about loss of precision. So I guess would adding a simple check like this involve much much less work than the porting of a plugin to GEGL? Although I haven't got to read the code myself, I guess all we need to do is to add a member in the plugin base class showing the type of element it supports (8-bit int, 16-bit int, 32-bit int etc) and let the constructor of each plugin (both GEGL and non-GEGL) set it to the correct value... ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] non-destructive editing and adjustment layers
On 1 September 2013 05:56, wrote: > > I mean that whenever a plugin is used on an image with the channel > size larger than the plugin can support, gimp should output a warning > message about loss of precision. So I guess would adding a simple > check like this involve much much less work than the porting of a > plugin to GEGL? GEGLIfied Plug-ins have an ostensive "G" icon next to their menu entries- if you are taking care not ot use legacy plug-in it is easy not to pick tehn by mistake. Also, GEGLfied plug-ins make their preview staright on Canvas, just like GIMP's itnernal tools - if you open a plug-in dialog with a built-in preview - or simply no preview on canvas, there is time to cancel. Other than that, there is no automated warning; js -><- ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] non-destructive editing and adjustment layers
On Sun, Sep 1, 2013 at 12:56 PM, wrote: > So in another word: do you mean that gimp git master already has full > support of 32-bit color channels, and there is nothing inside gimp > that silently discards the details of the 32-bit data? Some plugins do. >>> >>> Oops.. then this can be dangerous... you think your data is in >>> 32-bit, but actually it is silently down-cast to 8 bits. >> >> Dangerous to whom? Git master is barely ever recommended for daily use. >> > > I mean that whenever a plugin is used on an image with the channel > size larger than the plugin can support, gimp should output a warning > message about loss of precision. So I guess would adding a simple > check like this involve much much less work than the porting of a > plugin to GEGL? I don't understand why you are pushing this. What's so great about not porting plugins to GEGL and adding checks instead? Besides, file loaders already warn about the clipping of data, and, as Joao pointed out, GEGL-based plugins already work differently. Alexandre ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] non-destructive editing and adjustment layers
Okay. so do you mean that any non-GEGL plugins or filters should be treated as not 32-bit compatible and is therefore capable of silently clipping data? ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] non-destructive editing and adjustment layers
On Mon, Sep 2, 2013 at 12:22 AM, wrote: > Okay. so do you mean that any non-GEGL plugins or filters should > be treated as not 32-bit compatible and is therefore capable of > silently clipping data? By the time GIMP 2.10 is out, there will be no such plugins in GIMP, so what you are suggesting simply doesn't make much sense :) Alexandre ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] non-destructive editing and adjustment layers
El 01/09/13 17:22, kcle...@users.sourceforge.net escribió: Okay. so do you mean that any non-GEGL plugins or filters should be treated as not 32-bit compatible and is therefore capable of silently clipping data? What Alexandre is saying is that you won't have to worry about it when 2.10 is out, because that version won't be released until the rest of the legacy stuff is ported to GEGL. Due to the lack of manpower, using developers time to address something that is only relevant during development is a waste of time and efforts. If you're using 2.9 you should know that you are using a development version and things aren't ready yet. You asked and your answers were replied. You have a list of plugins that aren't ported to GEGL yet, you know the effect, you know how to tell if they are/aren't ported and you know that the legacy plugins won't stay like that whenever GIMP 2.10 is released. Do you still think developers should use their time to code warnings about it? Gez P.s.: This thread has been quite informative though. Anyone new to this development version will have a nice summary in the mailing list archives. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] non-destructive editing and adjustment layers
On Mon, Sep 2, 2013 at 10:44 AM, Guillermo Espertino (Gez) wrote: > El 01/09/13 17:22, kcle...@users.sourceforge.net escribió: > >> Okay. so do you mean that any non-GEGL plugins or filters should >> be treated as not 32-bit compatible and is therefore capable of >> silently clipping data? > > > What Alexandre is saying is that you won't have to worry about it when 2.10 > is out, because that version won't be released until the rest of the legacy > stuff is ported to GEGL. > Due to the lack of manpower, using developers time to address something that > is only relevant during development is a waste of time and efforts. > If you're using 2.9 you should know that you are using a development version > and things aren't ready yet. > You asked and your answers were replied. You have a list of plugins that > aren't ported to GEGL yet, you know the effect, you know how to tell if they > are/aren't ported and you know that the legacy plugins won't stay like that > whenever GIMP 2.10 is released. > Do you still think developers should use their time to code warnings about > it? > Thanks for the clarification so if I were to use the trunk and process files that have color channels larger than 8 bits, then I will stick to GEGL plugins :) I will now start looking at the code structure, and the non-GEGL list list to see what I can do.. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] non-destructive editing and adjustment layers
On 1 September 2013 22:33, Alexandre Prokoudine < alexandre.prokoud...@gmail.com> wrote: > On Mon, Sep 2, 2013 at 12:22 AM, wrote: > > Okay. so do you mean that any non-GEGL plugins or filters should > > be treated as not 32-bit compatible and is therefore capable of > > silently clipping data? > > By the time GIMP 2.10 is out, there will be no such plugins in GIMP, > so what you are suggesting simply doesn't make much sense :) What about all the plugins using the legacy APIs found at registry.gimp.organd other places? -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] non-destructive editing and adjustment layers
On Mon, Sep 2, 2013 at 6:20 PM, Jon Nordby wrote: >> By the time GIMP 2.10 is out, there will be no such plugins in GIMP, >> so what you are suggesting simply doesn't make much sense :) > > What about all the plugins using the legacy APIs found at registry.gimp.org > and other places? They will still look and behave differently :) Personally, I think that if someone has the time to implement a "system-wide" mechanism to detect what kind of plug-in was called, and warn about upcoming loss of data, that would be quite OK :) But _maybe_ this shouldn't be top priority for the time being. Alexandre ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] non-destructive editing and adjustment layers
On Mon, 2013-09-02 at 18:31 +0400, Alexandre Prokoudine wrote: > On Mon, Sep 2, 2013 at 6:20 PM, Jon Nordby wrote: > > >> By the time GIMP 2.10 is out, there will be no such plugins in GIMP, > >> so what you are suggesting simply doesn't make much sense :) > > > > What about all the plugins using the legacy APIs found at registry.gimp.org > > and other places? > > They will still look and behave differently :) > > Personally, I think that if someone has the time to implement a > "system-wide" mechanism to detect what kind of plug-in was called, and > warn about upcoming loss of data, that would be quite OK :) But > _maybe_ this shouldn't be top priority for the time being. That mechanism does exist, we just need to decide whether we want to warn if such a plug-in used. --Mitch ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] non-destructive editing and adjustment layers
>> > >> > What about all the plugins using the legacy APIs found at registry.gimp.org >> > and other places? >> >> They will still look and behave differently :) >> >> Personally, I think that if someone has the time to implement a >> "system-wide" mechanism to detect what kind of plug-in was called, and >> warn about upcoming loss of data, that would be quite OK :) But >> _maybe_ this shouldn't be top priority for the time being. > > That mechanism does exist, we just need to decide whether we want > to warn if such a plug-in used. > If this mechanism does exist, of course we do need to warn whenever any plugin that loses precision is used ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
