[etoys-dev] Category not showing up in viewer
sthomas1 at gosargon.com
Mon Mar 12 11:06:36 EDT 2012
On Mon, Mar 12, 2012 at 7:46 AM, Bert Freudenberg <bert at freudenbergs.de>wrote:
> On 11.03.2012, at 22:35, Scott Wallace wrote:
> > Ah, I can see that *setting* the hue, saturation, or brightness of a
> bitmap is well-defined and can be useful for color effects.
> > But what would be the definitions of the *getters* for these three
> quantities? How could one expect to *get* meaningful values for hue,
> saturation, and brightness from a bitmap, which can have a different value
> for each of these quantities at each pixel?
> > So… a suggestion: for bitmaps, how about offering filtering *commands*
> rather than trying to use variables? For example "applySaturation: foo"?
> This avoids the issue of ill-defined getters...
> > -- Scott
> We've had that discussion before ... and what I suggested before is that
> we should have slots for hue/saturation/brightness *shift*, instead of
> absolute values, which indeed make no sense in the context of images. These
> shift amounts would default to zero, in which case no filtering affects
> would be applied. Setting them to non-zero would add the filtering. Getting
> the values would be as simple (the amounts would be stored in Morph
> properties, and be zero if absent).
> This to me seems a lot more useful than commands, because using slots you
> can much more easily play with these effects, and undo them.
So IF I understand this discussion, we would have tiles that would allow us
to modify: hue, saturation, brightness by some percentage (the shift) *and
be able to undo* whatever "effects" were created by these tiles to "restore
to base graphic" (or the equivelant). It would be great to be able to
modify red, blue and green as well. Not sure if we can or should try for
alpha, especially this late in the release. Sounds great. Thanks to all.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the etoys-dev