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
[Gimp-developer] Translation handling with python plugins
Dear GIMP developers, i'd like to update some of my older scripts and write some new too. Is there meanwhile a way to handle translations of the UI? Cheers Eckhard. ___ 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
[Gimp-developer] Translation handling with python plugins
Dear GIMP developers, i'd like to update some of my older scripts and write some new too. Is there meanwhile a way to handle translations of the UI? Cheers Eckhard. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] Documentation about menu hooks
Dear developers, is there a documentation about menu hooks in GIMP? Is there a listing at the source code? I tired to try out how to get my python plugins in the right place. So i'd like to do a visual documentation for any developer. I attached an example on this mail. This could be later published on gimp.org. Cheers Eckhard. ___ 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
