Video data compression for serial link

[Dave Platt]

In article <012b41da-d6f5-4e97-91f9-c7f4a07ca071@googlegroups.com>,
Rick C <gnuarm.deletethisbit@gmail.com> wrote:

Only to the pedantic. While what you say is correct, it's not important. Virtually everyone refers to an async
serial port as RS-232 even when the voltage levels are something different.

Yes, that's probably true.

In many cases, it works, and the hardware survives.

In other cases, e.g. where somebody connects a real RS-232 port
directly to a micro serial port that uses 3.3-volt CMOS voltage levels
and non-inverted polarity, it doesn't work (for several reasons) and
there's often a quiet PHUT and a small leakage of magic blue smoke.

As Durano said to Londo Mollari, "The details are everything."

 

[david eather]

On 9/05/2019 7:22 am, Martin Brown wrote:

On 08/05/2019 21:57, bitrex wrote:
On 4/30/19 11:45 PM, david eather wrote:


On 29/04/2019 5:11 am, bitrex wrote:
I have a client who needs to send 10 bit greyscale video data
over a serial link from a PC to an ARM Cortex uP. Right now just
using a KISS implementation, constant-overhead-byte-stuffing
protocol, two bytes per value, with a simple CRC-type checksum
appended to each scanline the link needs to be around 384kbps to
support the amount of
data required to transmit.

the hardware is on-paper capable of that but in practice the lash up
is unstable, there's a bottleneck somewhere, most likely on the PC
side as it's not a "real" hardware serial port but virtualized via
USB and it has to go thru all the multiple layers of abstraction
from the application until it finally gets spit out; the application
code isn't even complied it's from a scripting language.

Using compiled C/C++ that can do system calls directly will probably
help but I'm also looking for ways to compress the serial stream
bandwidth. For 10 bit greyscale data I was thinking that just
something like u-law or A-law encoding could significantly reduce
the bandwidth without resorting to more compute-intensive bespoke
video compression algorithms. Primary requirement is that the link
needs to be very fault-tolerant and reliable for long term operation

you want a look up table like this. It might not solve all your
problems but at least it will halve the required bit rate which
should improve things. Note the darkness details (up to 63) are not
compressed at all.


Hi David, sorry for the delay in my reply - if you're around can you
tell me how you came up with that table? And/or how to adapt to a
different bit depth?

A formula that will work to give the same transform approximately is:

x = int( 0.5 + 0.998*y*(4096+y)/(4096+16*y))

maps 0<y<1024 onto 0<x<255 linearly at first and then sort of log.

That looks about right. At the bottom end The steps are much smaller
than 1 bit so you might as well make them 1 bit (since there is no loss
or resolution) until the steps are larger - that is why the first 63
entries were 0,1,2,3 etc until 63.

Did it behave OK when you halved the datarate?

 

On Friday, 10 May 2019 05:30:29 UTC+1, david eather wrote:

Isn't the video output from digital tv cameras already compressed
by "gamma correction" which applies a power law function?

John

 

[Martin Brown]

On 10/05/2019 12:30, jrwalliker@gmail.com wrote:

On Friday, 10 May 2019 05:30:29 UTC+1, david eather wrote:

Isn't the video output from digital tv cameras already compressed
by "gamma correction" which applies a power law function?

It might or might not be depending on the device. It is quite common for
some industrial ones to return the raw data frame to the computer.

Even so if you want to squish the image data into a smaller number of
bits then some sort of non-linear fast lookup table is the way to do it.

Usually (but not always) you want to preserve details in the shadows.

--
Regards,
Martin Brown

 

On Tue, 14 May 2019 11:17:03 +0100, Martin Brown
<'''newspam'''@nezumi.demon.co.uk> wrote:

On 10/05/2019 12:30, jrwalliker@gmail.com wrote:
On Friday, 10 May 2019 05:30:29 UTC+1, david eather wrote:

Isn't the video output from digital tv cameras already compressed
by "gamma correction" which applies a power law function?

It might or might not be depending on the device. It is quite common for
some industrial ones to return the raw data frame to the computer.

The available line speed was 384 kbit/s so assuming 10 bits/s and no
overhead, that is 38 kpixels/s. Even a VGA frame 640x480 = 300
kpixels, so it takes nearly 10 s to transfer a single frame. Not
really live video. That link speed would be capable of supporting
160x200 pixels once a second. assuming asynchronous transfer
(start/stop bits).

Even so if you want to squish the image data into a smaller number of
bits then some sort of non-linear fast lookup table is the way to do it.

Usually (but not always) you want to preserve details in the shadows.

 

[Martin Brown]

On 14/05/2019 12:51, upsidedown@downunder.com wrote:

On Tue, 14 May 2019 11:17:03 +0100, Martin Brown
'''newspam'''@nezumi.demon.co.uk> wrote:

On 10/05/2019 12:30, jrwalliker@gmail.com wrote:
On Friday, 10 May 2019 05:30:29 UTC+1, david eather wrote:

Isn't the video output from digital tv cameras already compressed
by "gamma correction" which applies a power law function?

It might or might not be depending on the device. It is quite common for
some industrial ones to return the raw data frame to the computer.

The available line speed was 384 kbit/s so assuming 10 bits/s and no
overhead, that is 38 kpixels/s. Even a VGA frame 640x480 = 300
kpixels, so it takes nearly 10 s to transfer a single frame. Not
really live video. That link speed would be capable of supporting
160x200 pixels once a second. assuming asynchronous transfer
(start/stop bits).

I'm generally more looking at USB3 and low light fast Mpixel industrial
cameras which have become very popular for amateur/pro astronomy. It is
generally reckoned that at least 3 amateurs worldwide have Jupiter
imaged in video continuously whenever it is available to see.

Turns out SL9 type impacts with Jupiter are a bit more common than we
once thought. Someone catches and incident every couple of years. Last
lunar eclipse someone even caught a meteorite striking the moon!

Lucky imaging has revolutionised high resolution ground based optical
astronomy - bringing it well within reach of advanced amateurs.


--
Regards,
Martin Brown