On Mar 9, 2012, at 5:10 PM, karl ramberg wrote:

On Sat, Mar 10, 2012 at 12:48 AM, Scott Wallace scott.wallace@squeakland.org wrote:

...

Hi I have made the category in morph but it does not show up correctly. The viewer category is showing but not the tiles. I don't understand why I dont see the tiles...

Karl

additionsToViewerCategoryColorFilters "Answer viewer additions for the 'color filter' category"

  ^#(colorFilters
          (
                  (slot hue       'Hue value of my color from -180 to 180' Number  readWrite Player getHue Player setHue:)
                  (slot saturation        'Saturation value of my color from 0 to 100' Number      readWrite Player getSaturation Player setSaturation:)
                  (slot brightness        'Brightness value of my color from 0 to 100' Number readWrite Player getBrightness Player setBrightness:)

Seemingly has to do with camel-casing.

This works:

additionsToViewerCategoryColorFilters "Answer viewer additions for the 'color filter' category"

   ^#(#'color filters'
           (
                   (slot hue       'Hue value of my color from -180 to 180' Number  readWrite Player getHue Player setHue:)
                   (slot saturation        'Saturation value of my color from 0 to 100' Number      readWrite Player getSaturation Player setSaturation:)
                   (slot brightness        'Brightness value of my color from 0 to 100' Number readWrite Player getBrightness Player setBrightness:)
           )
   )

Aha, that works for most morphs, but it still don't show up for SketchMorph.

Karl

Right -- since SketchMorphs have no single "color", many of the color-related variables are meaningless for them, and hence are excluded from their viewers. The three variables in your example are among those excluded; if you look in a Sketch's "fill & border" category you'll notice that they're absent there as well.

-- Scott

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

On Mar 11, 2012, at 12:56 PM, karl ramberg wrote:

But these are really for doing color filters for sketches and images so we should make them available. It's possible to do all sorts of color changing etc. and it's pretty fast because they are run with the scratch plugin.

I'm not sure if we should use the standard color category or another.

Karl

On Sat, Mar 10, 2012 at 4:42 AM, Scott Wallace scott.wallace@squeakland.org wrote: On Mar 9, 2012, at 5:10 PM, karl ramberg wrote:

...

On Sat, Mar 10, 2012 at 12:48 AM, Scott Wallace scott.wallace@squeakland.org wrote:

...

Hi I have made the category in morph but it does not show up correctly. The viewer category is showing but not the tiles. I don't understand why I dont see the tiles...

Karl

additionsToViewerCategoryColorFilters "Answer viewer additions for the 'color filter' category"

  ^#(colorFilters
          (
                  (slot hue       'Hue value of my color from -180 to 180' Number  readWrite Player getHue Player setHue:)
                  (slot saturation        'Saturation value of my color from 0 to 100' Number      readWrite Player getSaturation Player setSaturation:)
                  (slot brightness        'Brightness value of my color from 0 to 100' Number readWrite Player getBrightness Player setBrightness:)

Seemingly has to do with camel-casing.

This works:

additionsToViewerCategoryColorFilters "Answer viewer additions for the 'color filter' category"

   ^#(#'color filters'
           (
                   (slot hue       'Hue value of my color from -180 to 180' Number  readWrite Player getHue Player setHue:)
                   (slot saturation        'Saturation value of my color from 0 to 100' Number      readWrite Player getSaturation Player setSaturation:)
                   (slot brightness        'Brightness value of my color from 0 to 100' Number readWrite Player getBrightness Player setBrightness:)
           )
   )

Aha, that works for most morphs, but it still don't show up for SketchMorph.

Karl

Right -- since SketchMorphs have no single "color", many of the color-related variables are meaningless for them, and hence are excluded from their viewers. The three variables in your example are among those excluded; if you look in a Sketch's "fill & border" category you'll notice that they're absent there as well.

-- Scott

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.

- Bert -

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

On Mon, Mar 12, 2012 at 7:46 AM, Bert Freudenberg bert@freudenbergs.dewrote:

...

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