<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Levente,<br>
<br>
I do that. I asked here because I found a bug in bmp saving of
Raspistill.<br>
<pre wrap=""><a class="moz-txt-link-freetext" href="http://www.raspberrypi.org/forums/viewtopic.php?f=43&t=119050">http://www.raspberrypi.org/forums/viewtopic.php?f=43&t=119050</a>
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
</pre>
<br>
<br>
<div class="moz-cite-prefix">Am 30.08.2015 um 19:35 schrieb Levente
Uzonyi:<br>
</div>
<blockquote
cite="mid:alpine.DEB.2.02.1508301934340.11724@login03.caesar.elte.hu"
type="cite">Hi Herbert,
<br>
<br>
Wouldn't it be better to use raspistill instead of raspiyuv, and
generate a jpg or png file directly?
<br>
<br>
Levente
<br>
<br>
On Sun, 30 Aug 2015, Herbert König wrote:
<br>
<br>
<blockquote type="cite">Hi,
<br>
<br>
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
<br>
version takes about 1.5 to 3 seconds. This is already too slow
for me.
<br>
<br>
Here:
<br>
<a class="moz-txt-link-freetext" href="https://www.raspberrypi.org/documentation/raspbian/applications/camera.md">https://www.raspberrypi.org/documentation/raspbian/applications/camera.md</a>
(search for --rgb)
<br>
suggests that padding for multiples of 16 may occur.
<br>
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
<br>
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
<br>
not taken into account.
<br>
<br>
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
<br>
night exposures.
<br>
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
<br>
much. If you happen to know the buffer size of raspiyuv, please
tell me so I can play a bit.
<br>
<br>
Thanks to both for chiming in. I learned something :-))
<br>
<br>
Herbert
<br>
<br>
<br>
| extent result |
<br>
extent := 320 @ 208.
<br>
result := StandardFileStream readOnlyFileNamed:
'sample.yuv' do: [ :file |
<br>
file binary.
<br>
extent area * 3 = file size ifTrue: [
<br>
| word bits form |
<br>
form := Form extent: extent depth: 32.
<br>
bits := form bits.
<br>
word := 16rFF bitShift: 24.
<br>
1 to: bits size do: [ :i |
<br>
word
<br>
digitAt: 3 put: file next;
<br>
digitAt: 2 put: file next;
<br>
digitAt: 1 put: file next.
<br>
bits at: i put: word ].
<br>
form ] ].
<br>
result display.
<br>
<br>
Levente
<br>
<br>
P.S.: This is usually the point when someone comes up with
a pure bitblt solution providing further significant speedups.
<br>
<br>
On Sat, 29 Aug 2015, tim Rowledge wrote:
<br>
<br>
<br>
On 29-08-2015, at 8:13 AM, Herbert König
<a class="moz-txt-link-rfc2396E" href="mailto:herbertkoenig@gmx.net"><herbertkoenig@gmx.net></a> wrote:
<br>
<br>
Hi,
<br>
<br>
how do I go about reading a raw RGB 888 (24
bits deep output from raspiyuv) file into a Form?
<br>
<br>
<br>
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
<br>
completely raw; no header to tell us anything, just
a long list of bytes. Since you can control the width and height
of
<br>
the image the camera takes (apparently, though it
looks like it gets rounded up to 32 pixels in width and 16 in
height?) I
<br>
guess we can at least in principle assume the w
& d for the data. The RGB888 is pretty much the Squeak
pixels format for
<br>
32bpp anyway so there shouldn’t be too much of a
problem.
<br>
<br>
Basically
<br>
take your picture and write to file
<br>
open file as binary in Squeak `myFileStream :=
(FileStream readOnlyFileNamed: ‘my.yuv’) binary`
<br>
create a Form of appropriate size & depth
`myForm := Form extent: width@height depth: 32`
<br>
read bytes from the filestream and stick them in the
form’s bits array. There will be issues of byte-endianness to
get
<br>
right (squeak bitmaps are for some demented reason
big-endian and I’d guess the pi YUV files are little-endian) and
you’ll
<br>
have to fill in the top (or bottom, see endianness)
byte to set the alpha correctly.
<br>
<br>
It’ll be something along the lines of checking the
sizes match up, reading the data into the form’s bits array and
making
<br>
sure the bits all line up.
<br>
<br>
Here’s a quick example from my pi2, since it tickled
my curiousity
<br>
<br>
in terminal - `raspiyuv -w 320 -h 208 -rgb -o
smple.yuv`
<br>
in Squeak
<br>
Form extent: 320@208 depth: 32 -> inspect it
<br>
in the inspector -
<br>
|myfile alpha|
<br>
myfile := FileStream readOnlyFileNamed:
‘/home/pi/sample.yuv’.
<br>
myfile binary.
<br>
bits size * 3 = myfile size ifFalse:[^nil].
<br>
alpha := 16rFF<<24.
<br>
1 to: bits size do: [ :i| |val|
<br>
val := myfile next.
<br>
val := val <<8 + myfile next.
<br>
val := val <<8 + myfile next.
<br>
val := alpha bitOr: val.
<br>
bits at: i put: val].
<br>
myfile close
<br>
self display
<br>
<br>
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
<br>
the cost of using the largeinteger ‘alpha’ to set
the proper alpha value for each pixel. You *can* leave that out
if
<br>
you’re going to simply do ‘myform display’ since the
raw bitblt ignores the alpha. If you are going to be examining
the
<br>
pixels as just rgb values, save the time - I see
120mS in that case.
<br>
<br>
<br>
Obviously once you have the general format sorted it
ought to get moved into Form and tidied up as From
<br>
class>>readRGBFromFileNamed: or similar.
<br>
<br>
<br>
tim
<br>
--
<br>
tim Rowledge; <a class="moz-txt-link-abbreviated" href="mailto:tim@rowledge.org">tim@rowledge.org</a>;
<a class="moz-txt-link-freetext" href="http://www.rowledge.org/tim">http://www.rowledge.org/tim</a>
<br>
Useful random insult:- If you give him a penny for
his thoughts, you get change back.
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>