Re: toward a plan for 2.8

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Jan 27, 2008 8:52 AM, William Skaggs <weskaggs@xxxxxxxxxxxxxxxxxxx> wrote:
> One of the points that emerged from the ongoing discussion is that it
> is time to start making a tentative roadmap for 2.8.  I hope this time
> that Peter and his group can be brought into the discussion as early
> as possible, and will play a role in shaping the plan.
>
> As I wrote earlier, Peter in his LGM talk listed the things he
> considered the top priorities at the UI level:
>
> 10. better printing support
> 9.  painting with brushes
> 8.  improve the text tool
> 7.  save for web
> 6.  organize brushes, palettes, gradients in categories
> 5.  avoid pop-up dialogs
> 4.  better painting tools
> 3.  layer trees
> 2.  adjustment layers
> 1.  single window interface
>
> Of these items, #1 is controversial, and #2 and #3 depend on Gegl
> developments.  Each of the remaining things are potential targets for
> 2.8 -- in fact, I don't see any reason why it wouldn't be possible to
> do several of them.  In particular, I think it should be possible, and
> very cool, to implement the "blobs of paint" idea that is part of #4.
I thought that #4 was dependent on (the use of, but not the overall
adoption of) Gegl. Perhaps I've misunderstood you.
At the moment, we do have some useful GEGL ops that could be used to
back the 'blobs of paint' idea.

At a casual glance, most of the approachable ops would work best for
mask adjustment:
   * range adjustment (gimp-levels
   * halo adjustment (gimp-curves)
   * hardening (gimp-threshold)
   * blurring
   * inversion (good for stenciling, ie. layer masks)
   * noise

There are some that work with colors:
   * colorbalance
   * colorify
   * white balance

Can we use the transform ops (rotate/flip/etc)? That would be very nice.
Initially, I figure we will only make the brush data available to ops,
so it could
be done with a linear stack of Ops. After a while, you might want to
combine brushes, so that might develop into a normal tree.

Actually, technically it would start as a tree, looking like this:

brush-output (sink)
  |
 +- add_alpha
  |
 ++--- last_mask_op
   |         |-- some_mask_op
   |         +-brush-mask (source)
   +--- last_color_op
             |-- some_color_op
             +- brush_color (source)


If we wanted to combine blobs of paint, that would amount to
re-separating the mask and color, and connecting the output to the
newly added blob.

More advanced things, such as spatially-dependent paint (think of the
clone tool in aligned mode), would have to wait until GIMP was using
GEGL for images, so that a brush could know what region was requested
in terms of the image coords.

I think 'blobs of paint' would be a good place to experiment with GEGL
graphing UI, that could later be refactored to be more generally
usable for GIMP.
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux