Mast3rbug
Posts: 5
Joined: Sun Dec 30, 2018 7:55 pm

256 colors mode.

Sun Dec 30, 2018 8:49 pm

Hi All.

I purchased my first raspberry PI and now I'm experimenting with it in Python. At the moment, I'm using the SPI port to communicate with a 128 x128 pixel OLED RGB display. The display is in 262K color mode (RGB 6 bit / color). I wondered if a conversion mode is available in OPENCV or NUMPY to convert the map to 256 colors mode to speed up the transfer rate between the PI and my display? I don't need to have so much colors anyway.

At the moment, I'm using this to convert the resolution:

Code: Select all

img = cv2.imread('cat.jpg',4)
resizedpic=cv2.resize(img, dsize=(128, 128), interpolation=cv2.INTER_CUBIC)

I want to convert to a 8bit pixel Array like this: RRRGGGBB. I don't want to convert it by code because it's too slow in python. So if a function is available to do the job, that would be wonderful.
Also, if any of you want help to communicate with an SPI display I can post the code.
Thanks!


Here a picture of my setup just to show you the result:

Image

Cedric

User avatar
paddyg
Posts: 2315
Joined: Sat Jan 28, 2012 11:57 am
Location: UK

Re: 256 colors mode.

Sun Dec 30, 2018 11:25 pm

there might be something in PIL but in numpy I would try something like

Code: Select all

import numpy as np 
img = img[:,:,0] & 224 + np.right_shift (img[:,:,1], 3) & 28 + np.right_shift (img[:,:,2], 6)
where img is your resized pic. Not tested as only have phone here.
also https://groups.google.com/forum/?hl=en-GB&fromgroups=#!forum/pi3d

Mast3rbug
Posts: 5
Joined: Sun Dec 30, 2018 7:55 pm

Re: 256 colors mode.

Mon Dec 31, 2018 8:06 am

Nice! Python is really new for me. I know better C, VB and ASM.


So, if I iunderstand, this type of call will execute at the function speed, not the Python interpreter speed (not like loop)?
Thanks!
Cedric

User avatar
paddyg
Posts: 2315
Joined: Sat Jan 28, 2012 11:57 am
Location: UK

Re: 256 colors mode.

Mon Dec 31, 2018 8:27 am

yes numpy is v fast. numba jit will also compile python to v fast exec
also https://groups.google.com/forum/?hl=en-GB&fromgroups=#!forum/pi3d

User avatar
OutoftheBOTS
Posts: 711
Joined: Tue Aug 01, 2017 10:06 am

Re: 256 colors mode.

Mon Dec 31, 2018 9:05 pm

I am a little confused upon the what colour modes u r starting from and what colour modes your converting to.

Most of these little SPI screens can be run in either 16bit colour(recommended) or 18bit colour(a pain in the butt)

16bit colour RGB565 (5 bits of red, 6 bits of green and 5 bits of blue) this gives you 2^16 = 65,536 colours

18bit colour RGB666 (6 bits of red, 6 bbits of green and 6 bits of blue) this gives you 2^18 = 262,144 colours

Most cameras output 24bit colour RGB888 (8 bits of each colour) this gives you 2^24 = 16,777,216 colours

Using 18bit colour is a really big pain in the butt as each pixel doesn't fit nicely into bytes(8 bits). 16bit colour can even be better on the human eye because the human eye is more sensitive to green than another colour and 16bit colour has higher resolution in the green channel than the other channels.

User avatar
paddyg
Posts: 2315
Joined: Sat Jan 28, 2012 11:57 am
Location: UK

Re: 256 colors mode.

Tue Jan 01, 2019 1:12 am

yes, good point. in numpy to produce 565 result you would change the bitshift values and the and masks then (...).astype(np.uint16)
also https://groups.google.com/forum/?hl=en-GB&fromgroups=#!forum/pi3d

Mast3rbug
Posts: 5
Joined: Sun Dec 30, 2018 7:55 pm

Re: 256 colors mode.

Tue Jan 01, 2019 2:53 am

The 256 color mode is this one:

Image

and the 262K colors is this other one, not really hard to address, only bit shifting twice per color. But the transfer data rate over SPI is the bottle neck. This is why I want to use only 8 colors. but I can also try the 16 bit mode.

Image

Cedric

User avatar
OutoftheBOTS
Posts: 711
Joined: Tue Aug 01, 2017 10:06 am

Re: 256 colors mode.

Tue Jan 01, 2019 8:07 am

Can you please post a link to the screen that your using.

I use all sorts of little SPI screens all the time for a number of different project and drive then with lots of different processor from RPi to STM32 to ESP32 and you should have any sort of problem with getting high enough frame rares on such a low res screen in 16bit colour mode.

Here's an example I was reading a camera in 8 bit parallel in 16 bit colour at 320x240 res and sending the data to a ili9341 SPI screen in same 16 bit colour in 320x240 res and was getting 26fps on a stm32F103 MCU that runs at 72MHz so a RPi running at 1.2GHz on a tiny little 128x128 res screen should be able to get very good frame rates.

User avatar
Gavinmc42
Posts: 3148
Joined: Wed Aug 28, 2013 3:31 am

Re: 256 colors mode.

Tue Jan 01, 2019 8:45 am

The driver chip info is the important bit.
New drivers going into the Linux Kernel will only update changed pixel not the whole image.

Start here to check if you have a matching chip?
https://github.com/notro/fbtft
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

User avatar
OutoftheBOTS
Posts: 711
Joined: Tue Aug 01, 2017 10:06 am

Re: 256 colors mode.

Tue Jan 01, 2019 10:34 am

I written my own drivers for these little screen before and once once u run initialization code then set the window you want to write too you can just send the RAMWR (ram write) command then send the image buffer to the SPI then it will appear on the screen.

here is a good example of a driver I wrote for OpenMV cam running Micro-python on a stm32f7 chip to see it in action watch from 1:40 https://www.youtube.com/watch?v=onzi71RsGXw

Mast3rbug
Posts: 5
Joined: Sun Dec 30, 2018 7:55 pm

Re: 256 colors mode.

Wed Jan 02, 2019 9:02 am

The Display I use was purchased at sparkfun a few years ago. It's a discontinued product by now. The display is based on SSD1339. I was able to reach a good frame rate with random data (RAMwrite) but what it slowdown the transfer is the conversion in Python. I do it in For Loop and this is not the best way to do it.

Cedric

User avatar
OutoftheBOTS
Posts: 711
Joined: Tue Aug 01, 2017 10:06 am

Re: 256 colors mode.

Wed Jan 02, 2019 8:11 pm

So what happens is python is slow to call a function. So calling the function to write to the SPI takes much longer than the writing.

So make a buffer and write the whole screen in 1 write rather than call it over and over in a for loop.

Something like this

Code: Select all

#create a buffer to hold a 16bit image of res 128 x 128
screen_buffer = bytearray(2 x 128 x 128)

#put code here to fit the buffer

#set DC pin for command
spi.xfer(RAMWR)

#set DC pin for data
spi.xfer(screen_buffer)
You may find it easier to use numpy arrays instead of bytearray but it works the same way. I just used bytearray because I have been using Micro-python mainly and it doesn't have numpy array so my code is easily ported between Cpython and Micro-Python easily.

You may aslo want to look at the baud rate your setting up on the SPI bus. I have been running then as fast as the MCUs will go which is usually in the 40MHz range for most of the MCUs that I have been these little screens on

Mast3rbug
Posts: 5
Joined: Sun Dec 30, 2018 7:55 pm

Re: 256 colors mode.

Wed Jan 02, 2019 9:56 pm

I already tried something similar, but if I remember, I had an error message that the SPI maximum buffer size is 9K or something like that? So what I tried was to segment SPI send each line instead and this was slow too. Is there a way to increase the SPI buffer size?
Cedric

User avatar
OutoftheBOTS
Posts: 711
Joined: Tue Aug 01, 2017 10:06 am

Re: 256 colors mode.

Thu Jan 03, 2019 4:50 am

Well then you have a few options.

Just write it in block of 4096 this shouldn't slow you down too much as it is still large blocks not individual pixels.

I do believe it maybe possible to change the max size of SPI buffer but not sure on exact linux kernal settings.

After a bit of googling it seems that pigpio can write much larger buffers see http://abyz.me.uk/rpi/pigpio/python.html#spi_write

Return to “Python”