No, your picture is 256 x 256 ... so 256 leds for the diameter :
there's 2-3$ ARM based microcontrollers with 256-512 KB of SRAM, plenty to hold everything in ram.
ex : 2$ (25pcs) for ARM Cortex M4 running at up to 100 Mhz with 1MB of ram :
https://www.digikey.com/product-detail/en/microchip-technology/ATSAM4N16BA-MUR/1611-ATSAM4N16BA-MURCT-ND/68326016$ (25pcs) for 256KB ram and 180 Mhz STM32F446RCT6 :
https://www.digikey.com/product-detail/en/stmicroelectronics/STM32F446RCT6/497-17472-ND/7650386Re memory bandwidth: You could use multiple microcontrollers, for example one for each 128 led segment (if you make a cross out of 4 x 128 led segments). It could be a tad more complex to sync all four - the easiest would be to just go overboard and have 4 micros and 10 wires to each micro: 9 for angle data (0..360) and 1 for strobe/enable (signal micros at same time to change angle)... 11 wires if you want half degree precision
Also no, you're not reading 3 bytes per pixel, you're reading 1 or 2 bytes per pixel (256 color palette, 444 or 565/whatever in worst case scenario). You don't have leds precise enough and powerful enough to have 256 light intensity levels for each color of a led anyway. Dither the image down to 565 or 444 or something like that.
If you use 256 color (1 byte per pixel), your ram bandwidth is a bit higher than using 2 byte per color all the time but you save ram.
ex for 128 led segment 256 color palette: read the coordinates of each point (66 bytes) + read the color index for each (128 bytes) + [1..128 x 2 bytes] = 322...450 bytes per segment. For a full rotation, you have up to 450x360 = 162,000 bytes per frame if you go with 320 updates per turn, 324,000 bytes for 720 updates per turn. For 24 frames, you'd have 3,888,000 bytes or 7,776,000 bytes a second.
If you use 10/12/16 bit color per pixel you can just have two 256x256 arrays and read 2 bytes per pixel.. so now you read 66 bytes for the coordinates of each point, then read 2 bytes x 128 bytes ... you have 322 bytes per angle. That's 115,920 bytes for a 360 step rotation, or 231,840 for 720 updates each rotation.
This version uses less bandwidth as you can see, but the memory needed is double (2 x 64 KB + potentially extra stuff). If you're ram size constrained, palette makes sense.
Just had some fun in php calculating the coordinates of the pixels on each line so you can see how compressible it would be using RLE encoding
If you check the txt file attached, you can see it would compress quite well.
Also added the php script I used (open it in any text editor or run it with php.exe script.php >text_dump.txt - and note it will try to save the generated png file in c:\temp\ - you'll get error if folder doesn't exist)
ps. you could also have a sort of hybrid ... one pixel wide line for the stuff near the center, and 2 pixel line for the 48-64...128 range, where there would be some gaps as you can see in the image
ps i think my math is a bit wrong... it would be one byte for each of the 127 leds that follow the first, which has known coordinates ... so 127 bytes instead of 66 bytes. Worst case scenario. Can be much less using RLE compression
edit: a very basic rle encoding would reduce the 360 angles to 30166 bytes or avg of 83 bytes per line... see script and txt attached.
edit2: and actually, you only need to store one 90 degree chunk, the coordinates are the same for the other 3 chunks of the circle, just flipped or mirrored (ex decrease x offset instead of increase etc etc) ... 1/4th of 30KB (rle compressed) or around 8 KB would be enough