Announcement

Collapse
No announcement yet.

uOLED-160-G2 screen image appears to be wrong color with horizontal banding

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

  • uOLED-160-G2 screen image appears to be wrong color with horizontal banding

    Hello,

    I've just begun using a uOLED-160-G2 and ViSi in order to load images onto the board. The image file I'm using is a simple black background with a white numeral, but when it displays on the board, the color appears slightly brown/dark red and has 5 distinct horizontal color bands that run the complete width of the screen. See included picture of the screen (showing the Windows version, 16 bit bitmap) and a jpeg of the same image file (having trouble attaching the actual bitmap file).

    I've tried outputting the file in 16, 24, and 32 bit Windows versions in Photoshop, 24 bit Mac, PNG, and JPEG, but all feature the same issue. I tried a different image file, with the same background and foreground colors, but it appears the same. Finally, I grabbed another 160-G2 and downloaded the same code, but to no avail.

    Thanks very much for any help you might be able to offer!

    Click image for larger version

Name:	Marker1_16_Windows.jpg
Views:	37
Size:	2.4 KB
ID:	42567 Click image for larger version

Name:	uOLED-160-G2_image_problem.jpg
Views:	29
Size:	3.71 MB
ID:	42566
    Attached Files

  • #2
    What you are seeing is a characteristic of PM OLED displays.

    It shows up when you drive the display too hard and/or have high contrast colours.

    You can also try reducing the 'brightness' of the display (using gfx_Contrast)

    You need to play around with the above until you get an acceptable display appearance.
    Mark

    Comment


    • #3
      Mark,

      Thanks for your quick reply. I tried changing the black background color to a light gray (till white foreground), but didn't see much difference. The horizontal bands were still quite prevalent. I also tried to change the brightness via gfx_Contrast(x), but can't see any difference in brightness or color/horizontal banding using any value from 1-16. Value 0 does shut off the display for me.

      Can you elaborate on 'drive the display too hard'? Do you mean in reference to a refresh rate? I've put some pause(1000) lines in the code, but that doesn't seem to help anything.

      Or, do I need to call another function after calling gfx_Contrast() in order to force the change through? Currently, my psuedo code looks like this:

      main()
      Display image (code pasted in from Object Inspector)
      gfx_Contrast(2)

      repeat
      forever

      endfunc

      Comment


      • #4
        Hmm, trying to create some 'examples' and not having too much success.

        Can you post your code so I can work with that?

        Also, can you measure the voltage at the input to the display?
        Mark

        Comment


        • #5
          Sure thing, thanks for your help. Code is below, image with gray background and inital black background images are attached as zipped bitmaps.

          When the screen is actively displaying something, I get between 4.76 and 4.8 VDC on the input pins, and 5.0 when the contrast is set to zero (screen is not active). I've been using the programming cable and my laptop, but used a bench top DC power supply and am getting the same horizontal banding, so I don't think that it's attributable to the laptop USB power supply.

          Mike


          #platform "GOLDELOX"

          // Program Skeleton 1.0 generated 1/28/2015 9:06:28 AM

          #inherit "4DGL_16bitColours.fnc"

          #inherit "VisualConst.inc"

          #inherit "NoName1Const.inc"

          func main()
          // Uncomment the following if uSD images, fonts or strings used.

          print("Starting\n") ;
          while(!media_Init())
          putstr("Drive not mounted...");
          pause(200);
          gfx_Cls();
          pause(200);
          wend

          repeat


          // Image2 1.0 generated 1/28/2015 1:35:00 PM
          media_SetAdd(iImage2H, iImage2L) ; // point to the Image2 image
          media_Image(0, 0) ; // show image

          pause(1000) ;

          gfx_Contrast(16) ;

          pause(5000) ;

          gfx_Contrast(0) ;

          forever

          endfunc
          Attached Files

          Comment


          • #6
            Hmm, well in your case the problem is that the background is not truly black, as a windows 24 bit colour value it is 0x212121. If I make the background truly black (i.e. 0x000000) the smearing is not visible.
            Mark

            Comment


            • #7
              Mark, thank you, that seemed to fix the problem (but only for a bit!). When I use true white text on a true black background, the horizontal smearing goes away completely. But, I was just given a file with a true-black background and a gradient in the foreground text, from a near-white transitioning to a blue (see .png included). When I display this image using the same code as posted above, I get the horizontal banding (see .jpeg included).

              It seems that feeding the screen images with colors that it can't display causes the gradient. Is there any "easy" way to design within these limits? In other words, if I only use colors from a certain list, that the image should appear without the smearing? I've looked in the Goldelox documentation, but I can't find a table of standard colors.

              The datasheet says it's capable of 65,000 colors, so I wonder if it's something like 40 distinct levels of R, 40 of G, and 40 of B (40^3 = 64,000)?

              Thanks for the help!
              Attached Files

              Comment


              • #8
                65k colors is usually (and is in this case) often described as 565 colour. This means 5 bits of Red, 6 bits of Green and 5 bits of Blue, or, to put it another way 32 shades of Red, 64 shades of Blue and 32 shades of Green.

                Whilst a normal picture looks fine, a gradient can easily show up the 'scale' of available colours, whereas the Windows style 888 color (256 shades of each colour) makes a gradient look much more normal.

                I generally avoid using gradients, but the do look ok in some circumstances.
                Mark

                Comment


                • #9
                  Mark,

                  Thanks for the response. I read up on 565 color and figured out how to force photoshop to export my bmps in that color scheme. I still had a weird gradient in the numeral image displayed, so I tried to just export an image with various colors we are thinking about using together. Overall, the individual color squares look okay. But, on the LHS where it should be a continuous strip of purple color top to bottom, you can clearly see "ghosting" of the other squares. See in the included input BMP and a cell phone photo of the image as displayed on the screen.

                  I promise that I'm not trying to steal all of your time with these questions I'm just trying to better understand how (if?) I can design images that fit within the limitations of the screen/driver. Thanks again for your assistance.

                  Mike
                  Attached Files

                  Comment


                  • #10
                    Think of it this way, for each line across the OLED there are three power supplies One for RED, one for GREEN and one for BLUE. There is only a limited current available (due to the 'thin wires' required to keep them 'invisible') and thus the more of any one color you use one one line, the less of it there is available to the color overall.

                    Here's a pure code example that shows the 'effect', although it's very hard to 'see' the 'extra green' in row two, the overall whiteness difference between row 1 and 2 is noticeable.

                    Code:
                    #platform "GOLDELOX"
                    
                    #inherit "4DGL_16bitColours.fnc"
                    #constant w 28
                    #constant h 21
                    #constant g 4
                    
                    func main()
                    
                        gfx_ScreenMode(LANDSCAPE) ; // change manually if orientation change
                    
                        gfx_RectangleFilled(g,       g,       g+w,     g*3+h*4, WHITE) ;
                        gfx_RectangleFilled(g,       g*4+h*4, g+w,     g*5+h*5, WHITE) ;
                    
                        gfx_RectangleFilled(g*3+w*2, g, g*3+w*3, g+h, RED) ;
                        gfx_RectangleFilled(g*4+w*3, g, g*4+w*4, g+h, LIME) ;
                        gfx_RectangleFilled(g*5+w*4, g, g*5+w*5, g+h, BLUE) ;
                    
                        gfx_RectangleFilled(g*3+w*2,   g*2+h, g*3+w*3,     g*2+h*2, RED) ;
                        gfx_RectangleFilled(g*5+w*4, g*2+h, g*5+w*5, g*2+h*2, BLUE) ;
                    
                        gfx_RectangleFilled(g*2+w,   g*3+h*2, g*2+w*2, g*3+h*3, RED+LIME) ;
                        gfx_RectangleFilled(g*3+w*2, g*3+h*2, g*3+w*3, g*3+h*3, RED) ;
                        gfx_RectangleFilled(g*4+w*3, g*3+h*2, g*4+w*4, g*3+h*3, LIME) ;
                        gfx_RectangleFilled(g*5+w*4, g*3+h*2, g*5+w*5, g*3+h*3, BLUE) ;
                    
                        gfx_RectangleFilled(g*2+w,   g*4+h*3, g*2+w*2, g*4+h*4, RED+LIME) ;
                    
                        repeat                      // maybe replace
                        forever                     // this as well
                    
                    endfunc
                    Whilst forcing Photoshop to export 565 will make the 565 color palette more obvious sooner, be aware that as soon as Windows sees 565 it will convert it to 888 and when Workshop builds the uSD it will convert it back to 565. Whilst the conversion should be perfect and exact I do now know exactly what it doing under the covers so it can't be 'guaranteed'.
                    Mark

                    Comment

                    Working...
                    X