GIMP and Google SoC (from digest)
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.
| 20060418181028.CDD2EB3D33E@... | 07 Oct 20:24 | |
| GIMP and Google SoC (from digest) | Dave Neary | 19 Apr 11:58 |
| GIMP and Google SoC (from digest) | GSR - FR | 19 Apr 14:35 |
| GIMP and Google SoC (from digest) | Nathan Summers | 22 Apr 05:11 |
| GIMP and Google SoC (from digest) | GSR - FR | 23 Apr 00:24 |
GIMP and Google SoC (from digest)
Hi,
Michael Schumacher wrote:
Von: Dave Neary
Hi all,
I have registered the GIMP as a mentoring organisation for the Summer of Code (I had been in contact with Google before the announcement), we should be up on the page over the next couple of days.
It would have been nice to know this a bit earlier. As you can see in the other thread, we were already preparing stuff...
I was away for the weekend, when the announcement was made, but the contact I made was last year when the GIMP wasn't in the mentoring organisations, because no-one had asked. This year, I got in early.
I'm not taking this over, by any means. I'd like to have as little as possible to do with it, but I'm happy being an initial point of contact.
Bill Skaggs said:
Thanks Dave for taking the initiative. Does this mean that you are volunteering to be the "coordinator", as described in the SoC FAQ?
I'm the "coordinator" - I have received the information we need to sign up mentors, and anyone who would like to be a mentor for an SoC project should contact me.
The role of mentors is to be present in the soc groups during the start-up phase, commenting on GIMP project ideas, helping people refine those ideas, and after project selection, to supervise someone's work, be their shoulder to cry on when things are going badly, their wall to bounce ideas off, their interface to the greater GIMP community.
We will need 3 or 4 of these, at least, perhaps more.
We should settle on half-a-dozen well-defined project ideas, because having too many choices leads to brain freeze, and people who want to work with GIMP but don't like any of the suggestions are always free to come up with ideas of their own. And it would be nice to put them on a page on the developer web site as opposed to the Wiki.
It is much the same thing - the important thing is to have the ideas available quickly. Either way is fine with me.
I would go for 10 or 12 decent ideas. I would rule out anything that starts "finish...". Outside of that, there's no need to provide specs, and ideas are there to inspire. They should be realistic, but make people go "wow" at the same time.
I think this timeline is unrealistic, and that it would be better to aim for the results of the student projects being incorporated in the 2.4 release.
You're probably right. But we'll need to be a bit slushy about hardening features - 2.4 will be feature frozen when SoC finishes. We can release a slightly buggier than usual 2.4 of course.
2) Resource management. Currently resources such as brushes, gradients etc are shown to the user in an unstructured way, which greatly limits the number of items a user can deal with. People love to make collections of things, so this would greatly enhance the user experience.
This and a decent plug-in distribution system are great ideas.
Sven Neumann said:
- Plug-ins: Save for web for example (too small to be a project, but could be part of one)
IMO "Save for Web" is complex enough for a project.
I may be underestimating the effort involved, but I think I could throw together a prototype fairly quickly.
- Effect layers - I think this is fairly straightforward with the GIMP as it is, it's a nice chunk of a project, and would be a nice feature for users
How is this fairly straightforward with the current architecture? I would rather say that it is currently almost impossible to implement sanely.
Ah, but I'm insane.
Add a layer type for effect layers, and define 3 operations that you can associate with the layer (to start): curves, levels and colour balance. All the operations are pixel-by-pixel, which should make things easier. Then hack the projection code to add a special case for an effect layer.
We'd need to evolve the xcf version number, and it probably wouldn't be possible to do anything useful with the effects layers in earlier versions of the GIMP (ignore seems about the best option).
I don't see why we should wait with GEGL integration. There are people waiting for the 2.4 release to start this work. It would be a huge mistake to postpone this. The amount of GEGL integration that is planned for the next release is small anyway and is unlikely going to delay the 2.6 release.
I'm not proposing delaying gegl integration. I'm just saying that to get the most benefit out of SoC, you need to release people's code soon after the Summer, and the gegl integration isn't going to ship until next Summer probably. So it seems sane to me that gegl integration start on a branch (made straight after 2.4), and gets merged back into HEAD *after* we ship a stable release with SoC projects included. That said, Bill suspects that 2.4 might not get released until after the Summer (seems pessimistic to me, but I'm a bit far from things to be able to say for certain), and in that case, he has a point.
Cheers, Dave.
GIMP and Google SoC (from digest)
Hi,
dneary@free.fr (2006-04-19 at 1158.08 +0200):
How is this fairly straightforward with the current architecture? I would rather say that it is currently almost impossible to implement sanely.
Ah, but I'm insane.
Add a layer type for effect layers, and define 3 operations that you can associate with the layer (to start): curves, levels and colour balance. All the operations are pixel-by-pixel, which should make things easier. Then hack the projection code to add a special case for an effect layer.
Internally I would say they are blend modes. Make them special so content is fixed and flat (better compression), so only layer mask matters. Then make the formula for the blend mode be curves, levels, colour balance... whatever you can find that is pix to pix (and probably LUT based in many cases, if not all) and make it work in BG while the FG is unused. The settings would be stored in a parasite.
PS allows the following types: http://www.bairarteditions.com/pages/tutorials/photoshop/images/layerpalette.gif Except gradient and pattern, all the rest are pixel in, pixel out, without caring about the position.
We'd need to evolve the xcf version number, and it probably wouldn't be possible to do anything useful with the effects layers in earlier versions of the GIMP (ignore seems about the best option).
It would load a flat colour in normal mode and keep the layer mask, if implemented as above, I think, and maybe lose the parasite? It was time ago when I ported some modes and thus looked at XCF load/save.
GSR
GIMP and Google SoC (from digest)
On 4/19/06, GSR - FR wrote:
Hi,
dneary@free.fr (2006-04-19 at 1158.08 +0200):How is this fairly straightforward with the current architecture? I would rather say that it is currently almost impossible to implement sanely.
Ah, but I'm insane.
Add a layer type for effect layers, and define 3 operations that you can associate with the layer (to start): curves, levels and colour balance. All the operations are pixel-by-pixel, which should make things easier. Then hack the projection code to add a special case for an effect layer.Internally I would say they are blend modes. Make them special so content is fixed and flat (better compression), so only layer mask matters. Then make the formula for the blend mode be curves, levels, colour balance... whatever you can find that is pix to pix (and probably LUT based in many cases, if not all) and make it work in BG while the FG is unused. The settings would be stored in a parasite.
Excellent idea. Unfortunately, when people say they want layer effects most of the time what they mean is that they want spiffy auto-drop shadows. Of course, that's not that hard to represent with a few parameters. But it's not exactly something you can implement with a LUT. Still, I think it's pretty doable as a custom layer. Perhaps implementing some as blend types and some as custom layers is a good plan.
Rockwalrus
GIMP and Google SoC (from digest)
Hi,
rockwalrus@gmail.com (2006-04-21 at 2311.22 -0400):
On 4/19/06, GSR - FR wrote:
Hi,
dneary@free.fr (2006-04-19 at 1158.08 +0200):How is this fairly straightforward with the current architecture? I would rather say that it is currently almost impossible to implement sanely.
Ah, but I'm insane.
Add a layer type for effect layers, and define 3 operations that you can associate with the layer (to start): curves, levels and colour balance. All the operations are pixel-by-pixel, which should make things easier. Then hack the projection code to add a special case for an effect layer.Internally I would say they are blend modes. Make them special so content is fixed and flat (better compression), so only layer mask matters. Then make the formula for the blend mode be curves, levels, colour balance... whatever you can find that is pix to pix (and probably LUT based in many cases, if not all) and make it work in BG while the FG is unused. The settings would be stored in a parasite.
Excellent idea. Unfortunately, when people say they want layer effects most of the time what they mean is that they want spiffy auto-drop shadows. Of course, that's not that hard to represent with a few parameters. But it's not exactly something you can implement with a LUT. Still, I think it's pretty doable as a custom layer. Perhaps implementing some as blend types and some as custom layers is a good plan.
What I described above is what matches David text ("curves, levels and colour balance"). He could had used the name Adjustment Layer (the PS term) or a different description. What you describe is named Layer Styles (in PS). People want Adjustment Layers anyway too. The main difference I can see is that one has a layer mask as a requisite (and the operations performed are in what that layer mask lets pass) and the other has pixel data (and the operations are performed in those pixels).
Global view:
http://depts.washington.edu/sacg/services/workshops/desktop/photoshop2/layers.shtml
Adjusment layers (AL, mixed with other topics):
http://www.arraich.com/ps6_tips_llayers1.htm
Layers Styles (LS):
http://www.arraich.com/effects1/aaeffects_main.htm
And from the bugs and talks in the past, what some people would like is a "no limits" version, in which you can apply any filter. That has a problem compared to PS ways, the order. PS declares one special kind of layer (AL) that works in same order than others, and a reduced set of operations (LS) applied in the order that makes sense (embossing the result of the drop shadow? weird) to a given layer.
For a "no limits" the interface has to be reviewed, one option being some kind of order index, other being a graph approach, in which the user defines all the orders and relations (this would allow filters that work with multiple input or output drawables, for example).
That is why I see AL to be the simpler to do, then LS (it would require a system to keep the user data and swap with the result data, depending if editing or compositing) and finally the full "you do whatever you want" system.
GSR
