Announcement

Collapse
No announcement yet.

Image Transparency Artifacts

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

  • Image Transparency Artifacts

    First I should mention that I'm new to using the 4D display modules, so this may be something obvious that I just haven't tripped over yet. I'm currently evaluating the uLCD-32PTU and the uLCD-28PTU. I'm working in Reversed Landscape mode.

    I am working in the Visi environment importing 24 bit .png files for button images. I am using full Red+Blue as the transparency color (0xF81F, or what you call FUCHSIA) and am mostly getting the expected results. However I seem to be getting some odd rendering issues when showing certain button images on-screen. For instance:

    Click image for larger version

Name:	PanelEmulation_Left___.png
Views:	54
Size:	2.4 KB
ID:	39820Click image for larger version

Name:	PanelEmulation_Left__P.png
Views:	31
Size:	2.4 KB
ID:	39818 Click image for larger version

Name:	PanelEmulation_Left_L_.png
Views:	51
Size:	1.6 KB
ID:	39821 Click image for larger version

Name:	PanelEmulation_Left_LP.png
Views:	301
Size:	1.8 KB
ID:	39822

    The above is an example of one of button's images (specifically the Left button, Normal, Pressed, Lit, Lit+Pressed versions). With this button I get a black one pixel bar on the far right side of where the image should have rendered (when any of the four button faces is called out). It is difficult to tell, but I believe this bar is in the last column of pixels that should have been drawn by the img_Show command (it's possible it's the column immediately to the right of the image region).

    Are there any known restrictions on the sizes, locations, or content of images? Let me know if I can provide specific details or tests which might provide useful information I've omitted.
    Attached Files
    Last edited by Speed8ump; 25th July 2014, 05:10 AM.

  • #2
    I think this may be a manifestation of a known issue in the current Workshop.

    Can you change the width (or height) of the UserButton by one pixel so it is not the same size as the actual image and see if that appears to fix the issue?
    Mark

    Comment


    • #3
      Ok, that appears to have fixed that issue. Thanks for the quick response. I'll see if that (or something like it) fixes my other rendering issues tomorrow (sorry, it's late here in the US). Just so I'm clear, the root cause here is that the img_Show is drawing more image than actually exists in the image file and I therefore get black? If I had used black as my transparent color would this not have been apparent? I'm just trying to clarify the actual bug so I can try to avoid/work around it. Also, is there a publicly visible bug tracker that I could have searched to find this issue (and, even better, when/if we might expect a fix)?

      Comment


      • #4
        The issue is with the underlying Windows graphics routines that only shows up when certain conditions are met (The last row column is not rendered). It has been fixed in the next workshop release.
        Mark

        Comment


        • #5
          I've now updated and rebuilt the application that had this issue and can confirm that it is fixed in the latest release. Thanks.

          Comment


          • #6
            PNGs create transparency in one of two ways. One of these methods employs the same approach used by GIFs, with a single color defined as transparent, and the other is to set an alpha channel . One of the advantages of PNG single-color transparency is that it doesn't remove a color from the available palette. However, the alpha channel is a much smoother method, as it is far better at blending colors, and allows you to select different levels of transparency in specific regions. The transparent areas of the PNG will blend and adjust naturally to whatever is behind the image when the background of the page isn't a solid white or black color.

            http://net-informations.com/q/mis/jpgng.html

            Comment


            • ESPsupport
              ESPsupport commented
              Editing a comment
              You are replying to a post from 2014. Also, whilst much of what you say is relevant to PNGs per se, it is not truly relevant to what the original poster was talking about.
          Working...
          X