[etoys-dev] Category not showing up in viewer

[karl ramberg]

On Mon, Mar 12, 2012 at 4:06 PM, Steve Thomas <sthomas1 at gosargon.com> wrote:

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

The code is in the inbox, not trunk for the time being. Works as you
describe. It would be possible to set the red green and blue by reversing
something like

Color>>setHue: hue saturation: saturation brightness: brightness
"Initialize this color to the given hue, saturation, and brightness. See
the comment in the instance creation method for details."

| s v hf i f p q t |
s _ (saturation asFloat max: 0.0) min: 1.0.
v _ (brightness asFloat max: 0.0) min: 1.0.

"zero saturation yields gray with the given brightness"
s = 0.0 ifTrue: [ ^ self setRed: v green: v blue: v ].

hf _ hue asFloat.
(hf < 0.0 or: [hf >= 360.0])
ifTrue: [hf _ hf - ((hf quo: 360.0) asFloat * 360.0)].
hf _ hf / 60.0.
i _ hf asInteger.  "integer part of hue"
f _ hf fractionPart.         "fractional part of hue"
p _ (1.0 - s) * v.
q _ (1.0 - (s * f)) * v.
t _ (1.0 - (s * (1.0 - f))) * v.

0 = i ifTrue: [ ^ self setRed: v green: t blue: p ].
1 = i ifTrue: [ ^ self setRed: q green: v blue: p ].
2 = i ifTrue: [ ^ self setRed: p green: v blue: t ].
3 = i ifTrue: [ ^ self setRed: p green: q blue: v ].
4 = i ifTrue: [ ^ self setRed: t green: p blue: v ].
5 = i ifTrue: [ ^ self setRed: v green: p blue: q ].

self error: 'implementation error'.


Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakland.org/pipermail/etoys-dev/attachments/20120312/384e3df9/attachment.html>