Re: Raspberry Pi camera

[David Vine via Tech-talk <tech-talk@aps.anl.gov>]

Hi Vishnu,

here's a script I used to control the Pi noir using Python. No EPICS integration but this should get you going for acquisition.

Best,

David

On Mon, Dec 23, 2019 at 10:00 AM <tech-talk-request@aps.anl.gov> wrote:

Send Tech-talk mailing list submissions to
        tech-talk@aps.anl.gov

To subscribe or unsubscribe via the World Wide Web, visit
        https://mailman.aps.anl.gov/mailman/listinfo/tech-talk
or, via email, send a message with subject or body 'help' to
        tech-talk-request@aps.anl.gov

You can reach the person managing the list at
        tech-talk-owner@aps.anl.gov

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Tech-talk digest..."
Today's Topics:

   1. Ring buffer overflow (Abdalla Ahmad)
   2. Raspberry Pi camera (Vishnu Patel)
   3. Re: Ring buffer overflow (Mark Rivers)



---------- Forwarded message ----------
From: Abdalla Ahmad <Abdalla.Ahmad@sesame.org.jo>
To: "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Cc: 
Bcc: 
Date: Mon, 23 Dec 2019 06:44:11 +0000
Subject: Ring buffer overflow

Hi

 

In an asyn port driver, I get the following message on the IOC shell

 

scanOnce: Ring buffer overflow

 

For now I rarely get this message and the IOC is working fine, but what is the reason behind it? Could the record’s IO is taking more time than the scan time?

 

Best Regards,

Abdalla.

---------- Forwarded message ----------
From: Vishnu Patel <patel.vishnu@hotmail.com>
To: "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Cc: 
Bcc: 
Date: Mon, 23 Dec 2019 08:58:34 +0000
Subject: Raspberry Pi camera

Hello,

    If anyone worked on the PI Camera on the raspberry PI, i need help to get camera acquisition (archiving) and display on it.

Thanks

Vishnu

---------- Forwarded message ----------
From: Mark Rivers <rivers@cars.uchicago.edu>
To: Abdalla Ahmad <Abdalla.Ahmad@sesame.org.jo>
Cc: tech-talk <tech-talk@aps.anl.gov>
Bcc: 
Date: Mon, 23 Dec 2019 13:45:32 +0000
Subject: Re: Ring buffer overflow
Hi Abdalla,


> scanOnce: Ring buffer overflow

?> For now I rarely get this message and the IOC is working fine, but what is the reason behind it?
> Could the record's IO is taking more time than the scan time?


That message is coming from dbScan.c in EPICS base.  It usually means that you have records with SCAN=I/O Intr that are processing very fast, i.e. lots of callbacks from your asyn driver.


There is a callback queue in EPICS base that is overflowing.   Since the problem is only happening every once in a while you can probably eliminate the message by increasing the size of the queue.  The queue size defaults to 2000.  You can check the current size with callbackShowQueue:


epics> callbackQueueShow
PRIORITY  HIGH-WATER MARK  ITEMS IN Q  Q SIZE  % USED  Q OVERFLOWS
   cbLow                7           0    2000     0.0            0
cbMedium                0           0    2000     0.0            0
  cbHigh                0           0    2000     0.0            0

You can increase the size to 5000 by adding this command to your IOC startup script before iocInit:

callbackSetQueueSize(5000)


Mark




________________________________
From: Tech-talk <tech-talk-bounces@aps.anl.gov> on behalf of Abdalla Ahmad via Tech-talk <tech-talk@aps.anl.gov>
Sent: Monday, December 23, 2019 12:44 AM
To: tech-talk@aps.anl.gov
Subject: Ring buffer overflow


Hi



In an asyn port driver, I get the following message on the IOC shell



scanOnce: Ring buffer overflow



For now I rarely get this message and the IOC is working fine, but what is the reason behind it? Could the record's IO is taking more time than the scan time?



Best Regards,

Abdalla.

_______________________________________________
Tech-talk mailing list Tech-talk@aps.anl.gov
https://mailman.aps.anl.gov/mailman/listinfo/tech-talk

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this email. Please notify the sender immediately by email if you have received this email by mistake and delete this email from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited
from __future__ import (
    unicode_literals,
    absolute_import,
    print_function,
    division,
    )


from PIL import Image
import io
import time
import numpy as np
from numpy.lib.stride_tricks import as_strided
import ipdb

stream = io.BytesIO()
#with picamera.PiCamera() as camera:
#    # Let the camera warm up for a couple of seconds
#    time.sleep(2)
#    # Capture the image, including the Bayer data
#    camera.capture(stream, format='jpeg', bayer=True)
#    ver = {
#        'RP_ov5647': 1,
#        'RP_imx219': 2,
#        }[camera.exif_tags['IFD0.Model']]
#byteImage = Image.open('./img_000001.jpg').tobytes()
for i in range(38000):
    print(i)
    del stream
    with open('/home/david/pinoir/42W/img_{:06d}.bs'.format(i), 'rb') as f:
        stream = io.BytesIO(f.read())
    ver = 2

    # Extract the raw Bayer data from the end of the stream, check the
    # header and strip if off before converting the data into a numpy array

    offset = {
        1: 6404096,
        2: 10270208,
        }[ver]
    data = stream.getvalue()[-offset:]
    assert data[:4] == b'BRCM'
    #data = data[32768:]
    #data = np.fromstring(data, dtype=np.uint8)
    data = np.frombuffer(data[32768:], dtype=np.uint8)

    # For the V1 module, the data consists of 1952 rows of 3264 bytes of data.
    # The last 8 rows of data are unused (they only exist because the maximum
    # resolution of 1944 rows is rounded up to the nearest 16).
    #
    # For the V2 module, the data consists of 2480 rows of 4128 bytes of data.
    # There's actually 2464 rows of data, but the sensor's raw size is 2466
    # rows, rounded up to the nearest multiple of 16: 2480.
    #
    # Likewise, the last few bytes of each row are unused (why?). Here we
    # reshape the data and strip off the unused bytes.

    reshape, crop = {
        1: ((1952, 3264), (1944, 3240)),
        2: ((2480, 4128), (2464, 4100)),
        }[ver]
    data = data.reshape(reshape)[:crop[0], :crop[1]]

    # Horizontally, each row consists of 10-bit values. Every four bytes are
    # the high 8-bits of four values, and the 5th byte contains the packed low
    # 2-bits of the preceding four values. In other words, the bits of the
    # values A, B, C, D and arranged like so:
    #
    #  byte 1   byte 2   byte 3   byte 4   byte 5
    # AAAAAAAA BBBBBBBB CCCCCCCC DDDDDDDD AABBCCDD
    #
    # Here, we convert our data into a 16-bit array, shift all values left by
    # 2-bits and unpack the low-order bits from every 5th byte in each row,
    # then remove the columns containing the packed bits

    data = data.astype(np.uint16) << 2
    for byte in range(4):
        data[:, byte::5] |= ((data[:, 4::5] >> ((4 - byte) * 2)) & 0b11)
    data = np.delete(data, np.s_[4::5], 1)

    # Now to split the data up into its red, green, and blue components. The
    # Bayer pattern of the OV5647 sensor is BGGR. In other words the first
    # row contains alternating green/blue elements, the second row contains
    # alternating red/green elements, and so on as illustrated below:
    #
    # GBGBGBGBGBGBGB
    # RGRGRGRGRGRGRG
    # GBGBGBGBGBGBGB
    # RGRGRGRGRGRGRG
    #
    # Please note that if you use vflip or hflip to change the orientation
    # of the capture, you must flip the Bayer pattern accordingly

    rgb = np.zeros(data.shape + (3,), dtype=data.dtype)
    rgb[1::2, 0::2, 0] = data[1::2, 0::2] # Red
    rgb[0::2, 0::2, 1] = data[0::2, 0::2] # Green
    rgb[1::2, 1::2, 1] = data[1::2, 1::2] # Green
    rgb[0::2, 1::2, 2] = data[0::2, 1::2] # Blue

    # At this point we now have the raw Bayer data with the correct values
    # and colors but the data still requires de-mosaicing and
    # post-processing. If you wish to do this yourself, end the script here!
    #
    # Below we present a fairly naive de-mosaic method that simply
    # calculates the weighted average of a pixel based on the pixels
    # surrounding it. The weighting is provided by a byte representation of
    # the Bayer filter which we construct first:

    bayer = np.zeros(rgb.shape, dtype=np.uint8)
    bayer[1::2, 0::2, 0] = 1 # Red
    bayer[0::2, 0::2, 1] = 1 # Green
    bayer[1::2, 1::2, 1] = 1 # Green
    bayer[0::2, 1::2, 2] = 1 # Blue

    # Allocate an array to hold our output with the same shape as the input
    # data. After this we define the size of window that will be used to
    # calculate each weighted average (3x3). Then we pad out the rgb and
    # bayer arrays, adding blank pixels at their edges to compensate for the
    # size of the window when calculating averages for edge pixels.

    output = np.empty(rgb.shape, dtype=rgb.dtype)
    window = (3, 3)
    borders = (window[0] - 1, window[1] - 1)
    border = (borders[0] // 2, borders[1] // 2)

    rgb = np.pad(rgb, [
        (border[0], border[0]),
        (border[1], border[1]),
        (0, 0),
        ], 'constant')
    bayer = np.pad(bayer, [
        (border[0], border[0]),
        (border[1], border[1]),
        (0, 0),
        ], 'constant')

    # For each plane in the RGB data, we use a nifty numpy trick
    # (as_strided) to construct a view over the plane of 3x3 matrices. We do
    # the same for the bayer array, then use Einstein summation on each
    # (np.sum is simpler, but copies the data so it's slower), and divide
    # the results to get our weighted average:

    for plane in range(3):
        p = rgb[..., plane]
        b = bayer[..., plane]
        pview = as_strided(p, shape=(
            p.shape[0] - borders[0],
            p.shape[1] - borders[1]) + window, strides=p.strides * 2)
        bview = as_strided(b, shape=(
            b.shape[0] - borders[0],
            b.shape[1] - borders[1]) + window, strides=b.strides * 2)
        psum = np.einsum('ijkl->ij', pview)
        bsum = np.einsum('ijkl->ij', bview)
        output[..., plane] = psum // bsum

    # At this point output should contain a reasonably "normal" looking
    # image, although it still won't look as good as the camera's normal
    # output (as it lacks vignette compensation, AWB, etc).
    #
    # If you want to view this in most packages (like GIMP) you'll need to
    # convert it to 8-bit RGB data. The simplest way to do this is by
    # right-shifting everything by 2-bits (yes, this makes all that
    # unpacking work at the start rather redundant...)

    #output = (output >> 2).astype(np.uint8)
    #with open('image.data', 'wb') as f:
    #    output.tofile(f)

    if i == 0:
        avimg = np.sum(output, axis=2)
    else:
        avimg += np.sum(output, axis=2)

    np.save('/home/david/lang/python/nanodet/avimg.npy', avimg)