Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#1565 partially transparent images don't display correctly.

obsolete: 8.4.4
open-accepted
Jeffrey Hobbs
4
2005-12-01
2003-09-19
Joe Mistachkin
No

When using "partial transparency of images with non-
trivial alpha channels", the renderer always assumes a
grey background. This means that if the image has any
areas that are partially transparent instead of fully
transparent they will be rendered as grey pixels. This
precludes using any shape such as a rounded edge,
circles, ovals, triangles, polygons, etc (anything other
than a normalized, non-rotated rectangle) that require
anti-aliasing in an image as the edges will appear jagged
with grey pixels instead of smooth and blended with the
background pixels. The correct behaviour is to instead
sample the underlying background pixel and combine it
with the partially transparent pixel of the foreground
image to create a new "result" pixel. According to dkf
the issue appears to be a bug in the renderer code
in "tkImgPhoto.c".

Discussion

1 2 > >> (Page 1 of 2)
    • milestone: --> obsolete: 8.4.4
    • assigned_to: nobody --> dkf
     
  • Logged In: YES
    user_id=79902

    GPStaplin is working on a fix for this in selected visual
    types (those without palettes!)

     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2003-10-28

    Logged In: YES
    user_id=72656

    attaching new patch which rewrites GPS's stuff to scale back
    the a much simpler alpha blend. It always blends against the
    original image and works correctly for 16bpp (with
    tkWinImage.c patch also attached). Needs to be tested on
    OS X, especially with 16bpp.

     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2003-10-28

    • priority: 7 --> 9
     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2003-10-28

     
    Attachments
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2003-10-28

    Logged In: YES
    user_id=72656

    I should note that the one oddity I see with this is for
    Windows 16bpp displays, when the x and/or width to display
    is at the edge (clipped) and odd, the image can get slanted.

     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2003-10-28

    Logged In: YES
    user_id=72656

    attached is a modification of GPS's tests that display several
    alpha transparent images. test against 16bpp and 24+bpp
    (and 8bpp - you should see no use of blending).

     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2003-10-28

     
    Attachments
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2003-10-28

    Logged In: YES
    user_id=72656

    minor correction in patch for XGetImageZPixmap to handle
    odd width images by letting XCreateImage calc the line width
    from the bitmap_pad. This makes 16bpp work right on
    Windows.

     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2003-10-28

     
    Attachments
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2003-10-29

     
    Attachments
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2003-10-29

    Logged In: YES
    user_id=72656

    3rd gen patch that uses shift/mask info from the visual. This
    should work across LE and BE machines and X server
    variations. It's more compute intensive for unix.

     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2003-10-29

    Logged In: YES
    user_id=72656

    added new test files that have more clear images on what
    one should see.

     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2003-10-29

    latest test files for clarity

     
    Attachments
  • Logged In: YES
    user_id=79902

    Need to call ToggleComplexAlphaIfNeeded() (or otherwise
    toggle the COMPLEX_ALPHA bit) from inside Tk_PhotoPutBlock
    and Tk_PhotoPutZoomedBlock, but might it be sufficient to
    postpone computing that until idle?

     
  • Logged In: YES
    user_id=79902

    Aside from that, it looks good. Especially when I run two
    identical tests side-by-side where one is in an 8-bit window
    and the other is in a 24-bit window (one of the few things
    that an SGI is really good at!) I shan't post the code I'm
    using to do the test here, since it depends on a lot of
    extra instrumentation code that I'm still thinking about.

     
  • Logged In: YES
    user_id=79902

    Hmm. Trying out a bit further, I find that you've got 16bpp
    as the split-point between the two renderers. Wouldn't it
    be better to use 15 but then only if the visual isn't
    pseudocolor (or some other colormapped visual type?) And we
    can of course support greyscale visuals completely even if
    they are only 8 bits deep...

     
  • Logged In: YES
    user_id=79902

    Here's a helpful script (customize to suit!):

    package require Img
    set i 0
    image create photo foo -file yourSampleImage.png
    foreach visual [winfo visualsavailable .] {
    set f [frame .f$i -visual $visual]
    pack $f
    label $f.l -text $visual -image foo -compound right
    pack $f.l
    }

     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2003-10-29

    Logged In: YES
    user_id=72656

    variant #6 that has somewhat working 16bpp code for unix. I
    don't think this is 100% for 16bpp. It also simplifies the
    ALPHA_BLEND macro.

     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2003-10-29

     
    Attachments
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2003-10-30

     
    Attachments
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2003-10-30

    Logged In: YES
    user_id=72656

    7 is the lucky number. Attached is a patch that should work
    for 15bpp+ screens across the board. Needs OS X testing,
    and of course more testing everywhere else.

     
  • Logged In: YES
    user_id=79902

    Assigning to Jeff as he seems to be taking more of a lead in
    this one.

     
    • assigned_to: dkf --> hobbs
     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2003-11-11

    Logged In: YES
    user_id=72656

    fixed for 15bpp+ on Windows/Unix, but not OS X.

     
1 2 > >> (Page 1 of 2)