Uploaded image for project: 'Batik'
  1. Batik
  2. BATIK-454

unexpected non-zero alpha due to clamping of premultiplied filter results



    • Type: Bug
    • Status: Open
    • Resolution: Unresolved
    • Affects Version/s: 1.5
    • Fix Version/s: None
    • Component/s: GVT Filters
    • Labels:
    • Environment:
      Operating System: Windows XP
      Platform: PC


      The premultiplied results of the arithmetic FeComposite filter
      primitive are being clamped by increasing alpha to the highest
      color component. The spec, in Section 15.7.1, merely states:
      "The RGBA result from each filter primitive will be clamped into
      the allowable ranges for colors and opacity values. Thus, for
      example, the result from a given filter primitive will have any
      negative color values or opacity values adjusted up to color/opacity
      of zero." It doesn't specify whether to clamp the alpha value up
      or the color values down. The Adobe Viewer seems to do the latter,
      and the results seem more natural to me; this may be related to the
      fact that this is what would happen if the clamping were performed
      on the non-premultiplied values. Batik's method has the advantage that
      it doesn't change the hue, but this could also be achieved by clamping
      the color values proportionally such that the highest is equal to the
      alpha value. Anyway, the appearance of non-zero alpha values where one
      expected complete transparency is troublesome.

      I've submitted a request for clarification of the spec to www-svg@w3.org




            • Assignee:
              batik-dev@xmlgraphics.apache.org Batik Developer's Mailing list
              fpahl@web.de Felix Pahl
            • Votes:
              0 Vote for this issue
              0 Start watching this issue


              • Created: