Announcement

Collapse
No announcement yet.

uVGAIII - more information about image format and displaying it on the screen

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • uVGAIII - more information about image format and displaying it on the screen

    I am connecting the uVGAIII module to an old Z180 based computer and lots of stuff are working - but now I'm stuck with the problem of displaying images from the SDCARD. I suppose, that the file format is raw 565 format ? At least I was able to load a screen capture in GIMP by selecting the the 565 filter.

    But there are other problems: I have an image of 640x360 and want to display on my screen (format 640x480) - but that never worked:

    a) Actually I do not understand, how the Picasso can know the dimension of the image in that file. So how can he display it at all ?
    b) I logged all stuff and as I interpret it: I got a file handle, and the DisplayImage command returns zero error (0x00, 0x00)

    Any idea to get around this ???

    Thanks,

    Marten

  • #2
    Ok, it seems a question about the supported graphic format. Can anyone give me a hint, how the graphic format is correctly defined.

    It seems, that byte 0 and 1 in the file are width, 2+3 are height but 4+5 is still unkown for me.

    Comment


    • #3
      Hi Marten,

      It seems that you are using Serial Environment which can be used without WS4.

      Our display modules actually uses a custom format GCI and DAT files for graphics.

      You can design your graphics interface using either ViSI or ViSi Genie environment of Workshop4.

      The IDE will compile the graphics for you and will prompt to copy it to a FAT16 formatted SD card.

      This can then be used to be shown on your display. You can use the Serial Commander tool from WS4's serial environment to test this.

      I attached a CGI and DAT files as example. You can test it using Serial Commander with the steps provided.

      Hope this helps.

      Best Regards,
      Ferdinand
      Attached Files

      Comment


      • #4
        Some further information:

        0000 - 02
        0001 - 80 width (0x280 = 640)
        0002 - 01
        0003 - E0 height (0x1E0 = 480)
        0004 - 10 ???
        0005 - 00 ???
        0006 ..... image data

        and on top of that: ALL data (the picture data also) have to be big endian. For conversion you may consider ffmpeg with pixel format rgb565be:

        ffmpeg -vcodec bmp -i /path/to/texture-file.bmp -vcodec rawvideo -f rawvideo -pix_fmt rgb565be output.raw

        After the conversion step you have to insert the 6 bytes mentioned before (with your width and height) at the beginning of that file.

        Comment


        • #5
          Hi,

          Byte no 4 is the colour depth of the image so a 565 image will always be 0x10 - 16 bit. The following byte is a image or image set identifier. If this bye is 0 then the image data starts immeiately after. If this byte is greater than 0 then the image file is treated as an image set and there will be a further 2 bytes indicating how many frames are in the image set as a 16 bit value, image data will follow these 2 bytes and are arranged as width * height * 2 * no of frames.

          I hope this helps

          Best regards

          Paul

          Comment


          • #6
            Also see Q4 here https://forum.4dsystems.com.au/node/2290
            Mark

            Comment


            • #7
              And the command to convert the files back to bmp (but before you have to remove the 6 bytes header from the input tool):

              ffmpeg -vcodec rawvideo -pix_fmt rgb565be -s 640x480 -i ./capture.raw -vcodec bmp output.bmp

              Comment


              • #8
                Or use GCI2BMP and leave the 6 bytes there https://forum.4dsystems.com.au/node/69007
                Mark

                Comment

                Working...
                X