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

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

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

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

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 ->

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

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

El 01/09/13 17:22, kcleung@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.

On 1 September 2013 22:33, Alexandre Prokoudine < alexandre.prokoudine@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

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

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