How to Modify a Bitmap file in Chora that is read from and external file like .png or .bmp?

Question

1. Can I call another method from a slot method?

2. I know how to manipulate the pixels in a native C code, but, not sure how to do it in the  Prototyper in Chora. I want to modify the pixels in a Bitmap I get from and ExternalBitmap that reads the image from a .bmp file. I'm thinking of writing a method something like this below, but I'm not sure of the proper Chora Syntax.

 

   Bitmap* EwLoadExternBitmap( XString aName ):

   FrameSize  = EwGetBitmapFrameSize ( Bitmap);

    pure Width = FrameSize.x;
    pure Height = FrameSize.y;

    XRect         lockArea;
    XBitmapLock*  lock;

    lockArea.Point1.X = 0;
    lockArea.Point1.Y = 0;
    lockArea.Point2.X = Wdith;
    lockArea.Point2.Y = Height;
    lock = EwLockBitmap( bitmap, 0, lockArea, 0, 1 );
    unsigned short* dest   = (unsigned short*)lock->Pixel1;

    for ( y = 0; y < height; y++, dest += ofs )

       for ( x = 0; x < width; x++, dest++ )

    {

        ... Some Code that reads the pixels and makes modifications.

     }

      EwUnlockBitmap( lock );
      

     this.Image.Bitmap = Bitmap;  ???? I want to point the modified Bitmap to the Image View.
 

Thanks,

Answer 1

Hello,

1. Can I call another method from a slot method?

Slot methods are like regular methods. You can invoke other methods from slot methods. There are no limitations.

2. I know how to manipulate the pixels in a native C code, but, not sure how to do it in the  Prototyper in Chora. I want to modify the pixels in a Bitmap I get from and ExternalBitmap that reads the image from a .bmp file. I'm thinking of writing a method something like this below, but I'm not sure of the proper Chora Syntax.

Accessing pixel memory in Chora is not possible. Concrete, Chora has no pointers you can evaluate in order to access its memory. The operation has to be implemented in native code. If you want this code to be executed at the Prototyping time, you have to enclose the code within an Intrinsic Module for this purpose. See also:

Integrating with the device

Implementing Prototyper intrinsics

Extern Bitmap and Prototyping

Does it help you further?

Best regards

Paul Banach

Comments

Hi Paul,

Thank you for the clarification. I was able to pass the bitmap resource to the native code and modify it. I do see the modified display on the STM32F746G platform screen, where I pass a bitmap resource and just put random data for test in it and the display looked random on the hardware device screen.

#include <stdio.h>
#include <stdlib.h>
#include "ewrte.h"
#include "ewgfxdriver.h"
#include "ewextgfx.h"
#include "ewgfxdefs.h"
#include "ewextpxl_RGB565.h"

void ProcessBitmap( XBitmap* aBitmap )
{
  XRect           lockArea;
  XBitmapLock*    lock;
  int             width;
  int             height;
  unsigned short* dest;
  int             ofs;
  int             x, y;

  width  = 2* aBitmap->FrameSize.X;
  height = aBitmap->FrameSize.Y;
  
  /* Lock the entire bitmap for write/read operation */
  lockArea.Point1.X = 0;
  lockArea.Point1.Y = 0;
  lockArea.Point2.X = width;
  lockArea.Point2.Y = height;
  lock              = EwLockBitmap( aBitmap, 0, lockArea, 1, 1 );
  
  dest   = (unsigned short*)lock->Pixel1;
  ofs    = ( lock->Pitch1Y / 2 ) - width;

  /* Iterate through the pixel within the locked area. Do this
     row-by-row and column-by-column. */
  for ( y = 0 ; y < height; y++, dest += ofs )
    for ( x = 0; x < width; x++, dest++ )
  {
    *dest = rand() % 0xffff; // use 'dest' to read/write pixel data
  }

  /* Don't forget to unlock the bitmap when you are done! */
  EwUnlockBitmap( lock );
}

I had to mess around with the width "width  = 2* aBitmap->FrameSize.X;" in the code to get access to the full image, but this could be bitmap image related.

As you mentioned, it is something you don't recommend since the bitmap resource contains constant immutable data.

I have started the code to have the native c code do the bitmap SD read write and modification on the STM32F746G platform and controlling the image selections by passing the file names through ExternalBitmap.name property. Will let you know how it goes after I put all the hooks in the code.

Thanks, your answers were helpful.

mmd

---

Hello mmd,

thank you for the information. Concerning width = 2* aBitmap->FrameSize.X, this is surely  because the bitmap is in RGB565 format. Please note the data field Pitch1X (and Pitch1Y) in the XBitmapLock data structure. Pitch1X corresponds to the number of bytes used for a single pixel. In case of RGB565, 2 bytes (16 bit) are used for a single pixel. See also Bitmap color format EW_PIXEL_FORMAT_RGB565 (optional).

Best regards

Paul Banach

---

 

Hi Paul, bitmap resource passed from EW to native code looks like RGB888. I had to look at the pixel RGB data  stored in a 32 bit integer using 24 bits of it in the native C code.

See code below where I modified the bitmap to gray scale (actually the gray scale was not done to the proper formula where it should have been using: grayValue = (BYTE)(0.299*redValue + 0.587*greenValue + 0.114*blueValue)). I just changed the "dest" pointer to : unsigned int* dest; and took the width = 2* aBitmap->FrameSize.X back to its original width = aBitmap->FrameSize.X

Also I had to modify the for loop. Did not use the "ofs" 

//for ( y = 0 ; y < height; y++, dest += ofs )
  for ( y = 0 ; y < height; y++, dest++ )
    for ( x = 0; x < width; x++, dest++ )
  { ..

This way I could see the modified image in its entirety

Here is the "Inline" code below:

 

#include <stdio.h>
#include <stdlib.h>
#include "ewrte.h"
#include "ewgfxdriver.h"
#include "ewextgfx.h"
#include "ewgfxdefs.h"
#include "ewextpxl_RGB565.h"

void ProcessBitmap( XBitmap* aBitmap )
{
  XRect           lockArea;
  XBitmapLock*    lock;
  int             width;
  int             height;
  //unsigned short* dest;
  unsigned int* dest;
  unsigned short red, green, blue;
  unsigned int sum_color;
  int             ofs;
  int             x, y;

  width  = aBitmap->FrameSize.X;
  height = aBitmap->FrameSize.Y;
  
  /* Lock the entire bitmap for write/read operation */
  lockArea.Point1.X = 0;
  lockArea.Point1.Y = 0;
  lockArea.Point2.X = width;
  lockArea.Point2.Y = height;
  lock              = EwLockBitmap( aBitmap, 0, lockArea, 1, 1 );
  
  dest   = (unsigned short*)lock->Pixel1;
  ofs    = ( lock->Pitch1Y / 2 ) - width;

  /* Iterate through the pixel within the locked area. Do this
     row-by-row and column-by-column. */
  //for ( y = 0 ; y < height; y++, dest += ofs )
  for ( y = 0 ; y < height; y++, dest++ )
    for ( x = 0; x < width; x++, dest++ )
  {
 
    red =   (*dest & 0xff0000) >> 16;
    green = (*dest & 0x00ff00) >> 8;
    blue =  (*dest & 0x0000ff)  ;

    sum_color = red + green + blue;
    sum_color = sum_color/3;  

   // Actually this values should be calculated as
   // grayValue = (BYTE)(0.299*redValue + 0.587*greenValue + 0.114*blueValue);

    if (sum_color >   0xff)
        sum_color = 0xff;  //cieling sqrt(pow(Gx,2.0)
        
     
        *dest =  (sum_color << 16 ) | (sum_color << 8)  | sum_color;
        
  }

  /* Don't forget to unlock the bitmap when you are done! */
  EwUnlockBitmap( lock );
}

 

The Platform STM32F746 is set for RGB565.

---

Hello mmd,

Embedded Wizard supports and uses several bitmap formats. This is controlled by the Format attribute of the affected bitmap resource. If you want the bitmap to be stored in RGB565 format, change its attribute accordingly. I suppose, the bitmap is configured with the format Native. It represents the RGBA8888 format even on the STM32.RGB565 target system. This is essential to support transparency within the bitmap. RGB565 does not contain any alpha channel.

Best regards

Paul Banach

---

Hi Paul,

Thanks for the clarification. I will change the Bitmap Resource Format from Native to RGB565.

Thanks!

mmd