[FYI] Filter layer implementation in gimp-2.8+
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
| [FYI] Filter layer implementation in gimp-2.8+ | sigetch | 07 Aug 14:13 |
| [FYI] Filter layer implementation in gimp-2.8+ | Alexandre Prokoudine | 07 Aug 15:30 |
| [FYI] Filter layer implementation in gimp-2.8+ | Michael Natterer | 07 Aug 16:35 |
| [FYI] Filter layer implementation in gimp-2.8+ | sigetch | 07 Aug 17:09 |
| [FYI] Filter layer implementation in gimp-2.8+ | C R | 07 Aug 20:02 |
| [FYI] Filter layer implementation in gimp-2.8+ | Alexandre Prokoudine | 07 Aug 20:50 |
| [FYI] Filter layer implementation in gimp-2.8+ | Tobias Jakobs | 08 Aug 07:22 |
| [FYI] Filter layer implementation in gimp-2.8+ | sigetch | 08 Aug 14:38 |
[FYI] Filter layer implementation in gimp-2.8+
Hello all,
I recently added filter layer (or adjustment layer in other words) in my
gimp-painter 2.8 branch. You can see how it works at following demo movie.
https://www.youtube.com/watch?v=ddzAqrppHnk
If you are interested in filter layer, please visit https://github.com/seagetch/gimp-painter to see details.
Thanks,
--
seagetch
[FYI] Filter layer implementation in gimp-2.8+
Hello,
I've been wondering when you'd announce that :)
As is usual with your fork, it's impressive work. I definitely like some of the implementation specifics, although I can see that certain things could be improved (I can elaborate on that, if you wish).
Unfortunately, this cannot be backported to mainstream GIMP 'as is'. Off top of my head:
- It's based on GIMP 2.8 that uses obsolete tech. - Your implementation doesn't use the "new" GimpFilterStack class (available in git master since 2013) for stacking filters on a layer. - XCF version in upstream's git master is already 10 now, while you use v4, so that would make mainstream GIMP and your fork (even more?) incompatible.
Personally, I'm not sure what is the best approach here.
On one hand, this is something users have been requesting for ages, and I can already here crowds screaming, how dare I criticize your work :)). On the other hand, certain changes would need to happen for this to be merged. On yet another hand, I don't know how this will play with proposed release order where non-destructive editing is scheduled for 3.2.
More opinions, please?
Alex
On Mon, Aug 7, 2017 at 5:13 PM, sigetch wrote:
Hello all,
I recently added filter layer (or adjustment layer in other words) in my gimp-painter 2.8 branch. You can see how it works at following demo movie. https://www.youtube.com/watch?v=ddzAqrppHnkIf you are interested in filter layer, please visit https://github.com/seagetch/gimp-painter to see details.
Thanks, --
seagetch
_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
[FYI] Filter layer implementation in gimp-2.8+
On Mon, 2017-08-07 at 18:30 +0300, Alexandre Prokoudine wrote:
Hello,
I've been wondering when you'd announce that :)
As is usual with your fork, it's impressive work. I definitely like some of the implementation specifics, although I can see that certain things could be improved (I can elaborate on that, if you wish).
Unfortunately, this cannot be backported to mainstream GIMP 'as is'. Off top of my head:
- It's based on GIMP 2.8 that uses obsolete tech. - Your implementation doesn't use the "new" GimpFilterStack class (available in git master since 2013) for stacking filters on a layer. - XCF version in upstream's git master is already 10 now, while you use v4, so that would make mainstream GIMP and your fork (even more?) incompatible.
Personally, I'm not sure what is the best approach here.
On one hand, this is something users have been requesting for ages, and I can already here crowds screaming, how dare I criticize your work :)). On the other hand, certain changes would need to happen for this to be merged. On yet another hand, I don't know how this will play with proposed release order where non-destructive editing is scheduled for 3.2.
More opinions, please?
The biggest problem is that the branch uses a lot of C++ code, which, unfortunately, can't go upstream.
Regards, Mitch
Alex
On Mon, Aug 7, 2017 at 5:13 PM, sigetch wrote:
Hello all,
I recently added filter layer (or adjustment layer in other words) in my
gimp-painter 2.8 branch. You can see how it works at following demo movie.
https://www.youtube.com/watch?v=ddzAqrppHnkIf you are interested in filter layer, please visit https://github.com/seagetch/gimp-painter to see details.
Thanks, --
seagetch
_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-devel oper-list
List archives: https://mail.gnome.org/archives/gimp-developer-lis t_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-develop er-list
List archives: https://mail.gnome.org/archives/gimp-developer-list
[FYI] Filter layer implementation in gimp-2.8+
Thanks for your feedback!
2017年8月8日(火) 0:31 Alexandre Prokoudine :
As is usual with your fork, it's impressive work. I definitely like some of the implementation specifics, although I can see that certain things could be improved (I can elaborate on that, if you wish).
Thanks. Basically, purpose of my fork is to see what is good external specs, and where to implement functions to work functions correctly. If you like part of the specs, I'm happy to hear that.
Unfortunately, this cannot be backported to mainstream GIMP 'as is'. Off top of my head:
- It's based on GIMP 2.8 that uses obsolete tech. - Your implementation doesn't use the "new" GimpFilterStack class (available in git master since 2013) for stacking filters on a layer. - XCF version in upstream's git master is already 10 now, while you use v4, so that would make mainstream GIMP and your fork (even more?) incompatible.
==snipped==
On yet another hand, I don't know how this will play with proposed release order where non-destructive editing is scheduled for 3.2.
As for road-map, it depends on the project's development policy. Personally, I think "non-destructive" and "filter layer" is not the same thing, because painting tool, transform tool, or other functions also have to be "non-destructive" at gimp 3.2. "Filter layer" is the sub-step toward the whole "non-destructive" concept. In another aspect, some of the graphics editor have "filter-layer" and "filter-mask." Both have pros and cons. I think several approaches can coexist for "non-destructive" editing concept.
And as you mentioned, I also know there's no straight path to merge my work to upstream for now. (I used C++, that might be a big problem :) )
My proposal is to start with discussion of the external specs for filter specs, and to launch low-priority "filter-layer" development sub-project.
In my thoughts, following should be discussed to get things move forward.
- Filter should be layer ? or attributes of the layer? I chose filter as layer design. GimpFilterStack seems to choose latter one.
- What kind of filter functions should be applied. In my work, PDB or plug-in function is applied. Alternative candidates is to use Gegl operations for filter.
- How the filter should work with undo buffer? Currently in my branch, part of the undo operation is simply ignored.
- How to deal with brush tool? Simple gegl operation chain may be annoying when brush tool updates underlying layer continuously.
- What kind of GUI should be provided for filter configuration? PDB functions have good configuration dialog, but it is hard to use that kind of dialog from outside of PDB process.
If you all like filter layer, I'd like to continue discussion.
Regards,
--
seagetch
[FYI] Filter layer implementation in gimp-2.8+
Krita currently has an implementation of this in addition to just filters attached to specific layers. Maybe it's worth looking over their shoulders for ideas, as they seem to have handled it quite well.
Thanks for your work on GIMP! -C
On Mon, Aug 7, 2017 at 6:09 PM, sigetch wrote:
Thanks for your feedback!
2017年8月8日(火) 0:31 Alexandre Prokoudine :
As is usual with your fork, it's impressive work. I definitely like some of the implementation specifics, although I can see that certain things could be improved (I can elaborate on that, if you wish).
Thanks. Basically, purpose of my fork is to see what is good external specs, and where to implement functions to work functions correctly. If you like part of the specs, I'm happy to hear that.
Unfortunately, this cannot be backported to mainstream GIMP 'as is'. Off top of my head:
- It's based on GIMP 2.8 that uses obsolete tech. - Your implementation doesn't use the "new" GimpFilterStack class (available in git master since 2013) for stacking filters on a layer. - XCF version in upstream's git master is already 10 now, while you use v4, so that would make mainstream GIMP and your fork (even more?) incompatible.
==snipped==
On yet another hand, I don't know how this will play with proposed release order where non-destructive editing is scheduled for 3.2.
As for road-map, it depends on the project's development policy. Personally, I think "non-destructive" and "filter layer" is not the same thing, because painting tool, transform tool, or other functions also have to be "non-destructive" at gimp 3.2. "Filter layer" is the sub-step toward the whole "non-destructive" concept. In another aspect, some of the graphics editor have "filter-layer" and "filter-mask." Both have pros and cons. I think several approaches can coexist for "non-destructive" editing concept.
And as you mentioned, I also know there's no straight path to merge my work to upstream for now. (I used C++, that might be a big problem :) )
My proposal is to start with discussion of the external specs for filter specs, and to launch low-priority "filter-layer" development sub-project.
In my thoughts, following should be discussed to get things move forward.
- Filter should be layer ? or attributes of the layer? I chose filter as layer design. GimpFilterStack seems to choose latter one.
- What kind of filter functions should be applied. In my work, PDB or plug-in function is applied. Alternative candidates is to use Gegl operations for filter.
- How the filter should work with undo buffer? Currently in my branch, part of the undo operation is simply ignored.
- How to deal with brush tool? Simple gegl operation chain may be annoying when brush tool updates underlying layer continuously.
- What kind of GUI should be provided for filter configuration? PDB functions have good configuration dialog, but it is hard to use that kind of dialog from outside of PDB process.
If you all like filter layer, I'd like to continue discussion.
Regards, --
seagetch
_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
[FYI] Filter layer implementation in gimp-2.8+
On Mon, Aug 7, 2017 at 8:09 PM, sigetch wrote:
As for road-map, it depends on the project's development policy. Personally, I think "non-destructive" and "filter layer" is not the same thing, because painting tool, transform tool, or other functions also have to be "non-destructive" at gimp 3.2.
To the best of my knowledge, we haven't actually discussed how much exactly would be done in 3.2. We know we want some sort of adjustment layers for sure.
= snip=
- Filter should be layer ? or attributes of the layer? I chose filter as layer design. GimpFilterStack seems to choose latter one.
IMO, both layer filters and filter layers have their use.
Also, to quote mitch from today's IRC discussion:
"it's a medium joke to implement "adjustment layers" is the generally used term... in fact a layer *is* a filter on the stack below, just need to replace gegl:buffer-source by another op, in simple terms"
- What kind of filter functions should be applied. In my work, PDB or plug-in function is applied. Alternative candidates is to use Gegl operations for filter.
GEGL filters are the way to go :)
= snip=
- What kind of GUI should be provided for filter configuration? PDB functions have good configuration dialog, but it is hard to use that kind of dialog from outside of PDB process.
GEGL filters can have either automatically generated or custom UIs. There even is some metadata to help build more sensible UIs, from using custom widgets instead of regular spinboxes to "adaptive" layouts. E.g.: https://streamable.com/ajbi4 (available in upcoming 2.9.6).
Alex
[FYI] Filter layer implementation in gimp-2.8+
2017-08-07 22:50 GMT+02:00 Alexandre Prokoudine :
On Mon, Aug 7, 2017 at 8:09 PM, sigetch wrote:
As for road-map, it depends on the project's development policy. Personally, I think "non-destructive" and "filter layer" is not the same thing, because painting tool, transform tool, or other functions also have to be "non-destructive" at gimp 3.2.
To the best of my knowledge, we haven't actually discussed how much exactly would be done in 3.2. We know we want some sort of adjustment layers for sure.
Peter Sikking had some thoughts on filter layers some time ago that I
really like:
http://blog.mmiworks.net/2012/01/gimp-full-gegl-ahead.html
Tobias
[FYI] Filter layer implementation in gimp-2.8+
2017年8月8日(火) 5:50 Alexandre Prokoudine :
On Mon, Aug 7, 2017 at 8:09 PM, sigetch wrote: IMO, both layer filters and filter layers have their use.
Also, to quote mitch from today's IRC discussion:
"it's a medium joke to implement "adjustment layers" is the generally used term... in fact a layer *is* a filter on the stack below, just need to replace gegl:buffer-source by another op, in simple terms"
Okay, maybe we have several design choice of adjustment layer actually, including Krita, Photoshop, Clip Studio, and others.
I'd like to point out some of the design point for filter layer from my experience as a user. Be careful that filter layer is somewhat different from the simple "history of the gegl operation to the stack."
1) Whether filter layer itself is a "layer with surface", or just the "filter operation" on top of the stack.
In Krita, Photoshop and my branch, filter layer itself has a surface on the
stack. That means surface projection is generated from the projection of
the stack, and generated surface is composited into layer stack. This is
useful because we can affect stack in two way (filter and composition).
This feature is practical if we consider the post-processing by filter to
the existing photo.
We sometimes copied base image layer, applied some filter for copied layer,
and composite copied layer onto base layer.
I think we can naturally follow this step when using filter layer.
2) Clipping and masking can be applied to the layer or not
Like Krita's filter-mask, and Photoshop's filter layer, applying filter to part of the image is very common requirements. Krita's filter layer is applied to whole projection, that is not attractive to me. In my branch, filter layer is derived from basic filter. So resize, and layer mask can be used with filter layer. In short, filter layer can be the placeholder of the masks and clipping bounds.
3) Operation to the stack? or operation to the one-layer's projection?
Krita separates non-destructive editing in two ways. Filter layer and
Filter mask. Filter layer affects whole layer stack, and filter mask goes
only for one layer.
Of course, both mode is useful in different use cases.
Photoshop has an option to restrict filter only to underlying layer's
projection. I think just inserting filter layer into stack, and then
specifying which projection to apply, is the easiest way.
4) Filter update frequency
Krita's filter reflects the updates of underlying filter immediately, and
displays it in real time. I was annoyed with that. Updating process
prevents other event processing, thus brush stroke cannot be smooth as
expected.
In my branch, all update propagation is suppressed when underlying filter
is changed.
This kept brush stroke smooth, but of course, we can see the lag of the
updates of filter layer. We need to see further consideration on update
policy.
As a result of above consideration, I designed my specifications of filter
layer.
Any comments are welcome.
GEGL filters can have either automatically generated or custom UIs. There even is some metadata to help build more sensible UIs, from using custom widgets instead of regular spinboxes to "adaptive" layouts. E.g.: https://streamable.com/ajbi4 (available in upcoming 2.9.6).
Great work! Good news to me.
Regards,
--
seagetch
