ICEpdf
  1. ICEpdf
  2. PDF-815

Image colours in provided PDF rendered incorrectly

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 5.1
    • Fix Version/s: 5.1.1
    • Component/s: Core/Parsing
    • Labels:
      None
    • Environment:
      All

      Description

      With the provided PDF, there is an image that is rendered in what looks to be the opposite colours of how it is rendered in Adobe.

        Activity

        Hide
        Patrick Corless added a comment -

        DeviceN colour space issue. Will need to investigate further as to what is the cause of the ordering issue.

        Show
        Patrick Corless added a comment - DeviceN colour space issue. Will need to investigate further as to what is the cause of the ordering issue.
        Hide
        Patrick Corless added a comment -

        Unfortunately the fix breaks a bunch of other sample files we have. PDF-762 had his original fix attached to it, I'll need to revisit the issue to see if some sense can be made of this corner case related to our other samples.

        Show
        Patrick Corless added a comment - Unfortunately the fix breaks a bunch of other sample files we have. PDF-762 had his original fix attached to it, I'll need to revisit the issue to see if some sense can be made of this corner case related to our other samples.
        Hide
        Patrick Corless added a comment -

        I have a fix for the missing red dashed boarder which is actually an image. The image is raw and falls back to our old parseImage legacy image code. The only problem is that the code has no support for 2 bit per component and the deviceN colour space. Most DeviceN falls under colour space component count of 4 regardless, so I've made a slight tweak to get the image to decode correctly. The old fall through code just writes a white pixel.

        Show
        Patrick Corless added a comment - I have a fix for the missing red dashed boarder which is actually an image. The image is raw and falls back to our old parseImage legacy image code. The only problem is that the code has no support for 2 bit per component and the deviceN colour space. Most DeviceN falls under colour space component count of 4 regardless, so I've made a slight tweak to get the image to decode correctly. The old fall through code just writes a white pixel.
        Hide
        Patrick Corless added a comment -

        Passed QA, marking as resolved.

        Show
        Patrick Corless added a comment - Passed QA, marking as resolved.

          People

          • Assignee:
            Patrick Corless
            Reporter:
            Arran Mccullough
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: