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 at 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 at 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 
>> <herbertkoenig at gmx.net> 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 at 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 at 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; tim at rowledge.org; http://www.rowledge.org/tim
>>             Useful random insult:- If you give him a penny for his 
>> thoughts, you get change back.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150830/06a490e2/attachment.htm