Could look something like this, and either could return a hex value of the colour or another form.

(color of pixel at x: () y: () :: sensing)

Anyways this is needed as the workarounds are very cumbersome and slow.

Could you give a specific example of how this might be useful? (Something other than “it can be used to detect color at a certain location”.)

In addition, what could it return, hexadecimal values for color?

Za-Chary wrote:

Could you give a specific example of how this might be useful? (Something other than “it can be used to detect color at a certain location”.)

In addition, what could it return, hexadecimal values for color?

If you look at projects that scan pictures to lists, they are very slow as they cannot directly detect the colour of a pixel at a specific location, rather they must go through every colour for every pixel.
This would allow for fast scanning.

I suppose it would return hexadecimal values for colour, however scratch could choose to implement it differently than I have in mind (for example using scratch's in built colour mechanism.)

No support, this could allow people to scan from the camera and put it on a cloud variable, than look at it and possibly record them.

badatprogrammingibe wrote:

Za-Chary wrote:

Could you give a specific example of how this might be useful? (Something other than “it can be used to detect color at a certain location”.)

In addition, what could it return, hexadecimal values for color?

If you look at projects that scan pictures to lists, they are very slow as they cannot directly detect the colour of a pixel at a specific location, rather they must go through every colour for every pixel.
This would allow for fast scanning.

I suppose it would return hexadecimal values for colour, however scratch could choose to implement it differently than I have in mind (for example using scratch's in built colour mechanism.)

Hmm…that does sound cool.

Overall, I'd say semi-support because you'd be able to make some really cool stuff with this. However, one would have to consider very heavily how this boolean returns stuff. Would it return a hexadecimal value? If so, that may be confusing for younger users. Would it return a list of numbers representing the colors in the editor? If so, that may be tough since no other Scratch boolean returns lists (to my knowledge).

I do think it could work, though. It would just require some thought, as always.

Za-Chary wrote:

badatprogrammingibe wrote:

Za-Chary wrote:

Could you give a specific example of how this might be useful? (Something other than “it can be used to detect color at a certain location”.)

In addition, what could it return, hexadecimal values for color?

If you look at projects that scan pictures to lists, they are very slow as they cannot directly detect the colour of a pixel at a specific location, rather they must go through every colour for every pixel.
This would allow for fast scanning.

I suppose it would return hexadecimal values for colour, however scratch could choose to implement it differently than I have in mind (for example using scratch's in built colour mechanism.)

Hmm…that does sound cool.

Overall, I'd say semi-support because you'd be able to make some really cool stuff with this. However, one would have to consider very heavily how this boolean returns stuff. Would it return a hexadecimal value? If so, that may be confusing for younger users. Would it return a list of numbers representing the colors in the editor? If so, that may be tough since no other Scratch boolean returns lists (to my knowledge).

I do think it could work, though. It would just require some thought, as always.

I'd imagine it's probably supposed to be a reporter:

(color at x: () y: ()::sensing)

DaEpikDude wrote:

I'd imagine it's probably supposed to be a reporter:

(color at x: () y: ()::sensing)

Ah, good point. That must be what @badatprogrammingibe was referring to. It still may be a little tough to determine what it returns, though.

DaEpikDude wrote:

Za-Chary wrote:

badatprogrammingibe wrote:

Za-Chary wrote:

Could you give a specific example of how this might be useful? (Something other than “it can be used to detect color at a certain location”.)

In addition, what could it return, hexadecimal values for color?

If you look at projects that scan pictures to lists, they are very slow as they cannot directly detect the colour of a pixel at a specific location, rather they must go through every colour for every pixel.
This would allow for fast scanning.

I suppose it would return hexadecimal values for colour, however scratch could choose to implement it differently than I have in mind (for example using scratch's in built colour mechanism.)

Hmm…that does sound cool.

Overall, I'd say semi-support because you'd be able to make some really cool stuff with this. However, one would have to consider very heavily how this boolean returns stuff. Would it return a hexadecimal value? If so, that may be confusing for younger users. Would it return a list of numbers representing the colors in the editor? If so, that may be tough since no other Scratch boolean returns lists (to my knowledge).

I do think it could work, though. It would just require some thought, as always.

I'd imagine it's probably supposed to be a reporter:

(color at x: () y: ()::sensing)

Yeah, that's what it was supposed to be.

It is slow, but fast:
(2 by 2 costume)

when green flag clicked
Find Pixel At X: () and Y: ()

define Find Pixel At X: (x) and Y: (y)
found = 0
go to x: (x) y: (y)
repeat until <(found) = [1]>
colour += 1
if <touching color (colour)>
found = 1
end

Sheep_maker wrote:

Duplicate

Er, that's wrong.

Tallented-Code-bot wrote:

No support, this could allow people to scan from the camera and put it on a cloud variable, than look at it and possibly record them.

even if you tried it would be very low resulotion (the current restrictions do well on preventing chats and recording video footage)

support, since any current workarounds currently lag scratch quite a bit

but a point to discuss is would it result a hex or a color value
if it would be a color value then we could convert it (would be hard for less experienced scratchers) or we could add a “turn (color) to hex” block but that is an entirely different suggestion, so suggest it on a new topic

Here's the actual duplicate (or at least one of them): https://scratch.mit.edu/discuss/topic/250529/

Tallented-Code-bot wrote:

No support, this could allow people to scan from the camera and put it on a cloud variable, than look at it and possibly record them.

I've put my thoughts out on this in the other thread but, worse case scenario, disable camera if the project has cloud variables, this block, and camera on in the same project.

Griffpatch made a great video on how to do a reasonably fast color picker that can be done in Scratch now here: https://www.youtube.com/watch?v=aBTh756kCZw
However, I think there is still merit to having a block like this for the increased performance and accuracy, in addition to being much more intuitive then the work around we have now.

1ogic wrote:

Here's the actual duplicate (or at least one of them): https://scratch.mit.edu/discuss/topic/250529/

Tallented-Code-bot wrote:

No support, this could allow people to scan from the camera and put it on a cloud variable, than look at it and possibly record them.

I've put my thoughts out on this in the other thread but, worse case scenario, disable camera if the project has cloud variables, this block, and camera on in the same project.

Griffpatch made a great video on how to do a reasonably fast color picker that can be done in Scratch now here: https://www.youtube.com/watch?v=aBTh756kCZw
However, I think there is still merit to having a block like this for the increased performance and accuracy, in addition to being much more intuitive then the work around we have now.

i agree also blank
meet ok. He gives you something.
Wait no. Press both. both

Ok!