Category not showing up in viewer

> 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:)
               )
       )

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 <[hidden email]> wrote:

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

On Sat, Mar 10, 2012 at 12:48 AM, Scott Wallace <[hidden email]> 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.

On Mon, Mar 12, 2012 at 7:46 AM, Bert Freudenberg <[hidden email]> 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.