<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    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 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 &lt;= 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.<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 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 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>
    <blockquote
      cite="mid:alpine.DEB.2.02.1508301431550.11724@login03.caesar.elte.hu"
      type="cite">| 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>
      <blockquote type="cite">
        <br>
        On 29-08-2015, at 8:13 AM, Herbert König
        <a class="moz-txt-link-rfc2396E" href="mailto:herbertkoenig@gmx.net">&lt;herbertkoenig@gmx.net&gt;</a> wrote:
        <br>
        <br>
        <blockquote type="cite">Hi,
          <br>
          <br>
          how do I go about reading a raw RGB 888 (24 bits deep output
          from raspiyuv) file into a Form?
          <br>
        </blockquote>
        <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
        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 &amp; 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.
        <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 &amp; 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 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.
        <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 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 -&gt; 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&lt;&lt;24.
        <br>
        1 to: bits size do: [ :i| |val|
        <br>
        val := myfile next.
        <br>
        val := val &lt;&lt;8 + myfile next.
        <br>
        val := val &lt;&lt;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 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.
        <br>
        <br>
        <br>
        Obviously once you have the general format sorted it ought to
        get moved into Form and tidied up as From
        class&gt;&gt;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>
      </blockquote>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">
</pre>
    </blockquote>
    <br>
  </body>
</html>