Shop OBEX P1 Docs P2 Docs Learn Events
Image display?? — Parallax Forums

Image display??

SethGSethG Posts: 8
edited 2010-04-05 14:47 in Propeller 1
I am doing a project that involves the wireless transmission of an image over Xbee transceivers, and then using the PropellerRPM board to display it on an LCD screen.

I know how to do it with characters and strings, but what Im not sure about is the image processing that is required, so that you can take that image, send it serially, and then take that serial data and display the image on a screen.

Can anyone help with this? It would be very appreciated.

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2010-04-01 03:39
    How do you plan to get the image into the Propeller? Normally an image is provided either as a bitmap or as some kind of image file which eventually gets converted to a bitmap for display. In both cases, the image is just a sequence of bytes and this can be sent via xBee anyway you want since it's just arbitrary byte values. The xBee will take care of error detection and correction automatically.
  • kwinnkwinn Posts: 8,697
    edited 2010-04-01 03:52
    In general sending an image is not any different than sending characters and strings. The details would be very dependent on the type of image file, the pixel resolution, and number of colors. Most picture file formats have some header information and use some form of compression so you would have to decide where the decoding is done (transmit or receive end).

    Posting some details on the source of the images and resolution/colors is needed to be more specific.
  • SethGSethG Posts: 8
    edited 2010-04-01 05:32
    Mike: Getting the image into the Propeller is one of the things Im unsure how to do.

    kwinn: I didnt think that sending the image would be a problem, but I am unsure of how to do any kind of image decoding or encoding. The image I would like to display just needs to be a simple JPEG, and it will be displayed on a 7 inch LCD screen.
    starbucks.jpg
    956 x 972 - 221K
  • StefanL38StefanL38 Posts: 2,292
    edited 2010-04-01 07:40
    Hello SethG,

    it highly depends on the interface on the sourceside and the display side

    JPGEGs are compressed by a rather complicated algorythm.
    the picture you attached has a size of 956x972 pixel 16 Million colors.
    which results in a size of 2,6 MByte.

    So for more specific help there are some questions that HIGHLY control how a suitable solution looks like

    What is the pixel resolution of your display?
    What kind of interface does the display have?

    If I understand right you have a configuration like this Device(a PC??)---XBEE - - - - - - wireless - - - - - XBEE---Propeller-RPM
    Display

    What is the device on the left side? a PC?

    So for more specific answers you have to answer these questions and have to provide a manual of the display as PDF-File.

    If you have a PC on the left side and the image does NOT have to be updated every few minutes or seconds you could store the image in the BMP-format
    on the PC and transfer byte for byte of the BMP-file to the propeller and the propeller sends these bytes to the display.
    HOW the sending of the bytes can be done and if you have to do some data-transformations so the display understands the data depends on the Display-interface.
    So if you want to go on you HAVE TO provide the display manual.

    As a general hint:
    In the Microcontroller-world NOT everything is as standadised as in the PC-world where you can combine a PC from manufacturer A,B,C with monitor from manufacturer X,Y,Z
    and everything will work everytime in every combination just by plugin the monitor. In the microcontroller-world you can get almost everything working but sometimes it
    requires that YOU create the driver or a hardwareinterface.

    If you could post a general description of your project the forum-members can make much more specific suggestions.

    Examples:
    If your display should show some pictures and change from picture to picture after some time a digital picture-frame with a trigger-input "show-next-picture" would suit perfectly

    If your display should show all kinds of pictures but they change at least only every few minutes a display with a serial interface that has some intelligence on board so that the display
    can process JPEG-decoding itself would be a solution with a quite expensive display but is easy to program

    best regards

    Stefan

    Post Edited (StefanL38) : 4/1/2010 7:46:27 AM GMT
  • MagIO2MagIO2 Posts: 2,243
    edited 2010-04-01 08:12
    Some thoughts:
    Even transmission of a Jpeg will be to slow with an XBEE. So, you need to store the picture somewhere before displaying. If you can live with even slower transmission, the easiest thing would be to send BMP-files. BMP is uncompressed but you can handle it easily! It only has a header which can be skipped and then the R G B -pixel data.

    On display side it very much depends on the display you use. I think the most 7" displays expect digital pixel-data to be send repeatingly. Some smaller displays (I guess up to 3,5") have internal RAM. With those it's easy, as the propeller only has to send the BMP to the display once. The more colors you want to support, the more RAM you need. And you should have enough RAM to store 2 pictures there. The one being displayed and the one that's currently received by XBEE.

    What's the resolution of the display?

    So, depending on your goals it can be very easy (SD card, display including RAM) or very complex (fast RAM, display without RAM, 256k color) to implement that.
    In the first example you simply receive an image and store it on SD card. When it's done you send it to the display in ~200ms. Then the prop can wait for the next image.
    In the second example you need RAM which is fast enough for the refresh plus the storage of a new image. You have to interleave the access to the RAM. You need a lot of PINs to address the RAM.
  • kwinnkwinn Posts: 8,697
    edited 2010-04-01 14:27
    SethG, why don't you post information about the specific hardware (if any) you have in mind for sending, receiving, and displaying the images. Right now your question is so wide open it is almost impossible to make any concrete suggestions.

    How much data needs to be sent depends on the compression algorithm used and the resolution and color depth of the LCD you are using. There is a trade off between the amount of data sent and the complexity of the compression/decompression algorithm. Also, there is no point in sending more data than the LCD can display.

    For the simple image you are sending a small color look-up table (2 bits per pixel for 4 colors) and rll encoding would reduce the amount of data sent significantly and be very simple to code.
  • SethGSethG Posts: 8
    edited 2010-04-01 15:56
    Ok here are the specifics of what I have.

    The LCD screen has a composite video input, and has a resolution of 1440 x 234. It has no internal RAM.

    For sending and receiving data I am using the Xbee Pro. Here is the data sheet: http://ftp1.digi.com/support/documentation/90000903_C.pdf
    On the sending end I am going from PC -> Xbee. On the receiving end I have Xbee -> Propeller -> LCD. But I also have a 1MB EEPROM chip that is able to interface with the Propeller, for storage of the transmitted image. Here is the data sheet for the memory: http://www.atmel.com/dyn/resources/prod_documents/doc5194.pdf

    MagIO2: When you say slow transmission for a BMP, what type of time are we talking? Anything under 30 seconds would be acceptable for this project.



    -Thanks for all the help so far.
  • kwinnkwinn Posts: 8,697
    edited 2010-04-01 19:18
    1440 x 234 is an odd size. If the pixels are square that would be approximately a 6:1 screen ratio. Very wide but not very tall. Is it possible that it is 480 x 234 but they multiply the 480 by the 3 RGB pixels? That would be a more reasonable width/height ratio.

    Can you measure and post the width and height of the display?
  • MagIO2MagIO2 Posts: 2,243
    edited 2010-04-01 22:12
    Well .. you can calculate that by yourself.

    I think kwinn is right with his guess ... so, 480 x 234 pixels x color depth in bits per pixel / net transfer rate of the XBEE.
    For a full color (24 bit) picture would need 23,4 seconds if your max. speed is 115,2kbit/sec. But for composite you could also use a BMP file with a color pallette and only 8 bits per pixel.

    Do you want the LCD to get black while receiving the next image? That EEPROM is to slow for displaying. If you only use 4 bit per pixel you already need >3MByte/sec data transfer-rate for a 60Hz refresh. And no time left for writing to the EEPROM!
    One image with 4 bit per pixel needs 56kB, so you can't store it in internal RAM.
  • SethGSethG Posts: 8
    edited 2010-04-02 22:46
    kwinn: You said that for this type of image a small color look-up table (2 bits per pixel for 4 colors) and rll encoding would reduce the amount of data sent significantly and be very simple to code. How exactly would I go about doing that, and would that be the code that actually displays the image on the screen?

    Not sure if you can tell but Ive never even dealt with a microcontroller before this project, so sorry if some of these questions are kinda stupid.
  • RaymanRayman Posts: 14,880
    edited 2010-04-02 23:33
    SethG:

    Check out my 2-bit bitmap examples:

    http://www.rayslogic.com/propeller/Programming/2BitBitmap.htm

    I think this will do what you want...

    Ray

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm

    My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm
  • kwinnkwinn Posts: 8,697
    edited 2010-04-03 14:13
    SethG:

    I did get the impression from your post that you might be new to this, but we all have to start somewhere, and asking questions on this forum is a great place to start.

    Take a look at Rayman's code. There is some good information and code there but you may need to learn some basics before you can understand it.

    Instead of RLL I should have referred to the compression as RLE since it is a more commonly used term (RLL was the variant used on hard disk drives). See http://en.wikipedia.org/wiki/Run-length_encoding for an explanation.

    For the 2 bit look up table you are essentially sending 2 bits of data for each pixel in the picture and using those 2 bits to select one of 4 colors to display. The number of bits in the color you look up would depend on the display you are putting the image on. It could be 8 bits for a 256 color display, 16 bits for a 65535 color display, or 24 bits or more for high color resolution displays.

    Keep in mind that with only 2 bits per pixel you can only select 4 out of all the possible colors available.

    See http://en.wikipedia.org/wiki/Bitmap for more info.
  • SethGSethG Posts: 8
    edited 2010-04-04 21:18
    Rayman: Thanks a lot for all the code and examples. I am confused about one thing though. Here is what I understand. The .dat files that you use comes from your Prop2BitBitmap program. This .dat file is made up of a certain number of longs. I the number of longs the nuchars in your code?

    I also am confused about the colors that are in the code. How do the colors from the dat file get put into the code? You have colors[noparse][[/noparse]0]:= $05_2A_05_2A for example, and I am confused about the meaning of this.
  • RaymanRayman Posts: 14,880
    edited 2010-04-04 22:58
    Ok, yeah, figuring out the right value for nuchars is the trickiest part of this...

    It has to be exactly equal to the total number of tiles worth of special characters.

    This is so the code knows how much data it needs to align to the next 16-long boundary.
    This is required by all the TV/VGA style drivers...

    As for the colors, there are 4 colors defined there because it's 2-bit graphics.

    There are some color applets on my website that may help figure out how they work...

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm

    My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm
  • SethGSethG Posts: 8
    edited 2010-04-05 01:48
    Ok, the color part makes more sense now, although I still don't how to get the correct colors from my own images coming from your program.

    Also, how do I find out the number of tiles worth of special characters? Sorry, but Im not even sure what that means...
  • RaymanRayman Posts: 14,880
    edited 2010-04-05 14:47
    A tile is a 16x16 block of pixels...

    So, if your embedded image is 32x32 pixels, then nuchars should be 4.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm

    My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm
Sign In or Register to comment.