In projects like https://scratch.mit.edu/projects/296724684/ , there are a lot of costumes where a single color theme is used. It is often desired to have different color themes, so that it's possible to render text in a different theme, and also have different colors for each character. The visual effects don't provide enough customization, for example it isn't possible to turn a yellow/black costume into a white/black costume with effects. The pen in the other hand would be way too slow considering how much text there can be.

There are 2 forms of FCR, either of which could potentially become precursors to a new feature in Scratch:

Form 1:

FCR [#FFFF00] to [#FFFFFF] :: grey

The form above takes any pixels of a particular color and changes them to another color, possibly with hardware acceleration. It's possible to have multiple FCR instructions in effect.

Form 2:

FCR R: ()R+()G+()B+(), G: ()R+()G+()B+(), B: ()R+()G+()B+() :: grey

It replaces red, green and blue channels with mathematical expressions based on red, green and blue.

No color change:

FCR R: (1)R+(0)G+(0)B+(0), G: (0)R+(1)G+(0)B+(0), B: (0)R+(0)G+(1)B+(0) :: grey

Inverse colors:

FCR R: (-1)R+(0)G+(0)B+(1), G: (0)R+(-1)G+(0)B+(1), B: (0)R+(0)G+(-1)B+(1) :: grey

Grayscale:

FCR R: (0.299)R+(0.587)G+(0.114)B+(0), G: (0.299)R+(0.587)G+(0.114)B+(0), B: (0.299)R+(0.587)G+(0.114)B+(0) :: grey

Any FCR block of this form would override the previous FCR of this form, working similarly to the effects.

Bump.

Supporters (3):


Semi-supporters (1):


No-supporters (0):


Rejecters (0):


No rating (3):


Scoring rules (add to both numerator and denominator for each instance):

Supporters: 1/1
Semi-supporters: 0.5/1
No-supporters: 0/1
Rejecters: -Infinity/1
No rating: 0/0

Total result for this suggestion: 3.5/4 (87.5% support)

Support. This can be very useful with a lot of costumes and when color effects don't provide enough customization, such as in https://scratch.mit.edu/projects/296724684/ .

This would probably belong in an extension. Also, “FCR” is an undescriptive name. Perhaps it could be called something like “replace colors” or “quickly replace colors”?

Jonathan50 wrote:

This would probably belong in an extension. Also, “FCR” is an undescriptive name. Perhaps it could be called something like “replace colors” or “quickly replace colors”?

"There are 2 forms of FCR, either of which could potentially become precursors to a new feature in Scratch:"

It looks complicated for newer Scratchers, so it should probably be in an extenstion. But, for people who know what they're doing, this could be extremely useful. Support.

Here is some less confusing block syntax:

Replace [#0fBD8C] in sprite with [#5CB1D6] ::#4b4a60

Anyways, I like it! It would fit well with how you can use the color pickers on sprites for the pen tool

Current project: [s3Blocks: scratchblocks rewritten for Scratch 3.0] ::#4b4a60 //https://scratch.mit.edu/discuss/topic/290031/ Basically done!

NitroCipher wrote:

Here is some less confusing block syntax:

Replace [#0fBD8C] in sprite with [#5CB1D6] ::#4b4a60

Anyways, I like it! It would fit well with how you can use the color pickers on sprites for the pen tool

Note that it is two separate FCR suggestions in one topic. One is a color replacement, and the other is a RGB transformation.

support for this being an extension.

Semi-support for it being an extension, because the blocks are much-needed and are wanted by many Scratchers, but the block's jobs aren't clear and many New Scratchers (and some Scratchers!) Would find the.function of the block very confusing
If that was changed then full support

This would be very good for things like a stamp text engine.
I support the first form, the second one looks very long and confusing.
For the first form, you should be able to choose to set, change and multiply the color selected.
Also, it would be nice if it allowed you to choose a color from a costume.

Support if it was an extension. It might be useful for REALLY advanced coders.

This could be really useful for colour-related (perhaps pen) projects, but I have two conditions:

1. I agree with openPoll that this needs to be an extension and not normal blocks because it would be complicated for New Scratchers.
2. We could try reducing the length of the blocks, they are extremely long and one won't even fit in the normal Scratch Editor.

I also created a 3.0 version for this (password is 3.0): https://thinfi.com/gcc3

My name is DoNotFoIIowMe (do not follow me or comment on my profile, you!) and I am a New Scratcher willing to help out on the Scratch community. If you see any of my posts, don't think I'm new myself and that I'm not supposed to be teaching you because I have quite a wide knowledge about Scratch. Just so you know though, following me will ruin my life. People have already disobeyed.

DoNotFoIIowMe wrote:

This could be really useful for colour-related (perhaps pen) projects, but I have two conditions:

1. I agree with openPoll that this needs to be an extension and not normal blocks because it would be complicated for New Scratchers.
2. We could try reducing the length of the blocks, they are extremely long and one won't even fit in the normal Scratch Editor.

I also created a 3.0 version for this (password is 3.0): https://thinfi.com/gcc3

This suggestion wasn't supposed to be used for pen (it wouldn't have an effect on it), it would only transform the visible pixels of the sprite in pretty much the same way as an effect.

-CodePro- wrote:

This would be very good for things like a stamp text engine.
I support the first form, the second one looks very long and confusing.
For the first form, you should be able to choose to set, change and multiply the color selected.
Also, it would be nice if it allowed you to choose a color from a costume.

The second form is a “linear transformation” on all the pixels rather than replacing individual colors like the first form. What do you mean by “set, change and multiply the color selected”? Isn't it possible for the color inputs to input a variable from 0 to 16777215 into, to select the color?

45afc4td wrote:

-CodePro- wrote:

This would be very good for things like a stamp text engine.
I support the first form, the second one looks very long and confusing.
For the first form, you should be able to choose to set, change and multiply the color selected.
Also, it would be nice if it allowed you to choose a color from a costume.

The second form is a “linear transformation” on all the pixels rather than replacing individual colors like the first form. What do you mean by “set, change and multiply the color selected”? Isn't it possible for the color inputs to input a variable from 0 to 16777215 into, to select the color?

set = set the RGB/HSL values to something else.
change = change them relative to the original color.
multiply = multiply or divide them relative to the original color.

Although the most simple and important is replace (color) with (color). (set)

The form 2:

FCR2 R: ()R+()G+()B+(), G: ()R+()G+()B+(), B: ()R+()G+()B+() :: grey

would be the most feasible one. Entering different values would overwrite the FCR2 with a different one. ‘clear all effects’ would clear the FCR2 as well.

Clearing the FCR2 is equivalent to:

FCR2 R: (1)R+(0)G+(0)B+(0), G: (0)R+(1)G+(0)B+(0), B: (0)R+(0)G+(1)B+(0) :: grey

The form 1:

FCR1 [#FFFF00] to [#FFFFFF] :: grey

doesn't look as good. Multiple FCR1 instructions can be in effect, but what if the user iteratively replaces each of the 16777216 colors to the next color? Every pixel would become white, and many FCR1 instructions would have to be processed, causing a major slowdown, and the only way to remove those FCR1 instructions by the suggestion is to ‘clear all effects’.

Support. Could be useful for like inverted color “glitchy spacetime” events.

Though I must suggest renaming “FCR” to something like:

replace every color [] with [] :: sensing

45afc4td wrote:

Clearing the FCR2 is equivalent to:

FCR2 R: (1)R+(0)G+(0)B+(0), G: (0)R+(1)G+(0)B+(0), B: (0)R+(0)G+(1)B+(0) :: grey

R, R+ and G+ are 1
Do I not get it or shouldn't it be:

FCR2 R: (1)R+(0)G+(0)B+(0), G: (1)R+(0)G+(0)B+(0), B: (1)R+(0)G+(0)B+(0) :: grey

?

-CodePro- wrote:

45afc4td wrote:

Clearing the FCR2 is equivalent to:

FCR2 R: (1)R+(0)G+(0)B+(0), G: (0)R+(1)G+(0)B+(0), B: (0)R+(0)G+(1)B+(0) :: grey

R, R+ and G+ are 1
Do I not get it or shouldn't it be:

FCR2 R: (1)R+(0)G+(0)B+(0), G: (1)R+(0)G+(0)B+(0), B: (1)R+(0)G+(0)B+(0) :: grey

?

It's R set to 1R + 0G + 0B + 0, G set to 0R + 1G + 0B + 0 and B set to 0R + 0G + 1B + 0. Every channel is set to itself. Your set of parameters would set all three channels to red, meaning the color becomes a shade of gray set to the red channel, so it doesn't set every color to itself. The inverse formula (in the beginning of the topic) adds a constant 1 and adds -1 multiplied by the channel — this creates an inversion effect, because every channel is set to the inverse of itself. The grayscale formula sets every channel to the sum of 0.299 times red, 0.587 times green and 0.114 times blue, which approximates the visual brightness.

Bump, even though this is a high level function, there is not much possible sprite replacements in form of “effects” so this does make sense; it is really not workaroundable.