Native Image Format

[MobileWill]

Are there any examples of using native image format? I would like to try it for RGB565. I want to be able to read a pixel at run time.

 

Thanks. 

Edited February 16, 2016 by MobileWill

[Joel Bodenmann]

There are no explicit examples for that because they wouldn't be very portable. You can use any of the existing image examples you want. All you do is enabling the native format in the configuration file - everything else stays the same!

You can find the definition of the native format header in our wiki: http://wiki.ugfx.org/index.php/Images#NATIVE

If you are having any issues getting this to work please do not hesitate to show us your file(s) so we can have a look.

[MobileWill]

I had read that wiki but I don't quite understand the header.

 

{ 'N', 'I', width.hi, width.lo, height.hi, height.lo, format.hi, format.lo }

 

I was able to use a utility to generate an array of pixel data. Each element is a 16bit hex value with color of that pixel. I wrote my own loop to read it back. I converted to RGB888 and then used the RGBCOLOR macro to set the color before using drawpixel. If I add the header and make it a native format then I could set the container to use the image instead. 

 

The question is will the container redraw every time I draw a pixel to it? I rather it not since I am handling that myself so that I only redraw the one pixel that needs redrawing instead of the whole image. In my first working test it is working nicely. The idea is to have a high quality image as the graph background. Load the image to the display and then once the graph updates only redraw the pixel for that x,y and then draw the new data point. 

 

 

[inmarket]

The header...

Byte 0:   The letter 'N' (0x4E)
Byte 1:   The letter 'I' (0x49)
Byte 2 and 3:   The image width in MSB first order
Byte 4 and 5:  The image height in MSB first order
Byte 6 and 7:  The pixel format expressed in the same way that the macro GDISP_PIXEL_FORMAT is expressed. Note that this must match the pixel format of the current display for the NATIVE image handler to process it. Again it must be in MSB byte order.

 

[MobileWill]

{ 'N', 'I', 0x1, 0x40, 0xF0, 0x0, 0x5 , 0x65}

So something like this for 320x240 RGB565

Does the pixel data go in this array or another?

Edited February 17, 2016 by MobileWill

[inmarket]

That looks roughly right (without getting out a calculator to check the numbers).

The pixel data must immediately follow the header.

[inmarket]

Actually just checked. Byte 6 (the 2nd last) must be 0x25 not 0x05.

See the pixel color definitions in src/gdisp/gdisp_colors.h

 

[MobileWill]

Then if I want a single pixel I will have to offset my loop to account for the header data. This is what I am using now to read an array of just pixel data. 

 

for (i=0; i<width; i++){
        for(j=0; j<height; j++){
            r = ((((_acgraphH[i+(j*width)] >> 11) & 0x1F)*527)+23) >> 6;
            g = ((((_acgraphH[i+(j*width)] >> 5) & 0x3f)*259)+33) >> 6;
            b = (((_acgraphH[i+(j*width)])  & 0x1f) + 23) >> 6;
            gh->color=(RGB2COLOR(r,g,b));
            gwinDrawPixel(gh,i, j);
        }
     }

 

[MobileWill]

1 minute ago, inmarket said:

Actually just checked. Byte 6 (the 2nd last) must be 0x25 not 0x05.

See the pixel color definitions in src/gdisp/gdisp_colors.h

 

Wouldn't that be for True color (24bit)? The stm32f429 discovery board is only setup for 16bit. My final board will support 24bit color though. 

[inmarket]

Yes. As your _acgraphH array is 2 bytes each item you will need to add an offset of 4 (4 * 2 bytes = 8 byte header)

[inmarket]

The extra 0x20 indicates it is RGB format. 0x30 would mean it is BGR, 0x40 would mean it is greyscale.

See gdisp_colors.h

 

[MobileWill]

1 minute ago, inmarket said:

The extra 0x20 indicates it is RGB format. 0x30 would mean it is BGR, 0x40 would mean it is greyscale.

See gdisp_colors.h

 

Ah yes. I was ignoring the OR. (GDISP_COLORSYSTEM_RGB|0x0565) which is 0x2000|0x0565

[inmarket]

True color does not mean 24 bit. That is a misrepresentation that comes from the X documentation that is applied only in terms of how X uses that term.

True color in this sense means that the color is represented directly as r,g,b bits per pixel rather than via a palette lookup or a chroma scale.

[MobileWill]

And in my case I have to shift since I am not using RGB888. Unless there is a way to pass to gfx the RGB565 bits instead of shifting first which I would imaging gets shifted back to 565 since the display is 565. 

 

Or store the image in RGB888 which takes more flash. At least for now I do the have room. 

Edited February 17, 2016 by MobileWill

[inmarket]

What format is your display in?

If your display is in RGB888 then you should use RGB888 if you want the gdispImage calls to be able to recognise the image you have created.

If your display is in RGB565 then you should use RGB565 if you want the gdispImage calls to be able to recognise the image you have created.
 

If you are not interested in the gdisp image calls recognising the image then you can use whatever format you want.

If the format is the same as your display you can use the below code to get the pixel components (obviously before you do any other translation on it)...
      r = RED_OF(_acgraphH[4+i+(j*width)])
etc. The reason this works is because if your pixel format matches the display and so the RED_OF() understand the pixel format.

[MobileWill]

Yes its RGB565 and that is the format of the array. Perfect I thought of using RED_OF but hadn't tried it. So I shouldn't have to much shifting other than separating the bits. Cool. 

 

Other than creating the array for the nativefs, how does uGFX know about it? Is there a index like the ROMFS header?

[inmarket]

No. GFILE's nativefs just passes the file name directly to your operating system's file open call. It is the base operating system that finds the file. Nativefs is really just a thunk layer to the standard operating system calls.

As GFILE tries each file system in turn, for a development environment you can turn on nativefs and have the file located in the current directory when you run the development uGFX executable, and then when everything works as you expect, you can move those files into the ROMFS without changing any other application code.

There is a gfxconf.h macro you can specify which turns on code that enables you to specify a filesystem specific file using a "X|" type syntax but generally that is turned off and thus GFILE searches each file-system until it finds a match.

 

[MobileWill]

Oh so its just like ROMFS but the header will till GFile that it is native and not encoded. So nativeFS still uses ROMFS for the file storage. 

[Joel Bodenmann]

I think you are mixing things up: NativeFS from the GFILE module and NativeFormat from the GDISP (image) module have nothing in common. Those are two completely separate things.

The NativeFS is just a layer that glues the underlying operating systems file system to GFILE. NativeFS does not use ROMFS for anything.

The Native format for the GDISP images is something completely different. It's an image format.