Get raw 24 Bit image data into a Form

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Get raw 24 Bit image data into a Form

Herbert König
Hi,

how do I go about reading a raw RGB 888 (24 bits deep output from
raspiyuv) file into a Form?

Form supports 16 or 32 bits depth.

Cheers,

Herbert

Reply | Threaded
Open this post in threaded view
|

Re: Get raw 24 Bit image data into a Form

timrowledge

On 29-08-2015, at 8:13 AM, Herbert König <[hidden email]> wrote:

> Hi,
>
> how do I go about reading a raw RGB 888 (24 bits deep output from raspiyuv) file into a Form?

Well we need to understand the file format first to decode it and so far as some quick googling tells me the yuv files are completely raw; no header to tell us anything, just a long list of bytes. Since you can control the width and height of the image the camera takes (apparently, though it looks like it gets rounded up to 32 pixels in width and 16 in height?) I guess we can at least in principle assume the w & d for the data. The RGB888 is pretty much the Squeak pixels format for 32bpp anyway so there shouldn’t be too much of a problem.

Basically
take your picture and write to file
open file as binary in Squeak `myFileStream := (FileStream readOnlyFileNamed: ‘my.yuv’) binary`
create a Form of appropriate size & depth  `myForm := Form extent: width@height depth: 32`
read bytes from the filestream and stick them in the form’s bits array. There will be issues of byte-endianness to get right (squeak bitmaps are for some demented reason big-endian and I’d guess the pi YUV files are little-endian) and you’ll have to fill in the top (or bottom, see endianness) byte to set the alpha correctly.

It’ll be something along the lines of checking the sizes match up, reading the data into the form’s bits array and making sure the bits all line up.

Here’s a quick example from my pi2, since it tickled my curiousity

in terminal - `raspiyuv -w 320 -h 208 -rgb -o smple.yuv`
in Squeak
Form extent: 320@208 depth: 32 -> inspect it
in the inspector -
|myfile alpha|
myfile := FileStream readOnlyFileNamed: ‘/home/pi/sample.yuv’.
myfile binary.
bits size * 3 = myfile size ifFalse:[^nil].
alpha := 16rFF<<24.
1 to: bits size do: [ :i| |val|
val := myfile next.
val := val <<8 + myfile next.
val := val <<8 + myfile next.
val := alpha bitOr: val.
bits at: i put: val].
myfile close
self display

I get a pretty decent image displayed. Takes 250 mSec to read in on my pi2 with a cog-spur squeak. A bit over half that is the cost of using the largeinteger ‘alpha’ to set the proper alpha value for each pixel. You *can* leave that out if you’re going to simply do ‘myform display’ since the raw bitblt ignores the alpha. If you are going to be examining the pixels as just rgb values, save the time - I see 120mS in that case.


Obviously once you have the general format sorted it ought to get moved into Form and tidied up as From class>>readRGBFromFileNamed: or similar.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- If you give him a penny for his thoughts, you get change back.



Reply | Threaded
Open this post in threaded view
|

Re: Get raw 24 Bit image data into a Form

Levente Uzonyi-2
It's possible to set the alpha without sacrificing performance.

| extent result |
extent := 320 @ 208.
result := StandardFileStream readOnlyFileNamed: 'sample.yuv' do: [ :file |
  file binary.
  extent area * 3 = file size ifTrue: [
  | word bits form |
  form := Form extent: extent depth: 32.
  bits := form bits.
  word := 16rFF bitShift: 24.
  1 to: bits size do: [ :i |
  word
  digitAt: 3 put: file next;
  digitAt: 2 put: file next;
  digitAt: 1 put: file next.
  bits at: i put: word ].
  form ] ].
result display.

Levente

P.S.: This is usually the point when someone comes up with a pure bitblt
solution providing further significant speedups.

On Sat, 29 Aug 2015, tim Rowledge wrote:

>
> On 29-08-2015, at 8:13 AM, Herbert König <[hidden email]> wrote:
>
>> Hi,
>>
>> how do I go about reading a raw RGB 888 (24 bits deep output from raspiyuv) file into a Form?
>
> Well we need to understand the file format first to decode it and so far as some quick googling tells me the yuv files are completely raw; no header to tell us anything, just a long list of bytes. Since you can control the width and height of the image the camera takes (apparently, though it looks like it gets rounded up to 32 pixels in width and 16 in height?) I guess we can at least in principle assume the w & d for the data. The RGB888 is pretty much the Squeak pixels format for 32bpp anyway so there shouldn’t be too much of a problem.
>
> Basically
> take your picture and write to file
> open file as binary in Squeak `myFileStream := (FileStream readOnlyFileNamed: ‘my.yuv’) binary`
> create a Form of appropriate size & depth  `myForm := Form extent: width@height depth: 32`
> read bytes from the filestream and stick them in the form’s bits array. There will be issues of byte-endianness to get right (squeak bitmaps are for some demented reason big-endian and I’d guess the pi YUV files are little-endian) and you’ll have to fill in the top (or bottom, see endianness) byte to set the alpha correctly.
>
> It’ll be something along the lines of checking the sizes match up, reading the data into the form’s bits array and making sure the bits all line up.
>
> Here’s a quick example from my pi2, since it tickled my curiousity
>
> in terminal - `raspiyuv -w 320 -h 208 -rgb -o smple.yuv`
> in Squeak
> Form extent: 320@208 depth: 32 -> inspect it
> in the inspector -
> |myfile alpha|
> myfile := FileStream readOnlyFileNamed: ‘/home/pi/sample.yuv’.
> myfile binary.
> bits size * 3 = myfile size ifFalse:[^nil].
> alpha := 16rFF<<24.
> 1 to: bits size do: [ :i| |val|
> val := myfile next.
> val := val <<8 + myfile next.
> val := val <<8 + myfile next.
> val := alpha bitOr: val.
> bits at: i put: val].
> myfile close
> self display
>
> I get a pretty decent image displayed. Takes 250 mSec to read in on my pi2 with a cog-spur squeak. A bit over half that is the cost of using the largeinteger ‘alpha’ to set the proper alpha value for each pixel. You *can* leave that out if you’re going to simply do ‘myform display’ since the raw bitblt ignores the alpha. If you are going to be examining the pixels as just rgb values, save the time - I see 120mS in that case.
>
>
> Obviously once you have the general format sorted it ought to get moved into Form and tidied up as From class>>readRGBFromFileNamed: or similar.
>
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Useful random insult:- If you give him a penny for his thoughts, you get change back.
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Get raw 24 Bit image data into a Form

Herbert König
Hi,

this works with image size of 320 @ 208. On my A+ with a size of 1280*832 Tim's version takes 10-12 seconds without displaying the Form. Levente's version takes about 1.5 to 3 seconds. This is already too slow for me.
 
Here:
https://www.raspberrypi.org/documentation/raspbian/applications/camera.md (search for --rgb)
suggests that padding for multiples of 16 may occur.
I thought I would get away with just ignoring the end of the file by changing the test to (extent area * 3 <= file size) as long as x is dividable by 16. But already with 1296@832 which can both be divided by 16 some padding after each line sets in and the resulting image is garbled if that's not taken into account.

I want 1296@972 image size to take advantage of the camera module's binning capability (adding four physical pixels to reduce noise) in my long night exposures.
Finding out the buffer length after which they start padding and accounting for that will not help as it will make the code slower, even if not much. If you happen to know the buffer size of raspiyuv, please tell me so I can play a bit.

Thanks to both for chiming in. I learned something :-))

Herbert


| extent result |
extent := 320 @ 208.
result := StandardFileStream readOnlyFileNamed: 'sample.yuv' do: [ :file |
    file binary.
    extent area * 3 = file size ifTrue: [
        | word bits form |
        form := Form extent: extent depth: 32.
        bits := form bits.
        word := 16rFF bitShift: 24.
        1 to: bits size do: [ :i |
            word
                digitAt: 3 put: file next;
                digitAt: 2 put: file next;
                digitAt: 1 put: file next.
            bits at: i put: word ].
        form ] ].
result display.

Levente

P.S.: This is usually the point when someone comes up with a pure bitblt solution providing further significant speedups.

On Sat, 29 Aug 2015, tim Rowledge wrote:


On 29-08-2015, at 8:13 AM, Herbert König [hidden email] wrote:

Hi,

how do I go about reading a raw RGB 888 (24 bits deep output from raspiyuv) file into a Form?

Well we need to understand the file format first to decode it and so far as some quick googling tells me the yuv files are completely raw; no header to tell us anything, just a long list of bytes. Since you can control the width and height of the image the camera takes (apparently, though it looks like it gets rounded up to 32 pixels in width and 16 in height?) I guess we can at least in principle assume the w & d for the data. The RGB888 is pretty much the Squeak pixels format for 32bpp anyway so there shouldn’t be too much of a problem.

Basically
take your picture and write to file
open file as binary in Squeak `myFileStream := (FileStream readOnlyFileNamed: ‘my.yuv’) binary`
create a Form of appropriate size & depth  `myForm := Form extent: width@height depth: 32`
read bytes from the filestream and stick them in the form’s bits array. There will be issues of byte-endianness to get right (squeak bitmaps are for some demented reason big-endian and I’d guess the pi YUV files are little-endian) and you’ll have to fill in the top (or bottom, see endianness) byte to set the alpha correctly.

It’ll be something along the lines of checking the sizes match up, reading the data into the form’s bits array and making sure the bits all line up.

Here’s a quick example from my pi2, since it tickled my curiousity

in terminal - `raspiyuv -w 320 -h 208 -rgb -o smple.yuv`
in Squeak
Form extent: 320@208 depth: 32 -> inspect it
in the inspector -
|myfile alpha|
myfile := FileStream readOnlyFileNamed: ‘/home/pi/sample.yuv’.
myfile binary.
bits size * 3 = myfile size ifFalse:[^nil].
alpha := 16rFF<<24.
1 to: bits size do: [ :i| |val|
val := myfile next.
val := val <<8 + myfile next.
val := val <<8 + myfile next.
val := alpha bitOr: val.
bits at: i put: val].
myfile close
self display

I get a pretty decent image displayed. Takes 250 mSec to read in on my pi2 with a cog-spur squeak. A bit over half that is the cost of using the largeinteger ‘alpha’ to set the proper alpha value for each pixel. You *can* leave that out if you’re going to simply do ‘myform display’ since the raw bitblt ignores the alpha. If you are going to be examining the pixels as just rgb values, save the time - I see 120mS in that case.


Obviously once you have the general format sorted it ought to get moved into Form and tidied up as From class>>readRGBFromFileNamed: or similar.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- If you give him a penny for his thoughts, you get change back.







    



Reply | Threaded
Open this post in threaded view
|

Re: Get raw 24 Bit image data into a Form

Levente Uzonyi-2
Hi Herbert,

Wouldn't it be better to use raspistill instead of raspiyuv, and generate
a jpg or png file directly?

Levente

On Sun, 30 Aug 2015, Herbert König wrote:

> Hi,
>
> this works with image size of 320 @ 208. On my A+ with a size of 1280*832 Tim's version takes 10-12 seconds without displaying the Form. Levente's
> version takes about 1.5 to 3 seconds. This is already too slow for me.
>  
> Here:
> https://www.raspberrypi.org/documentation/raspbian/applications/camera.md (search for --rgb)
> suggests that padding for multiples of 16 may occur.
> I thought I would get away with just ignoring the end of the file by changing the test to (extent area * 3 <= file size) as long as x is dividable
> by 16. But already with 1296@832 which can both be divided by 16 some padding after each line sets in and the resulting image is garbled if that's
> not taken into account.
>
> I want 1296@972 image size to take advantage of the camera module's binning capability (adding four physical pixels to reduce noise) in my long
> night exposures.
> Finding out the buffer length after which they start padding and accounting for that will not help as it will make the code slower, even if not
> much. If you happen to know the buffer size of raspiyuv, please tell me so I can play a bit.
>
> Thanks to both for chiming in. I learned something :-))
>
> Herbert
>
>
>       | extent result |
>       extent := 320 @ 208.
>       result := StandardFileStream readOnlyFileNamed: 'sample.yuv' do: [ :file |
>           file binary.
>           extent area * 3 = file size ifTrue: [
>               | word bits form |
>               form := Form extent: extent depth: 32.
>               bits := form bits.
>               word := 16rFF bitShift: 24.
>               1 to: bits size do: [ :i |
>                   word
>                       digitAt: 3 put: file next;
>                       digitAt: 2 put: file next;
>                       digitAt: 1 put: file next.
>                   bits at: i put: word ].
>               form ] ].
>       result display.
>
>       Levente
>
>       P.S.: This is usually the point when someone comes up with a pure bitblt solution providing further significant speedups.
>
>       On Sat, 29 Aug 2015, tim Rowledge wrote:
>
>
>             On 29-08-2015, at 8:13 AM, Herbert König <[hidden email]> wrote:
>
>                   Hi,
>
>                   how do I go about reading a raw RGB 888 (24 bits deep output from raspiyuv) file into a Form?
>
>
>             Well we need to understand the file format first to decode it and so far as some quick googling tells me the yuv files are
>             completely raw; no header to tell us anything, just a long list of bytes. Since you can control the width and height of
>             the image the camera takes (apparently, though it looks like it gets rounded up to 32 pixels in width and 16 in height?) I
>             guess we can at least in principle assume the w & d for the data. The RGB888 is pretty much the Squeak pixels format for
>             32bpp anyway so there shouldn’t be too much of a problem.
>
>             Basically
>             take your picture and write to file
>             open file as binary in Squeak `myFileStream := (FileStream readOnlyFileNamed: ‘my.yuv’) binary`
>             create a Form of appropriate size & depth  `myForm := Form extent: width@height depth: 32`
>             read bytes from the filestream and stick them in the form’s bits array. There will be issues of byte-endianness to get
>             right (squeak bitmaps are for some demented reason big-endian and I’d guess the pi YUV files are little-endian) and you’ll
>             have to fill in the top (or bottom, see endianness) byte to set the alpha correctly.
>
>             It’ll be something along the lines of checking the sizes match up, reading the data into the form’s bits array and making
>             sure the bits all line up.
>
>             Here’s a quick example from my pi2, since it tickled my curiousity
>
>             in terminal - `raspiyuv -w 320 -h 208 -rgb -o smple.yuv`
>             in Squeak
>             Form extent: 320@208 depth: 32 -> inspect it
>             in the inspector -
>             |myfile alpha|
>             myfile := FileStream readOnlyFileNamed: ‘/home/pi/sample.yuv’.
>             myfile binary.
>             bits size * 3 = myfile size ifFalse:[^nil].
>             alpha := 16rFF<<24.
>             1 to: bits size do: [ :i| |val|
>             val := myfile next.
>             val := val <<8 + myfile next.
>             val := val <<8 + myfile next.
>             val := alpha bitOr: val.
>             bits at: i put: val].
>             myfile close
>             self display
>
>             I get a pretty decent image displayed. Takes 250 mSec to read in on my pi2 with a cog-spur squeak. A bit over half that is
>             the cost of using the largeinteger ‘alpha’ to set the proper alpha value for each pixel. You *can* leave that out if
>             you’re going to simply do ‘myform display’ since the raw bitblt ignores the alpha. If you are going to be examining the
>             pixels as just rgb values, save the time - I see 120mS in that case.
>
>
>             Obviously once you have the general format sorted it ought to get moved into Form and tidied up as From
>             class>>readRGBFromFileNamed: or similar.
>
>
>             tim
>             --
>             tim Rowledge; [hidden email]; http://www.rowledge.org/tim
>             Useful random insult:- If you give him a penny for his thoughts, you get change back.
>
>
>
>
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Get raw 24 Bit image data into a Form

Herbert König
Hi Levente,

I do that. I asked here because I found a bug in bmp saving of Raspistill.
http://www.raspberrypi.org/forums/viewtopic.php?f=43&t=119050
6by9 suggested to use raspiyuv and I wanted to at least verify that raspiyuv doesn't have this bug. It doesn't.

I can live with the bug because first thing I compute the difference between two consecutive images via BitBlt. This makes the problem vanish.

On that I do a very specialized motion detection to identify cats using the garden as a toilet :-)). I only noticed the problem because I save the photos creating an alarm. 

Cheers,

Herbert


Am 30.08.2015 um 19:35 schrieb Levente Uzonyi:
Hi Herbert,

Wouldn't it be better to use raspistill instead of raspiyuv, and generate a jpg or png file directly?

Levente

On Sun, 30 Aug 2015, Herbert König wrote:

Hi,

this works with image size of 320 @ 208. On my A+ with a size of 1280*832 Tim's version takes 10-12 seconds without displaying the Form. Levente's
version takes about 1.5 to 3 seconds. This is already too slow for me.
 
Here:
https://www.raspberrypi.org/documentation/raspbian/applications/camera.md (search for --rgb)
suggests that padding for multiples of 16 may occur.
I thought I would get away with just ignoring the end of the file by changing the test to (extent area * 3 <= file size) as long as x is dividable
by 16. But already with 1296@832 which can both be divided by 16 some padding after each line sets in and the resulting image is garbled if that's
not taken into account.

I want 1296@972 image size to take advantage of the camera module's binning capability (adding four physical pixels to reduce noise) in my long
night exposures.
Finding out the buffer length after which they start padding and accounting for that will not help as it will make the code slower, even if not
much. If you happen to know the buffer size of raspiyuv, please tell me so I can play a bit.

Thanks to both for chiming in. I learned something :-))

Herbert


      | extent result |
      extent := 320 @ 208.
      result := StandardFileStream readOnlyFileNamed: 'sample.yuv' do: [ :file |
          file binary.
          extent area * 3 = file size ifTrue: [
              | word bits form |
              form := Form extent: extent depth: 32.
              bits := form bits.
              word := 16rFF bitShift: 24.
              1 to: bits size do: [ :i |
                  word
                      digitAt: 3 put: file next;
                      digitAt: 2 put: file next;
                      digitAt: 1 put: file next.
                  bits at: i put: word ].
              form ] ].
      result display.

      Levente

      P.S.: This is usually the point when someone comes up with a pure bitblt solution providing further significant speedups.

      On Sat, 29 Aug 2015, tim Rowledge wrote:


            On 29-08-2015, at 8:13 AM, Herbert König [hidden email] wrote:

                  Hi,

                  how do I go about reading a raw RGB 888 (24 bits deep output from raspiyuv) file into a Form?


            Well we need to understand the file format first to decode it and so far as some quick googling tells me the yuv files are
            completely raw; no header to tell us anything, just a long list of bytes. Since you can control the width and height of
            the image the camera takes (apparently, though it looks like it gets rounded up to 32 pixels in width and 16 in height?) I
            guess we can at least in principle assume the w & d for the data. The RGB888 is pretty much the Squeak pixels format for
            32bpp anyway so there shouldn’t be too much of a problem.

            Basically
            take your picture and write to file
            open file as binary in Squeak `myFileStream := (FileStream readOnlyFileNamed: ‘my.yuv’) binary`
            create a Form of appropriate size & depth  `myForm := Form extent: width@height depth: 32`
            read bytes from the filestream and stick them in the form’s bits array. There will be issues of byte-endianness to get
            right (squeak bitmaps are for some demented reason big-endian and I’d guess the pi YUV files are little-endian) and you’ll
            have to fill in the top (or bottom, see endianness) byte to set the alpha correctly.

            It’ll be something along the lines of checking the sizes match up, reading the data into the form’s bits array and making
            sure the bits all line up.

            Here’s a quick example from my pi2, since it tickled my curiousity

            in terminal - `raspiyuv -w 320 -h 208 -rgb -o smple.yuv`
            in Squeak
            Form extent: 320@208 depth: 32 -> inspect it
            in the inspector -
            |myfile alpha|
            myfile := FileStream readOnlyFileNamed: ‘/home/pi/sample.yuv’.
            myfile binary.
            bits size * 3 = myfile size ifFalse:[^nil].
            alpha := 16rFF<<24.
            1 to: bits size do: [ :i| |val|
            val := myfile next.
            val := val <<8 + myfile next.
            val := val <<8 + myfile next.
            val := alpha bitOr: val.
            bits at: i put: val].
            myfile close
            self display

            I get a pretty decent image displayed. Takes 250 mSec to read in on my pi2 with a cog-spur squeak. A bit over half that is
            the cost of using the largeinteger ‘alpha’ to set the proper alpha value for each pixel. You *can* leave that out if
            you’re going to simply do ‘myform display’ since the raw bitblt ignores the alpha. If you are going to be examining the
            pixels as just rgb values, save the time - I see 120mS in that case.


            Obviously once you have the general format sorted it ought to get moved into Form and tidied up as From
            class>>readRGBFromFileNamed: or similar.


            tim
            --
            tim Rowledge; [hidden email]; http://www.rowledge.org/tim
            Useful random insult:- If you give him a penny for his thoughts, you get change back.












    



Reply | Threaded
Open this post in threaded view
|

Re: Get raw 24 Bit image data into a Form

timrowledge
In reply to this post by Herbert König

On 30-08-2015, at 8:19 AM, Herbert König <[hidden email]> wrote:
> this works with image size of 320 @ 208. On my A+ with a size of 1280*832 Tim's version takes 10-12 seconds without displaying the Form. Levente's version takes about 1.5 to 3 seconds. This is already too slow for me.
>  

You’re not going to get hugely faster with any code that involves a cycle of writing a file from raspiyuv and then reading that file. The FS interface on the Pi simply isn’t all that quick.

What you might be able to do is cut out the middle… err, fileman, and get access to the camera buffer directly. I have no idea exactly how the hardware works but for the Scratch camera UI we go via v4linux2 and mmap stuff. Maybe it’s possible to even side-step v4l2 ?

As an example on my Pi2 -
sudo modprobe bcm2835-v4l2
- to get the video4linux2 driver loaded
|frameForm|
(CameraPlugin cameraName: 1) ifNotNil: [|n frameExtent t|
        (CameraPlugin openCamera: 1 width: 1296 height: 832) ifNotNil: [
                                frameForm  :=  Form extent: (CameraPlugin frameExtent: 1) depth: 32.
                                frameExtent  :=  frameForm extent.
                                Delay waitMSecs: 400].
        t := Time millisecondsToRun: [n  :=  CameraPlugin getFrameForCamera: 1 into: frameForm bits].
        CameraPlugin closeCamera: 1.
        n = 0 ifTrue: [^ false].  
        frameForm display.
        t]
= 18mSec
So, much faster it seems. The CameraPlugin code is available from the squeakvm.org svn tree easily enough and the Smalltalk code is easily sendable. The plugin itself is included in any recent Pi VM.
Even if the A+ takes 3x longer it seems potentially useful to me.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Never write software that anthropomorphizes the machine. They hate that.



Reply | Threaded
Open this post in threaded view
|

Re: Get raw 24 Bit image data into a Form

Yoshiki Ohshima-3
In reply to this post by Levente Uzonyi-2
> P.S.: This is usually the point when someone comes up with a pure bitblt
> solution providing further significant speedups.

Yeah, kind of the topic I like^^;

The following is not tested but I'm putting this out just to
illustrates the idea:

------------------------------------------------------------
f := Form extent: 1296@972 depth: 32.
"f will contain the resulting 32-bit form."

hDest := Form new hackBits: f bits.
"hDest is a view on the bits of f that treats the bits as 4 pixel wide
8 bit form."

alpha := Form extent: 1@972 depth: 8.
alpha fillColor: (Bitmap with: 16rFFFFFFFF).
"A one-pixel wide narrow bitmap of white.  You actually don't need
this and do the fill with bounding box in below, but just to show
something."

orig := ByteArray new: 300.
"Let us say this is the original byte array."
hOrig := Form extent: 3@(972*1296) depth: 8.
hOrig bits copyFromByteArray: orig.
"hOrig is 3-pixel wide form."

alpha displayOn: hDest at: 0@0.
hOrig displayOn: hDest at: 1@0.
--------------------------------------------------------------

--
-- Yoshiki

Reply | Threaded
Open this post in threaded view
|

Re: Get raw 24 Bit image data into a Form

Herbert König
In reply to this post by timrowledge
Am 30.08.2015 um 20:04 schrieb tim Rowledge:

>
> As an example on my Pi2 -
> sudo modprobe bcm2835-v4l2
> - to get the video4linux2 driver loaded
> |frameForm|
> (CameraPlugin cameraName: 1) ifNotNil: [|n frameExtent t|
> (CameraPlugin openCamera: 1 width: 1296 height: 832) ifNotNil: [
> frameForm  :=  Form extent: (CameraPlugin frameExtent: 1) depth: 32.
> frameExtent  :=  frameForm extent.
> Delay waitMSecs: 400].
> t := Time millisecondsToRun: [n  :=  CameraPlugin getFrameForCamera: 1 into: frameForm bits].
> CameraPlugin closeCamera: 1.
> n = 0 ifTrue: [^ false].
> frameForm display.
> t]
I tucked that away. It seems very promising if I want to do other things
with the camera like triggering on external sensors. As stated earlier
in my current application I can live with bmp import and the camera's
problems with bmp. I just wanted to make sure my camera board didn't
degrade.

Thanks,

Herbert