[etoys-dev] Category not showing up in viewer
karlramberg at gmail.com
Mon Mar 12 13:16:56 EDT 2012
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
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'.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the etoys-dev