Uploaded image for project: 'PDFBox'
  1. PDFBox
  2. PDFBOX-1915

Implement shading with Coons and tensor-product patch meshes

    Details

      Description

      Of the seven shading methods described in the PDF specification, type 6 (Coons patch meshes) and type 7 (Tensor-product patch meshes) haven't been implemented. I have done type 1, 4 and 5, but I don't know the math for type 6 and 7. My math days are decades away.

      Knowledge prerequisites:

      • java, although you don't have to be a java ace, just feel confortable
      • math: you should know what "cubic Bézier curves", "Degenerate Bézier curves", "bilinear interpolation", "tensor-product", "affine transform matrix" and "Bernstein polynomials" are, or be able to learn it
      • maven (basic)
      • svn (basic)
      • an IDE like Netbeans or Eclipse or IntelliJ (basic)
      • ideally, you are either a math student who likes to program, or a computer science student who is specializing in graphics.

      A first look at PDFBOX: try the command utility here:
      https://pdfbox.apache.org/commandline/#pdfToImage
      and use your favorite PDF, or the PDFs mentioned in PDFBOX-615, these have the shading types that are already implemented.

      Some simple source code to convert to images:

      String filename = "blah.pdf";
      PDDocument document = PDDocument.loadNonSeq(new File(filename), null);
      List<PDPage> pdPages = document.getDocumentCatalog().getAllPages();
      int page = 0;
      for (PDPage pdPage : pdPages)
      {
      ++page;
      BufferedImage bim = RenderUtil.convertToImage(pdPage, BufferedImage.TYPE_BYTE_BINARY, 300);
      ImageIO.write(bim, "png", new File(filename+page+".png"));
      }
      document.close();

      You are not starting from scratch. The implementation of type 4 and 5 shows you how to read parameters from the PDF and set the graphics. You don't have to learn the complete PDF spec, only 15 pages related to the two shading types, and 6 pages about shading in general. The PDF specification is here:
      http://www.adobe.com/devnet/pdf/pdf_reference.html

      The tricky parts are:

      • decide whether a point(x,y) is inside or outside a patch
      • decide the color of a point within the patch

      To get an idea about the code, look at the classes GouraudTriangle, GouraudShadingContext, Type4ShadingContext and Vertex here
      https://svn.apache.org/viewvc/pdfbox/trunk/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/graphics/shading/
      or download the whole project from the repository.
      https://pdfbox.apache.org/downloads.html#scm
      If you want to see the existing code in the debugger with a Gouraud shading, try this file:
      http://asymptote.sourceforge.net/gallery/Gouraud.pdf

      Testing:
      I have attached several example PDFs. To see which one has which shading, open them with an editor like NOTEPAD++, and search for "/ShadingType" (without the quotes). If your images are rendering like the example PDFs, then you were successful.

      Optional:
      Review and optimize the complete shading package for speed; implement cubic spline interpolation for type 0 (sampled) functions (that one is really low-low priority, see details by looking up "cubic spline interpolation" in the PDF spec, which tells that it is disregarded in printing, and I don't have a test PDF).

      Mentor: Tilman Hausherr (European timezone, languages: german, english, french)

      1. XYZsweep.pdf
        5 kB
        Tilman Hausherr
      2. updateshading6ContourTest.rar
        5 kB
        Shaola Ren
      3. type45.pdf
        86 kB
        Shaola Ren
      4. TRITYP4.pdf
        3 kB
        Tilman Hausherr
      5. tensor-nofunction-RGB.ps
        0.5 kB
        Tilman Hausherr
      6. tensor-nofunction-RGB.pdf
        3 kB
        Tilman Hausherr
      7. tensor-nofunction-RGB_1.png
        79 kB
        Shaola Ren
      8. tensor4-nofunction.ps
        1 kB
        Tilman Hausherr
      9. tensor4-nofunction.pdf
        3 kB
        Tilman Hausherr
      10. tensor4-nofunction_1.png
        68 kB
        Shaola Ren
      11. TENSOR.pdf
        5 kB
        Tilman Hausherr
      12. Shadingtype6week1.pdf
        530 kB
        Shaola Ren
      13. shading7.rar
        1.37 MB
        Shaola Ren
      14. shading6Done.rar
        847 kB
        Shaola Ren
      15. shading6ContourTest.rar
        30 kB
        Shaola Ren
      16. Shading2Function2LargeDomain.ps
        0.2 kB
        Tilman Hausherr
      17. Shading2Function2LargeDomain.pdf-1-good.png
        8 kB
        Tilman Hausherr
      18. Shading2Function2LargeDomain.pdf-1-bad.png
        10 kB
        Tilman Hausherr
      19. Shading2Function2LargeDomain.pdf
        3 kB
        Tilman Hausherr
      20. pattern-shading-2-4-idMatrix.pdf
        6 kB
        Tilman Hausherr
      21. patchMap.jpg
        44 kB
        Shaola Ren
      22. patchCases.jpg
        43 kB
        Shaola Ren
      23. pass4FlagTest.rar
        36 kB
        Shaola Ren
      24. mcafeeu5.pdf-1.png
        61 kB
        Tilman Hausherr
      25. mcafeeU5.pdf
        131 kB
        Tilman Hausherr
      26. mcafeeU5_1.png
        6 kB
        Shaola Ren
      27. McAfee-ShadingType7.pdf
        621 kB
        Tilman Hausherr
      28. lineRasterization.jpg
        45 kB
        Shaola Ren
      29. LATTICE2.pdf
        3 kB
        Tilman Hausherr
      30. LATTICE1.pdf
        3 kB
        Tilman Hausherr
      31. lamp_cairo7_1.png
        42 kB
        Shaola Ren
      32. lamp_cairo7_1.png
        42 kB
        Shaola Ren
      33. lamp_cairo7_0.png
        36 kB
        Shaola Ren
      34. lamp_cairo.pdf
        37 kB
        Tilman Hausherr
      35. Kommunikationsbedingungen-Einlagen_FIDOR-Bank.pdf
        109 kB
        Tilman Hausherr
      36. HSBWHEEL.pdf
        3 kB
        Tilman Hausherr
      37. GWG060_Shading_x1a.pdf
        1.27 MB
        Tilman Hausherr
      38. GWG060_Shading_x1a_1.png
        15 kB
        Shaola Ren
      39. failedTest.rar
        333 kB
        Shaola Ren
      40. example_030.pdf
        28 kB
        Petr Slaby
      41. eci_altona-test-suite-v2_technical_H.pdf
        3.62 MB
        Tilman Hausherr
      42. eci_1-old.png
        68 kB
        Shaola Ren
      43. eci_1.png
        68 kB
        Shaola Ren
      44. DECAHED.pdf
        3 kB
        Tilman Hausherr
      45. crestron-p9.pdf
        1.67 MB
        Tilman Hausherr
      46. coons-nofunction-RGB.ps
        0.4 kB
        Tilman Hausherr
      47. coons-nofunction-RGB.pdf
        3 kB
        Tilman Hausherr
      48. coons-nofunction-Gray.ps
        0.4 kB
        Tilman Hausherr
      49. coons-nofunction-Gray.pdf
        3 kB
        Tilman Hausherr
      50. coons-nofunction-Duotone.ps
        1 kB
        Tilman Hausherr
      51. coons-nofunction-Duotone.pdf
        3 kB
        Tilman Hausherr
      52. coons-nofunction-CMYK.ps
        0.5 kB
        Tilman Hausherr
      53. coons-nofunction-CMYK.pdf
        3 kB
        Tilman Hausherr
      54. coons-function.ps
        0.6 kB
        Tilman Hausherr
      55. coons-function.pdf
        3 kB
        Tilman Hausherr
      56. coons4-function.ps
        1 kB
        Tilman Hausherr
      57. coons2-function.ps
        0.7 kB
        Tilman Hausherr
      58. coons2-function.pdf
        3 kB
        Tilman Hausherr
      59. CONICAL.pdf
        3 kB
        Tilman Hausherr
      60. CIB-coons-vs-tensormesh.pdf
        8 kB
        Tilman Hausherr
      61. CIB-coonsmesh.pdf
        7 kB
        Tilman Hausherr
      62. ch14.pdf
        774 kB
        Tilman Hausherr
      63. axsh02.pdf
        3 kB
        Shaola Ren
      64. axsh02_1_withoutBBox.png
        13 kB
        Shaola Ren
      65. axsh02_1_withBBox.png
        13 kB
        Shaola Ren
      66. asy-tensor-rainbow.pdf
        12 kB
        Tilman Hausherr
      67. asy-tensor.pdf
        15 kB
        Tilman Hausherr
      68. asy-coons-but-really-tensor.pdf
        12 kB
        Tilman Hausherr
      69. _mcafee-shadingtype7.pdf-1.png
        198 kB
        Tilman Hausherr
      70. _gwg060_shading_x1a.pdf-1.png
        133 kB
        Tilman Hausherr

        Activity

        Hide
        tilman Tilman Hausherr added a comment -

        Yes

        Show
        tilman Tilman Hausherr added a comment - Yes
        Hide
        jahewson John Hewson added a comment -

        Does this mean we can now follow up on PDFBOX-1991?

        Show
        jahewson John Hewson added a comment - Does this mean we can now follow up on PDFBOX-1991 ?
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1618474 from Tilman Hausherr in branch 'pdfbox/trunk'
        [ https://svn.apache.org/r1618474 ]

        PDFBOX-1915: removed the height parameter which isn't used anymore

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1618474 from Tilman Hausherr in branch 'pdfbox/trunk' [ https://svn.apache.org/r1618474 ] PDFBOX-1915 : removed the height parameter which isn't used anymore
        Hide
        xinshu Shaola Ren added a comment -

        Thanks for your trust, and thank you for giving me this opportunity to touch a field which is beyond my research but is a great interest of mine. I appreciated all the help that you and other people gave me.

        Show
        xinshu Shaola Ren added a comment - Thanks for your trust, and thank you for giving me this opportunity to touch a field which is beyond my research but is a great interest of mine. I appreciated all the help that you and other people gave me.
        Hide
        tilman Tilman Hausherr added a comment -

        As promised, I am now setting this to resolved. Thanks for all your work!

        If you have any additional ideas, you can either still comment here, or open a new issue. "Resolved" isn't the same as "Closed". The issue will be closed with the release of version 1.8.7 (in a few weeks).

        Btw, I'm pretty sure that I used all your code, except when I said I didn't. If there is any code or code change of yours that I didn't use and didn't tell why, then it means I accidentally missed it; please notify me if this is the case.

        Show
        tilman Tilman Hausherr added a comment - As promised, I am now setting this to resolved. Thanks for all your work! If you have any additional ideas, you can either still comment here, or open a new issue. "Resolved" isn't the same as "Closed". The issue will be closed with the release of version 1.8.7 (in a few weeks). Btw, I'm pretty sure that I used all your code, except when I said I didn't. If there is any code or code change of yours that I didn't use and didn't tell why, then it means I accidentally missed it; please notify me if this is the case.
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1617136 from Tilman Hausherr in branch 'pdfbox/trunk'
        [ https://svn.apache.org/r1617136 ]

        PDFBOX-1915: refactoring: move variable numberOfColorComponents up one level

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1617136 from Tilman Hausherr in branch 'pdfbox/trunk' [ https://svn.apache.org/r1617136 ] PDFBOX-1915 : refactoring: move variable numberOfColorComponents up one level
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1617135 from Tilman Hausherr in branch 'pdfbox/branches/1.8'
        [ https://svn.apache.org/r1617135 ]

        PDFBOX-1915: replace String.isEmpty()

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1617135 from Tilman Hausherr in branch 'pdfbox/branches/1.8' [ https://svn.apache.org/r1617135 ] PDFBOX-1915 : replace String.isEmpty()
        Hide
        tilman Tilman Hausherr added a comment -

        I fixed one thing that looked like a bug in 1.8 to me: PDSeparation.getNumberOfComponents() returned the number of components of the target, e.g. 3 for RGB or 4 for CMYK or whatever. After reading this my understanding of the Separation colorspace is that it is ONE value that is between black and a certain colorant, i.e. a color combination from ANOTHER colorspace. After using 1 instead of getNumberOfComponents() for PDSeparation I no longer get NPE. This happened for the ghostscript bugzilla 693027 file and the mozilla bugzilla 867751 file.

        Show
        tilman Tilman Hausherr added a comment - I fixed one thing that looked like a bug in 1.8 to me: PDSeparation.getNumberOfComponents() returned the number of components of the target, e.g. 3 for RGB or 4 for CMYK or whatever. After reading this my understanding of the Separation colorspace is that it is ONE value that is between black and a certain colorant, i.e. a color combination from ANOTHER colorspace. After using 1 instead of getNumberOfComponents() for PDSeparation I no longer get NPE. This happened for the ghostscript bugzilla 693027 file and the mozilla bugzilla 867751 file.
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1617132 from Tilman Hausherr in branch 'pdfbox/branches/1.8'
        [ https://svn.apache.org/r1617132 ]

        PDFBOX-1915: reformatted the package

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1617132 from Tilman Hausherr in branch 'pdfbox/branches/1.8' [ https://svn.apache.org/r1617132 ] PDFBOX-1915 : reformatted the package
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1617131 from Tilman Hausherr in branch 'pdfbox/branches/1.8'
        [ https://svn.apache.org/r1617131 ]

        PDFBOX-1915: backport shading changes from the trunk done in GSoC2014 by Shaola Ren to the 1.8 branch

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1617131 from Tilman Hausherr in branch 'pdfbox/branches/1.8' [ https://svn.apache.org/r1617131 ] PDFBOX-1915 : backport shading changes from the trunk done in GSoC2014 by Shaola Ren to the 1.8 branch
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1617113 from Tilman Hausherr in branch 'pdfbox/trunk'
        [ https://svn.apache.org/r1617113 ]

        PDFBOX-1915: fix typo

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1617113 from Tilman Hausherr in branch 'pdfbox/trunk' [ https://svn.apache.org/r1617113 ] PDFBOX-1915 : fix typo
        Hide
        tilman Tilman Hausherr added a comment -

        About the commit before the reformat: I renamed "CoonsTriangle" because that class is now used by all 4 triangle-based shadings. I didn't name it "Triangle" because I think there was a (now deleted) "Triangle" class in the past.

        That's it for refactoring (hopefully)... integration into 1.8 is next.

        While the svn mails might look wild, if you look at the actual code, you will still find everything you did Most of what I did was to move stuff to the base and to the intermediate class, so that there is no more double code.

        Show
        tilman Tilman Hausherr added a comment - About the commit before the reformat: I renamed "CoonsTriangle" because that class is now used by all 4 triangle-based shadings. I didn't name it "Triangle" because I think there was a (now deleted) "Triangle" class in the past. That's it for refactoring (hopefully)... integration into 1.8 is next. While the svn mails might look wild, if you look at the actual code, you will still find everything you did Most of what I did was to move stuff to the base and to the intermediate class, so that there is no more double code.
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1616964 from Tilman Hausherr in branch 'pdfbox/trunk'
        [ https://svn.apache.org/r1616964 ]

        PDFBOX-1915: reformat the package

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1616964 from Tilman Hausherr in branch 'pdfbox/trunk' [ https://svn.apache.org/r1616964 ] PDFBOX-1915 : reformat the package
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1616963 from Tilman Hausherr in branch 'pdfbox/trunk'
        [ https://svn.apache.org/r1616963 ]

        PDFBOX-1915: renamed "CoonsTriangle" (now used in types 4,5,6,7) to "ShadedTriangle"

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1616963 from Tilman Hausherr in branch 'pdfbox/trunk' [ https://svn.apache.org/r1616963 ] PDFBOX-1915 : renamed "CoonsTriangle" (now used in types 4,5,6,7) to "ShadedTriangle"
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1616959 from Tilman Hausherr in branch 'pdfbox/trunk'
        [ https://svn.apache.org/r1616959 ]

        PDFBOX-1915: more refactoring, pulled up convertToRGB and transformPoint

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1616959 from Tilman Hausherr in branch 'pdfbox/trunk' [ https://svn.apache.org/r1616959 ] PDFBOX-1915 : more refactoring, pulled up convertToRGB and transformPoint
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1616942 from Tilman Hausherr in branch 'pdfbox/trunk'
        [ https://svn.apache.org/r1616942 ]

        PDFBOX-1915: created abstract shading resource type for common stuff to 4,5,6,7; more refactoring

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1616942 from Tilman Hausherr in branch 'pdfbox/trunk' [ https://svn.apache.org/r1616942 ] PDFBOX-1915 : created abstract shading resource type for common stuff to 4,5,6,7; more refactoring
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1616918 from Tilman Hausherr in branch 'pdfbox/trunk'
        [ https://svn.apache.org/r1616918 ]

        PDFBOX-1915: simplified BBox handling; more refactoring

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1616918 from Tilman Hausherr in branch 'pdfbox/trunk' [ https://svn.apache.org/r1616918 ] PDFBOX-1915 : simplified BBox handling; more refactoring
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1616907 from Tilman Hausherr in branch 'pdfbox/trunk'
        [ https://svn.apache.org/r1616907 ]

        PDFBOX-1915: forgot to delete declaration of variable that is now in base class

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1616907 from Tilman Hausherr in branch 'pdfbox/trunk' [ https://svn.apache.org/r1616907 ] PDFBOX-1915 : forgot to delete declaration of variable that is now in base class
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1616895 from Tilman Hausherr in branch 'pdfbox/trunk'
        [ https://svn.apache.org/r1616895 ]

        PDFBOX-1915: refactoring: base class and intermediate class (for types 4 5 6 7) to get rid of double code

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1616895 from Tilman Hausherr in branch 'pdfbox/trunk' [ https://svn.apache.org/r1616895 ] PDFBOX-1915 : refactoring: base class and intermediate class (for types 4 5 6 7) to get rid of double code
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1616843 from Tilman Hausherr in branch 'pdfbox/trunk'
        [ https://svn.apache.org/r1616843 ]

        PDFBOX-1915: some minor reformat / rename / refactor

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1616843 from Tilman Hausherr in branch 'pdfbox/trunk' [ https://svn.apache.org/r1616843 ] PDFBOX-1915 : some minor reformat / rename / refactor
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1616833 from Tilman Hausherr in branch 'pdfbox/trunk'
        [ https://svn.apache.org/r1616833 ]

        PDFBOX-1915: delete class that is no longer used

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1616833 from Tilman Hausherr in branch 'pdfbox/trunk' [ https://svn.apache.org/r1616833 ] PDFBOX-1915 : delete class that is no longer used
        Hide
        tilman Tilman Hausherr added a comment -

        I did some tests without running other stuff on the pc and the result is:

        • at 96dpi, trityp4, decahed and pattern is about the same
        • at 300dpi, pattern is about the same, but trityp4 and decahed are slower
        • ch14 p15 and p20 are about the same at 96dpi, and slightly faster at 300dpi.
          trityp4 and decahed have large surfaces, so the hash map might perform poorly.

        I've decided to commit your changes for two reasons: 1) it will allow more common code, 2) there are some slight differences in the rendering of the ch14 file - your implementation has slightly less white artifacts than mine. Likely because I didn't bother about lines. I did think about it, but dropped the idea at that time because I thought that a line doesn't have a surface.

        Show
        tilman Tilman Hausherr added a comment - I did some tests without running other stuff on the pc and the result is: at 96dpi, trityp4, decahed and pattern is about the same at 300dpi, pattern is about the same, but trityp4 and decahed are slower ch14 p15 and p20 are about the same at 96dpi, and slightly faster at 300dpi. trityp4 and decahed have large surfaces, so the hash map might perform poorly. I've decided to commit your changes for two reasons: 1) it will allow more common code, 2) there are some slight differences in the rendering of the ch14 file - your implementation has slightly less white artifacts than mine. Likely because I didn't bother about lines. I did think about it, but dropped the idea at that time because I thought that a line doesn't have a surface.
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1616831 from Tilman Hausherr in branch 'pdfbox/trunk'
        [ https://svn.apache.org/r1616831 ]

        PDFBOX-1915: use the hash maps of types 6 and 7 for types 4 and 5, as done by Shaola Ren in GSoC2014

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1616831 from Tilman Hausherr in branch 'pdfbox/trunk' [ https://svn.apache.org/r1616831 ] PDFBOX-1915 : use the hash maps of types 6 and 7 for types 4 and 5, as done by Shaola Ren in GSoC2014
        Hide
        tilman Tilman Hausherr added a comment -

        Some intermediate news: I replaced the five files mentioned in your commit 59dbb8e with the current versions and did the tests, and all is identical except one file ( https://bugzilla.mozilla.org/show_bug.cgi?id=858109 ) where there is a difference of one line that is one pixel wide: the table is missing a width of one pixel on top. But this could as well be a rounding problem - who knows. Next thing for me is to do speed measurements. I did some non scientitic measurement and they are inconclusive - some are identical, some slightly slower, and one is identical at 96dpi but much slower at 300dpi.

        Show
        tilman Tilman Hausherr added a comment - Some intermediate news: I replaced the five files mentioned in your commit 59dbb8e with the current versions and did the tests, and all is identical except one file ( https://bugzilla.mozilla.org/show_bug.cgi?id=858109 ) where there is a difference of one line that is one pixel wide: the table is missing a width of one pixel on top. But this could as well be a rounding problem - who knows. Next thing for me is to do speed measurements. I did some non scientitic measurement and they are inconclusive - some are identical, some slightly slower, and one is identical at 96dpi but much slower at 300dpi.
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1616564 from Tilman Hausherr in branch 'pdfbox/trunk'
        [ https://svn.apache.org/r1616564 ]

        PDFBOX-1915: fix javadocs, as done by Shaola Ren in GSoC2014

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1616564 from Tilman Hausherr in branch 'pdfbox/trunk' [ https://svn.apache.org/r1616564 ] PDFBOX-1915 : fix javadocs, as done by Shaola Ren in GSoC2014
        Hide
        tilman Tilman Hausherr added a comment - - edited

        I found a new file:
        http://bugs.ghostscript.com/show_bug.cgi?id=694585
        has type 4 shadings

        oops, no, I misread the bugzilla entry. The shadings are type 2, 3 and 7.

        Show
        tilman Tilman Hausherr added a comment - - edited I found a new file: http://bugs.ghostscript.com/show_bug.cgi?id=694585 has type 4 shadings oops, no, I misread the bugzilla entry. The shadings are type 2, 3 and 7.
        Hide
        xinshu Shaola Ren added a comment -

        Take your time.
        I tried to use the floodfill algorithm to generate the points inside a triangle for type 4 and 5 shading, theoretically when knowing the edge and the seed point, it should be faster. But for our current situation, marking out the edge of a triangle consumes more time, so the performance is not good as expected. That part of code is still in the GouraudShadingContext (https://bitbucket.org/xinshu/pdfbox) but commented out, please don't waste time on it, I left them there as it may be convenient for me to make some further change.

        Show
        xinshu Shaola Ren added a comment - Take your time. I tried to use the floodfill algorithm to generate the points inside a triangle for type 4 and 5 shading, theoretically when knowing the edge and the seed point, it should be faster. But for our current situation, marking out the edge of a triangle consumes more time, so the performance is not good as expected. That part of code is still in the GouraudShadingContext ( https://bitbucket.org/xinshu/pdfbox ) but commented out, please don't waste time on it, I left them there as it may be convenient for me to make some further change.
        Hide
        tilman Tilman Hausherr added a comment - - edited

        I just committed your changes to types 1,4,5,6 and 7; for 4 and 5 I only used the BBox and deviceBounds changes, i.e. the optimizing changes aren't yet part of it, this will be done later. I wanted to have a commit closer to your own code first, before testing your optimizing changes again, now enhanced with deviceBounds.

        Show
        tilman Tilman Hausherr added a comment - - edited I just committed your changes to types 1,4,5,6 and 7; for 4 and 5 I only used the BBox and deviceBounds changes, i.e. the optimizing changes aren't yet part of it, this will be done later. I wanted to have a commit closer to your own code first, before testing your optimizing changes again, now enhanced with deviceBounds.
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1616329 from Tilman Hausherr in branch 'pdfbox/trunk'
        [ https://svn.apache.org/r1616329 ]

        PDFBOX-1915: use PaintContext deviceBounds and BBox for types 1,4,5,6,7, as done by Shaola Ren in GSoC2014

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1616329 from Tilman Hausherr in branch 'pdfbox/trunk' [ https://svn.apache.org/r1616329 ] PDFBOX-1915 : use PaintContext deviceBounds and BBox for types 1,4,5,6,7, as done by Shaola Ren in GSoC2014
        Hide
        tilman Tilman Hausherr added a comment -

        My code (identical to the trunk) produces the "good" image. The most likely explanation is that I made a change in one of the three type 4 / 5 related files, but that I forgot to mention it here. At the beginning of the project, the eci file almost not worked at all, i.e. 2/3 of the image were blank. My sample "good" rendering (except for the stripes) for my diff tests has a date June 29, this means that I must have been somewhat satisfied with the rendering before that date (there's an entry on June 20 telling that the eci file now looks nice).

        In other news: I tested your uncommitted changes for types 6 and 7 and it works fine. More later this week....

        Show
        tilman Tilman Hausherr added a comment - My code (identical to the trunk) produces the "good" image. The most likely explanation is that I made a change in one of the three type 4 / 5 related files, but that I forgot to mention it here. At the beginning of the project, the eci file almost not worked at all, i.e. 2/3 of the image were blank. My sample "good" rendering (except for the stripes) for my diff tests has a date June 29, this means that I must have been somewhat satisfied with the rendering before that date (there's an entry on June 20 telling that the eci file now looks nice). In other news: I tested your uncommitted changes for types 6 and 7 and it works fine. More later this week....
        Hide
        xinshu Shaola Ren added a comment -

        I didn't mean there is a difference in my before and after code, I meant your code gave different result from mine for the eci.pdf, but the same for all other type 4 & 5 shading test files.
        the eci_1-old was got before I edited the type 4 & 5 shading, the eci_1 is got from my current code. The one rectangle lacked one corner in eci_1-old is type 4, the one below is type 5.

        Show
        xinshu Shaola Ren added a comment - I didn't mean there is a difference in my before and after code, I meant your code gave different result from mine for the eci.pdf, but the same for all other type 4 & 5 shading test files. the eci_1-old was got before I edited the type 4 & 5 shading, the eci_1 is got from my current code. The one rectangle lacked one corner in eci_1-old is type 4, the one below is type 5.
        Hide
        tilman Tilman Hausherr added a comment -

        There should be a bug in the original code for type 4 shading

        Do you mean the type 4 or type 5 code? In the type45.pdf file you wrote about the type 5 rendering. When I tested your code at that time I had no image differences between before and after but I will test again.

        Could you attach the rendered files, i.e. one that is "good" and one that is "bad"?

        The eci file is a weird piece of work - when looking at it with Adobe Reader, there are many differences between left and right. And then there are some color differences between Adobe and PDFBox.

        Show
        tilman Tilman Hausherr added a comment - There should be a bug in the original code for type 4 shading Do you mean the type 4 or type 5 code? In the type45.pdf file you wrote about the type 5 rendering. When I tested your code at that time I had no image differences between before and after but I will test again. Could you attach the rendered files, i.e. one that is "good" and one that is "bad"? The eci file is a weird piece of work - when looking at it with Adobe Reader, there are many differences between left and right. And then there are some color differences between Adobe and PDFBox.
        Hide
        xinshu Shaola Ren added a comment -

        Thanks.

        There should be a bug in the original code for type 4 shading, the type 4 rectangle in the eci file lacks one corner, which is fixed in the hashtable version, but as these two versions use different sequence to generate the trianglelist, I don't know where the bug happens in the original code.

        Besides the BBox boundary clipping, I also made some change for type 6 & 7 shading, the reason is stated in the item 2 in type45.pdf.

        Yes, I know the problem for the the Kerstin Upmeyer frog file, which I mentioned in the item 5 in type45.pdf, however not specifically, this case also happens when rendering the lamp_cairo7.pdf at 300 dpi. It's kind of hard to fix for me now, to fix this I think a better mesh generating algorithm or a better triangle's points generating algorithm is needed or both. But, I will think about it.

        Thanks for your suggestion to prepare the stuff to be uploaded to google, I'll take it.

        Show
        xinshu Shaola Ren added a comment - Thanks. There should be a bug in the original code for type 4 shading, the type 4 rectangle in the eci file lacks one corner, which is fixed in the hashtable version, but as these two versions use different sequence to generate the trianglelist, I don't know where the bug happens in the original code. Besides the BBox boundary clipping, I also made some change for type 6 & 7 shading, the reason is stated in the item 2 in type45.pdf. Yes, I know the problem for the the Kerstin Upmeyer frog file, which I mentioned in the item 5 in type45.pdf, however not specifically, this case also happens when rendering the lamp_cairo7.pdf at 300 dpi. It's kind of hard to fix for me now, to fix this I think a better mesh generating algorithm or a better triangle's points generating algorithm is needed or both. But, I will think about it. Thanks for your suggestion to prepare the stuff to be uploaded to google, I'll take it.
        Hide
        tilman Tilman Hausherr added a comment -

        Yes I will set this to resolved before August 18, and yes you achieved the passed criteria. Indeed, there is no need for more documentation / tests. I'd like to say thank you on behalf of the group. Whats next to do?

        For me:

        • review again your changes for 4 and 5, I see I ignored a change about the boundaries, maybe test whether that alone can speed up. And think again about that part that I didn't commit, reread the type45.pdf file.
        • BBox for types 4 and 5
        • DRY refactoring re: BBox
        • Take all the changes and commit them to the 1.8 branch, which is the public release
        • set to resolved
          I will do all this until the end of the weekend.

        For you:

        • please have a look at the rendering of the Kerstin Upmeyer frog file ( http://kupmeyer.com/wp-content/uploads/2012/02/K_UPMEYER_SPRING10.pdf ), there are some colored spots when rendering. (I don't mind the white spots) You may have mentioned this somewhere but I can't find it.
        • upload your stuff to google. The easiest is probably to just upload the whole shading package in a zip, maybe along with a PDF that has this issue
        Show
        tilman Tilman Hausherr added a comment - Yes I will set this to resolved before August 18, and yes you achieved the passed criteria. Indeed, there is no need for more documentation / tests. I'd like to say thank you on behalf of the group . Whats next to do? For me: review again your changes for 4 and 5, I see I ignored a change about the boundaries, maybe test whether that alone can speed up. And think again about that part that I didn't commit, reread the type45.pdf file. BBox for types 4 and 5 DRY refactoring re: BBox Take all the changes and commit them to the 1.8 branch, which is the public release set to resolved I will do all this until the end of the weekend. For you: please have a look at the rendering of the Kerstin Upmeyer frog file ( http://kupmeyer.com/wp-content/uploads/2012/02/K_UPMEYER_SPRING10.pdf ), there are some colored spots when rendering. (I don't mind the white spots) You may have mentioned this somewhere but I can't find it. upload your stuff to google. The easiest is probably to just upload the whole shading package in a zip, maybe along with a PDF that has this issue
        Hide
        xinshu Shaola Ren added a comment -

        We are kind of doing duplicated work now, and as it's approaching the suggested pencils down date Aug. 11, I think I should stop working on this project at some moment, although there is no need to write additional tests and documents which are suggested on the melange website for the left time. The main aim of this project is more or less achieved, I think, the optional task is vague, there is always space to make a code better. I'd like to set this thread as resolved at the end of this project, however, you can have your own decision. If there are new problems coming out, I think creating new issues is better than working under this thread, and this will also give other people opportunities to contribute to this software on this topic. And hopefully, I achieved the passed criteria, which I think I should.

        Show
        xinshu Shaola Ren added a comment - We are kind of doing duplicated work now, and as it's approaching the suggested pencils down date Aug. 11, I think I should stop working on this project at some moment, although there is no need to write additional tests and documents which are suggested on the melange website for the left time. The main aim of this project is more or less achieved, I think, the optional task is vague, there is always space to make a code better. I'd like to set this thread as resolved at the end of this project, however, you can have your own decision. If there are new problems coming out, I think creating new issues is better than working under this thread, and this will also give other people opportunities to contribute to this software on this topic. And hopefully, I achieved the passed criteria, which I think I should.
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1615722 from Tilman Hausherr in branch 'pdfbox/trunk'
        [ https://svn.apache.org/r1615722 ]

        PDFBOX-1915: fix BBox if coordinates are inverted; add BBox to shading 1,3,6,7 as suggested by Shaola Ren; drop empty BBox because of trouble with eci file

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1615722 from Tilman Hausherr in branch 'pdfbox/trunk' [ https://svn.apache.org/r1615722 ] PDFBOX-1915 : fix BBox if coordinates are inverted; add BBox to shading 1,3,6,7 as suggested by Shaola Ren; drop empty BBox because of trouble with eci file
        Hide
        tilman Tilman Hausherr added a comment -

        The fidor file doesn't render correctly. The problem is that while the BBox coordinates are correct (minX, minY, maxX, maxY) this may no longer be the case after the transforms... and you (and I) missed a warning sign in your code (indices 3 1 for Y vs 0 2 for X):

         if (currentY < bboxTab[3] || currentY > bboxTab[1])
         if (currentX < bboxTab[0] || currentX > bboxTab[2])
        

        Anyway, I changed the code so that min and max values are chosen from the transform results and now all is OK. I tested type 1 and it fails the eci file because the BBox is empty after the transforms. I calculated the transform by hand and it is really empty. Thus I suspect that Adobe ignores empty BBoxes. I thus ignore an empty BBox, but put out a warning to find out easier whether this is a wrong decision. There is now identical code at several places; this will have to be refactored, maybe by using a common base class for all shadings.

        Show
        tilman Tilman Hausherr added a comment - The fidor file doesn't render correctly. The problem is that while the BBox coordinates are correct (minX, minY, maxX, maxY) this may no longer be the case after the transforms... and you (and I) missed a warning sign in your code (indices 3 1 for Y vs 0 2 for X): if (currentY < bboxTab[3] || currentY > bboxTab[1]) if (currentX < bboxTab[0] || currentX > bboxTab[2]) Anyway, I changed the code so that min and max values are chosen from the transform results and now all is OK. I tested type 1 and it fails the eci file because the BBox is empty after the transforms. I calculated the transform by hand and it is really empty. Thus I suspect that Adobe ignores empty BBoxes. I thus ignore an empty BBox, but put out a warning to find out easier whether this is a wrong decision. There is now identical code at several places; this will have to be refactored, maybe by using a common base class for all shadings.
        Hide
        tilman Tilman Hausherr added a comment - - edited

        The change I just made deals with larger domains (see the attached Shading2Function2LargeDomain* files), I got a rendered image with stripes before the change. The cause was that the function was returning negative color values or color values larger than 1. Luckily the fix is not only straightforward, but also in the spec:

        If the value returned by the function for a given colour component is out of range, it shall be adjusted to the nearest valid value.

        Show
        tilman Tilman Hausherr added a comment - - edited The change I just made deals with larger domains (see the attached Shading2Function2LargeDomain* files), I got a rendered image with stripes before the change. The cause was that the function was returning negative color values or color values larger than 1. Luckily the fix is not only straightforward, but also in the spec: If the value returned by the function for a given colour component is out of range, it shall be adjusted to the nearest valid value.
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1615162 from Tilman Hausherr in branch 'pdfbox/branches/1.8'
        [ https://svn.apache.org/r1615162 ]

        PDFBOX-1915: adjust out of range function result colors to the nearest valid value

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1615162 from Tilman Hausherr in branch 'pdfbox/branches/1.8' [ https://svn.apache.org/r1615162 ] PDFBOX-1915 : adjust out of range function result colors to the nearest valid value
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1615159 from Tilman Hausherr in branch 'pdfbox/trunk'
        [ https://svn.apache.org/r1615159 ]

        PDFBOX-1915: adjust out of range function result colors to the nearest valid value

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1615159 from Tilman Hausherr in branch 'pdfbox/trunk' [ https://svn.apache.org/r1615159 ] PDFBOX-1915 : adjust out of range function result colors to the nearest valid value
        Hide
        tilman Tilman Hausherr added a comment -

        From the spec:

        Blend circles extending beyond the starting circle shall be painted in the same colour defined by the shading dictionary’s Function entry for the starting circle (t = t0, s = 0.0). Blend circles extending beyond the ending circle shall be painted in the colour defined for the ending circle (t = t1, s = 1.0).

        My intepretation of this that we should disregard an extend option if a radius is 0. Now not only the shaded bullet file from PDFBOX-2117 is correct, but also the leaf-covered branch of page 739 (L.14) of the spec, for the first time, and no radial shading files are different. Btw the source code shown on page 188 is NOT the actual pdf code used in the PDF file.

        Show
        tilman Tilman Hausherr added a comment - From the spec: Blend circles extending beyond the starting circle shall be painted in the same colour defined by the shading dictionary’s Function entry for the starting circle (t = t0, s = 0.0). Blend circles extending beyond the ending circle shall be painted in the colour defined for the ending circle (t = t1, s = 1.0). My intepretation of this that we should disregard an extend option if a radius is 0. Now not only the shaded bullet file from PDFBOX-2117 is correct, but also the leaf-covered branch of page 739 (L.14) of the spec, for the first time, and no radial shading files are different. Btw the source code shown on page 188 is NOT the actual pdf code used in the PDF file.
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1615145 from Tilman Hausherr in branch 'pdfbox/trunk'
        [ https://svn.apache.org/r1615145 ]

        PDFBOX-1915: extend radial shadings only if radius > 0

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1615145 from Tilman Hausherr in branch 'pdfbox/trunk' [ https://svn.apache.org/r1615145 ] PDFBOX-1915 : extend radial shadings only if radius > 0
        Hide
        tilman Tilman Hausherr added a comment -

        Kommunikationsbedingungen-Einlagen_FIDOR-Bank.pdf has a BBox for radial shading.

        Show
        tilman Tilman Hausherr added a comment - Kommunikationsbedingungen-Einlagen_FIDOR-Bank.pdf has a BBox for radial shading.
        Hide
        tilman Tilman Hausherr added a comment -

        Yes, you're right, and I was aware of that, but useful code gets committed immediately

        Show
        tilman Tilman Hausherr added a comment - Yes, you're right, and I was aware of that, but useful code gets committed immediately
        Hide
        xinshu Shaola Ren added a comment -

        That's because most of the test files don't have this optional field BBox except the file I attached. I thought you wouldn't commit it now as all other shading types need to have this change as well and there should be more changes, those small commits create too many separate issues which could be grouped together and be committed once. Anyway, thanks to commit this change.

        Show
        xinshu Shaola Ren added a comment - That's because most of the test files don't have this optional field BBox except the file I attached. I thought you wouldn't commit it now as all other shading types need to have this change as well and there should be more changes, those small commits create too many separate issues which could be grouped together and be committed once. Anyway, thanks to commit this change.
        Hide
        tilman Tilman Hausherr added a comment -

        I committed your change, but I modified the variable names. We don't start with a capital letter, except with some constants who then are all caps. Thanks for this nice quick change. Funny thing is that the only effect it had in my test images was your file. Maybe because the PDF spec has operators for clipping that are more known.

        Show
        tilman Tilman Hausherr added a comment - I committed your change, but I modified the variable names. We don't start with a capital letter, except with some constants who then are all caps. Thanks for this nice quick change. Funny thing is that the only effect it had in my test images was your file. Maybe because the PDF spec has operators for clipping that are more known.
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1614959 from Tilman Hausherr in branch 'pdfbox/trunk'
        [ https://svn.apache.org/r1614959 ]

        PDFBOX-1915: implemented BBox clipping by Shaola Ren as part of GSoC2014

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1614959 from Tilman Hausherr in branch 'pdfbox/trunk' [ https://svn.apache.org/r1614959 ] PDFBOX-1915 : implemented BBox clipping by Shaola Ren as part of GSoC2014
        Hide
        tilman Tilman Hausherr added a comment -

        Thanks for the BBox implementation, I know this was missing, but never thought it would be important, and for some reason I never noticed that the axsh file had been wrong all the time. I will commit that change later tonight or tomorrow.

        Show
        tilman Tilman Hausherr added a comment - Thanks for the BBox implementation, I know this was missing, but never thought it would be important, and for some reason I never noticed that the axsh file had been wrong all the time. I will commit that change later tonight or tomorrow.
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1614946 from Tilman Hausherr in branch 'pdfbox/trunk'
        [ https://svn.apache.org/r1614946 ]

        PDFBOX-1915: intermediate variable must be compared to 0..1 range and not the /Domain range

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1614946 from Tilman Hausherr in branch 'pdfbox/trunk' [ https://svn.apache.org/r1614946 ] PDFBOX-1915 : intermediate variable must be compared to 0..1 range and not the /Domain range
        Hide
        xinshu Shaola Ren added a comment -

        All of the shading context classes don't consider the BBox, the attached axsh02.pdf could not be rendered correctly without considering BBox, see the two attached image axsh02_1_withBBox and axsh02_1_withoutBBox. This means I need to apply the similar change to other shading context besides type 2. Another potential problem for type 6 & 7 is that if something happens like the item 2 in the type45.pdf, the device bound needs to be passed to the context class.

        Show
        xinshu Shaola Ren added a comment - All of the shading context classes don't consider the BBox, the attached axsh02.pdf could not be rendered correctly without considering BBox, see the two attached image axsh02_1_withBBox and axsh02_1_withoutBBox. This means I need to apply the similar change to other shading context besides type 2. Another potential problem for type 6 & 7 is that if something happens like the item 2 in the type45.pdf, the device bound needs to be passed to the context class.
        Hide
        renshaola@163.com 任少辣 added a comment -

        Hello Tilman,
        Thanks.
        I will.

        I wish, but sadly, no.

        Best,
        Shaola

        At 2014-07-31 00:56:38, "Tilman Hausherr (JIRA)" <jira@apache.org> wrote:

        Show
        renshaola@163.com 任少辣 added a comment - Hello Tilman, Thanks. I will. I wish, but sadly, no. Best, Shaola At 2014-07-31 00:56:38, "Tilman Hausherr (JIRA)" <jira@apache.org> wrote:
        Hide
        tilman Tilman Hausherr added a comment -

        I think I understand some, maybe most of your text, and here are my thoughts

        • the shading-2-4-idMatrix file can't be optimized by pre-calculating, as long as the clipping region isn't taken into account. However I doubt that gouraud (and coons and tensor) shadings will be clipped much in the real world so don't bother.
        • a single gouraud triangle can't be optimized with tables because all colors are different
          Sadly, all gouraud files I have are test files so they are not realistic. Even the ch14 file of prof. Casselman is a test file, sortof.

        There are two things that could be done:

        • please have a look at the algorithms for gouraud shadings whether they are fast enough, I mean whether the methods contains() and getArea() and getWeights() are efficient enough. I remember that there are several methods to check whether a point is in a triangle
        • do you have high speed internet where you are now? I.e. 50 MBit/s or more? If yes, then I have an idea related to
          http://digitalcorpora.org/corp/nps/files/govdocs1/zipfiles/ , however email me first.

        If you have some ideas to try on the existing code, sure, go ahead. Even if types 4 and 5 can't be optimized, this GSoC project is very successful thanks to you: you did types 6 and 7, and you much optimized the "real world" shading types 2 and 3.

        Show
        tilman Tilman Hausherr added a comment - I think I understand some, maybe most of your text, and here are my thoughts the shading-2-4-idMatrix file can't be optimized by pre-calculating, as long as the clipping region isn't taken into account. However I doubt that gouraud (and coons and tensor) shadings will be clipped much in the real world so don't bother. a single gouraud triangle can't be optimized with tables because all colors are different Sadly, all gouraud files I have are test files so they are not realistic. Even the ch14 file of prof. Casselman is a test file, sortof. There are two things that could be done: please have a look at the algorithms for gouraud shadings whether they are fast enough, I mean whether the methods contains() and getArea() and getWeights() are efficient enough. I remember that there are several methods to check whether a point is in a triangle do you have high speed internet where you are now? I.e. 50 MBit/s or more? If yes, then I have an idea related to http://digitalcorpora.org/corp/nps/files/govdocs1/zipfiles/ , however email me first. If you have some ideas to try on the existing code, sure, go ahead. Even if types 4 and 5 can't be optimized, this GSoC project is very successful thanks to you: you did types 6 and 7, and you much optimized the "real world" shading types 2 and 3.
        Hide
        tilman Tilman Hausherr added a comment -

        Here are two type5 shading files. I'll work through your text tonight.

        Show
        tilman Tilman Hausherr added a comment - Here are two type5 shading files. I'll work through your text tonight.
        Hide
        xinshu Shaola Ren added a comment -

        It's a long story to explain some issues clear, so I put them in this type45.pdf file, you can have a look at it.

        Show
        xinshu Shaola Ren added a comment - It's a long story to explain some issues clear, so I put them in this type45.pdf file, you can have a look at it.
        Hide
        xinshu Shaola Ren added a comment -

        Thanks, bad news is good news, it is helpful to make the code better. However, there is no guarantee that I will always do the correct thing.

        Show
        xinshu Shaola Ren added a comment - Thanks, bad news is good news, it is helpful to make the code better. However, there is no guarantee that I will always do the correct thing.
        Hide
        tilman Tilman Hausherr added a comment -

        Sorry for bringing bad news, but three other files I tested have no improvement (decahed and trityp4), or worse - the file pattern-shading-2-4-idMatrix.pdf displays in about 5 seconds at 96dpi with the current trunk; with your change, I stopped counting at 60 seconds, so there must be a problem somewhere.

        I understand your explanation about the donut this way - if the triangles are too small, there won't be many different points in a triangle with the same color. However that explanation probably won't apply to the two files I mentioned first (which are test files from Adobe). And yes, I agree that our design with PaintContext and getRaster() shows its weakness with files like ch14.pdf.

        About the stripes in the eci file: this is a problem in axial shading. It is either the color space (some colorspaces are improperly converted, see PDFBOX-2142), or an "exotic" transformation matrix, see also PDFBOX-2217 )

        Show
        tilman Tilman Hausherr added a comment - Sorry for bringing bad news, but three other files I tested have no improvement (decahed and trityp4), or worse - the file pattern-shading-2-4-idMatrix.pdf displays in about 5 seconds at 96dpi with the current trunk; with your change, I stopped counting at 60 seconds, so there must be a problem somewhere. I understand your explanation about the donut this way - if the triangles are too small, there won't be many different points in a triangle with the same color. However that explanation probably won't apply to the two files I mentioned first (which are test files from Adobe). And yes, I agree that our design with PaintContext and getRaster() shows its weakness with files like ch14.pdf. About the stripes in the eci file: this is a problem in axial shading. It is either the color space (some colorspaces are improperly converted, see PDFBOX-2142 ), or an "exotic" transformation matrix, see also PDFBOX-2217 )
        Hide
        xinshu Shaola Ren added a comment -

        I modified type 4 & 5 shading, for the eci file, type 4 gets right, type 5 performs a misordered problem, I will fix this later.

        I didn't write the corresponding java doc for those two types shading, they may need further change.

        For the doughnut image in the chap14, the performance is not improved, the reason is that the hash table can save time in one instance of a shading context, when the size of the triangle list in this shading context is small, the hash table doesn't have an obvious advantage over a simple arraylist. The doughnut image is composed by over 800 type 4 shading instances, each instance only contains a small data stream. Thus the time consumption is mostly from the frequent call of PDShadingType4, I think this is an issue outside the shading package, in order to reduce the rendering time for this doughnut image, modification in this shading context is not much helpful.

        For the eci file, I cannot simply locate the shading type for the rectangle has two thin stripes which are not correct now, there should be some problem in the corresponding shading, I'll work on this later as well.

        The code is updated in the usual place.

        Show
        xinshu Shaola Ren added a comment - I modified type 4 & 5 shading, for the eci file, type 4 gets right, type 5 performs a misordered problem, I will fix this later. I didn't write the corresponding java doc for those two types shading, they may need further change. For the doughnut image in the chap14, the performance is not improved, the reason is that the hash table can save time in one instance of a shading context, when the size of the triangle list in this shading context is small, the hash table doesn't have an obvious advantage over a simple arraylist. The doughnut image is composed by over 800 type 4 shading instances, each instance only contains a small data stream. Thus the time consumption is mostly from the frequent call of PDShadingType4, I think this is an issue outside the shading package, in order to reduce the rendering time for this doughnut image, modification in this shading context is not much helpful. For the eci file, I cannot simply locate the shading type for the rectangle has two thin stripes which are not correct now, there should be some problem in the corresponding shading, I'll work on this later as well. The code is updated in the usual place.
        Hide
        tilman Tilman Hausherr added a comment -

        Sure, go ahead. The more common code, the better.

        Show
        tilman Tilman Hausherr added a comment - Sure, go ahead. The more common code, the better.
        Hide
        xinshu Shaola Ren added a comment -

        Thanks for writing all those tests. I am working on type 4&5 shading, they may need more changes. I may use my CoonsTriangle to substitute your GouraudTriangle, as the CoonsTriangle has more methods to deal with the degeneracy and is more suitable to do the pixel calculation. And then, I may change the name "CoonsTriangle" to "Trianlge" or "MeshTriangle" as it is actually a triangle or a degenerated triangle. Then the method to get the pixel table will be more or less similar to type 6&7 shading.

        Show
        xinshu Shaola Ren added a comment - Thanks for writing all those tests. I am working on type 4&5 shading, they may need more changes. I may use my CoonsTriangle to substitute your GouraudTriangle, as the CoonsTriangle has more methods to deal with the degeneracy and is more suitable to do the pixel calculation. And then, I may change the name "CoonsTriangle" to "Trianlge" or "MeshTriangle" as it is actually a triangle or a degenerated triangle. Then the method to get the pixel table will be more or less similar to type 6&7 shading.
        Hide
        tilman Tilman Hausherr added a comment - - edited

        I took your code of PDFunctionType2 a step further (initialize all in constructor) and committed this in rev 1611163 and 1611167. However I don't expect much speed improvement - on the day I ran the profiler, the share of PDFunctiontype2 went to 0% after the change in getN().

        Show
        tilman Tilman Hausherr added a comment - - edited I took your code of PDFunctionType2 a step further (initialize all in constructor) and committed this in rev 1611163 and 1611167. However I don't expect much speed improvement - on the day I ran the profiler, the share of PDFunctiontype2 went to 0% after the change in getN().
        Hide
        tilman Tilman Hausherr added a comment -

        I committed the optimization of PatchMeshesShadingContext and removed the ColorRGB class in rev 1611159. The total test time got down to 12 minutes (related to optimizations of 3, 6 and 7) but I wasn't watching/recording TV. With TV, it went up to 15 minutes.

        Show
        tilman Tilman Hausherr added a comment - I committed the optimization of PatchMeshesShadingContext and removed the ColorRGB class in rev 1611159. The total test time got down to 12 minutes (related to optimizations of 3, 6 and 7) but I wasn't watching/recording TV. With TV, it went up to 15 minutes.
        Hide
        tilman Tilman Hausherr added a comment -

        About

        Technically, I can use a 2D array to store the pixels' color instead of a hashmap in type 6&7 shading

        IMHO we can leave it as it is now, i.e. with the hash map. I'll review & commit the changes on 6 & 7 later today.

        Show
        tilman Tilman Hausherr added a comment - About Technically, I can use a 2D array to store the pixels' color instead of a hashmap in type 6&7 shading IMHO we can leave it as it is now, i.e. with the hash map. I'll review & commit the changes on 6 & 7 later today.
        Hide
        tilman Tilman Hausherr added a comment -

        I committed your radial shading optimizations in rev 1610917 in the trunk. I didn't measure the exact times, but PDFBOX-1764 and PDFBOX-1416 are much much faster.

        Show
        tilman Tilman Hausherr added a comment - I committed your radial shading optimizations in rev 1610917 in the trunk. I didn't measure the exact times, but PDFBOX-1764 and PDFBOX-1416 are much much faster.
        Hide
        xinshu Shaola Ren added a comment -

        Thanks. Hash table is a powerful tool when it is used in the right way.

        Show
        xinshu Shaola Ren added a comment - Thanks. Hash table is a powerful tool when it is used in the right way.
        Hide
        tilman Tilman Hausherr added a comment -

        Btw one advantage of your type 6 and 7 optimizations is that my test suite (that renders many files, but includes the GSoC test files) no longer takes over 30 minutes, it is now done in 18 minutes

        Show
        tilman Tilman Hausherr added a comment - Btw one advantage of your type 6 and 7 optimizations is that my test suite (that renders many files, but includes the GSoC test files) no longer takes over 30 minutes, it is now done in 18 minutes
        Hide
        tilman Tilman Hausherr added a comment -

        I committed your optimizations for types 6 and 7 in rev 1609410 with the following modifications:

        • I changed calDeg to calcDeg (you missed that one)
        • I didn't use the changes in Patch.java, IMHO 1e-1 takes longer to understand than 0.001
        • I didn't commit the changes for type 2 yet because I will review / test them first. Btw the "someone else" author is Andreas Lehmkühler.
          I included the round() change in Line.java, although it didn't have any effect on the rendering of the test files.
        Show
        tilman Tilman Hausherr added a comment - I committed your optimizations for types 6 and 7 in rev 1609410 with the following modifications: I changed calDeg to calcDeg (you missed that one) I didn't use the changes in Patch.java, IMHO 1e-1 takes longer to understand than 0.001 I didn't commit the changes for type 2 yet because I will review / test them first. Btw the "someone else" author is Andreas Lehmkühler. I included the round() change in Line.java, although it didn't have any effect on the rendering of the test files.
        Hide
        xinshu Shaola Ren added a comment -

        Never mind, I just wanted to finish the work earlier. I'll work through those issues gradually.

        Show
        xinshu Shaola Ren added a comment - Never mind, I just wanted to finish the work earlier. I'll work through those issues gradually.
        Hide
        tilman Tilman Hausherr added a comment -

        I didn't understand

        If you are willing to close this project earlier than the planned time Aug 19, I think I can try to finish all the improvements in 2 or 3 more weeks, the math in other types is simple and obvious. I hope you can consider this, thanks in advance.

        Are you away at that time?

        Show
        tilman Tilman Hausherr added a comment - I didn't understand If you are willing to close this project earlier than the planned time Aug 19, I think I can try to finish all the improvements in 2 or 3 more weeks, the math in other types is simple and obvious. I hope you can consider this, thanks in advance. Are you away at that time?
        Hide
        tilman Tilman Hausherr added a comment -

        The results are amazing, so yes, we'll take it Before I commit these changes, please

        • rename calXXXX to calcXXXX because there is a "cal" colorspace, so this is confusing
        • remove the commented out part, we can still find it in the repository
        • add a short javadoc to calcPixelTable

        Please try the same optimization on shadings 4 and 5 and observe if the last page of ch14.pdf is rendered faster.

        I'm not sure if your trick will work best for shadings 1-3 - the reason is that these are often used for backgrounds, so in the worst case, you would calculate areas that are not seen because of some clipping region. Maybe by now, you could have a look at what the others wrote in PDFBOX-2117.

        Show
        tilman Tilman Hausherr added a comment - The results are amazing, so yes, we'll take it Before I commit these changes, please rename calXXXX to calcXXXX because there is a "cal" colorspace, so this is confusing remove the commented out part, we can still find it in the repository add a short javadoc to calcPixelTable Please try the same optimization on shadings 4 and 5 and observe if the last page of ch14.pdf is rendered faster. I'm not sure if your trick will work best for shadings 1-3 - the reason is that these are often used for backgrounds, so in the worst case, you would calculate areas that are not seen because of some clipping region. Maybe by now, you could have a look at what the others wrote in PDFBOX-2117 .
        Hide
        tilman Tilman Hausherr added a comment -

        ch14.pdf - chapter 14 of the book of Prof. Bill Casselman. It contains several gouraud shadings, especially the 3d donut on the last page.

        Show
        tilman Tilman Hausherr added a comment - ch14.pdf - chapter 14 of the book of Prof. Bill Casselman. It contains several gouraud shadings, especially the 3d donut on the last page.
        Hide
        tilman Tilman Hausherr added a comment -

        I'll test the new code later today... I wonder what will happen with this PDF by Prof. Kerstin Upmeyer that took "almost forever" to render:
        http://kupmeyer.com/wp-content/uploads/2012/02/K_UPMEYER_SPRING10.pdf
        Apparently, illustrators are using type 6 and 7 patches for what it was intended: shading 3d objects.

        Show
        tilman Tilman Hausherr added a comment - I'll test the new code later today... I wonder what will happen with this PDF by Prof. Kerstin Upmeyer that took "almost forever" to render: http://kupmeyer.com/wp-content/uploads/2012/02/K_UPMEYER_SPRING10.pdf Apparently, illustrators are using type 6 and 7 patches for what it was intended: shading 3d objects.
        Hide
        xinshu Shaola Ren added a comment -

        As I thought at the very beginning, I used a hashmap to store all the pixel point of an image, there is no memory consumption problem, and the speed for type 6 and 7 shading is much faster now. Using the hashmap avoids much duplicated calculation and useless list traverse. This method also avoids to write a new structure of quadtree. For other shading type, I'm sure the similar technique will be helpful too, I looked at the type 2 function and type 2 shading, there is not an obvious flaw in the code except the common flaw as type 6 and 7 shading in the getRaster() which I mostly inherited from previous code before.

        If you are willing to close this project earlier than the planned time Aug 19, I think I can try to finish all the improvements in 2 or 3 more weeks, the math in other types is simple and obvious. I hope you can consider this, thanks in advance.

        the repository https://bitbucket.org/xinshu/pdfbox.git is up to date (https://bitbucket.org/xinshu/pdfbox).

        Show
        xinshu Shaola Ren added a comment - As I thought at the very beginning, I used a hashmap to store all the pixel point of an image, there is no memory consumption problem, and the speed for type 6 and 7 shading is much faster now. Using the hashmap avoids much duplicated calculation and useless list traverse. This method also avoids to write a new structure of quadtree. For other shading type, I'm sure the similar technique will be helpful too, I looked at the type 2 function and type 2 shading, there is not an obvious flaw in the code except the common flaw as type 6 and 7 shading in the getRaster() which I mostly inherited from previous code before. If you are willing to close this project earlier than the planned time Aug 19, I think I can try to finish all the improvements in 2 or 3 more weeks, the math in other types is simple and obvious. I hope you can consider this, thanks in advance. the repository https://bitbucket.org/xinshu/pdfbox.git is up to date ( https://bitbucket.org/xinshu/pdfbox ).
        Hide
        tilman Tilman Hausherr added a comment - - edited

        Have a look at PDFBOX-2117, but please don't read the dialog yet, only look at the attached PDF files, not the java files, and not the dialog after them.

        This issue was opened by "power user" Petr who has done a lot for the project in the last few weeks but who didn't know about GSoC2014. I would ask you to first use the profiler with the files, to look at the existing source code for optimization possibilities. Maybe you'll have the same ideas as in the java files / the dialog there, maybe you have different ones.

        Note that optimization may not only have to be done in the shading package, it is also possibly in the function package. Most is function type 2.

        I've added an example with its postscript file in that issue, this makes it easier to understand what this function type 2 is about, even if you don't know postscript.

        The C0 and C1 values are boundaries, the three values are color values (in that case, R G B, but it could also be C M Y K or whatever the colorspace is) and N is an exponent.

        It is explained in the PDF spec but also here in short:
        http://ipdfdev.com/2012/09/03/ifxpdffactory-part-3-pdf-functions/

        Show
        tilman Tilman Hausherr added a comment - - edited Have a look at PDFBOX-2117 , but please don't read the dialog yet, only look at the attached PDF files, not the java files, and not the dialog after them. This issue was opened by "power user" Petr who has done a lot for the project in the last few weeks but who didn't know about GSoC2014. I would ask you to first use the profiler with the files, to look at the existing source code for optimization possibilities. Maybe you'll have the same ideas as in the java files / the dialog there, maybe you have different ones. Note that optimization may not only have to be done in the shading package, it is also possibly in the function package. Most is function type 2. I've added an example with its postscript file in that issue, this makes it easier to understand what this function type 2 is about, even if you don't know postscript. The C0 and C1 values are boundaries, the three values are color values (in that case, R G B, but it could also be C M Y K or whatever the colorspace is) and N is an exponent. It is explained in the PDF spec but also here in short: http://ipdfdev.com/2012/09/03/ifxpdffactory-part-3-pdf-functions/
        Hide
        xinshu Shaola Ren added a comment -

        Thanks, glad to hear about this message, hope there are some fun content in type 2 and 3 shading, it looks that they are more real. I'll put type 6 and 7 shading aside since now, not because getting stuck but any work will need to put time on. If you want, you can start a new thread about type 2 and 3 shading, it won't really matter.

        Show
        xinshu Shaola Ren added a comment - Thanks, glad to hear about this message, hope there are some fun content in type 2 and 3 shading, it looks that they are more real. I'll put type 6 and 7 shading aside since now, not because getting stuck but any work will need to put time on. If you want, you can start a new thread about type 2 and 3 shading, it won't really matter.
        Hide
        tilman Tilman Hausherr added a comment -

        Speed is not the most important. On my phone, there is a second PDF viewer that is faster than Adobe, but Coons patches look not "smooth" but rather like the superhero "The Thing" and I doubt that Mr. Coons would have liked that.

        Type 6 and 7 shadings are extremely hard to find in the real world. About 95% of test files are just that - test files, created to test the feature. The only real world examples here are the crestron file and the mcafee files. The real world McAfee files are rendered in a decent amount of time, the crestron file is very slow but this is due to type 2 shadings.

        Shaola Ren:
        We shouldn't spend too much time on optimizing 6 and 7. Have a look at it, but don't get stuck in that problem. Optimizing 2 and 3 is more important, because these shadings occur much more often in the real world.

        If you haven't already, please have a look at the profiler of Netbeans (or watch a few videos on youtube). You can start an application in profiler mode, and it will show you (depending on the settings) where the time is spent. You right click on the left pane and choose "profile", or use the icon on the toolbar. Then choose "CPU" and try different settings and see what happens. There is no fixed rule on how to use the profiler, but one is to analyse slowness at locations you don't expect. Note that the software will be much slower if the profiler is enabled.

        Show
        tilman Tilman Hausherr added a comment - Speed is not the most important. On my phone, there is a second PDF viewer that is faster than Adobe, but Coons patches look not "smooth" but rather like the superhero "The Thing" and I doubt that Mr. Coons would have liked that. Type 6 and 7 shadings are extremely hard to find in the real world. About 95% of test files are just that - test files, created to test the feature. The only real world examples here are the crestron file and the mcafee files. The real world McAfee files are rendered in a decent amount of time, the crestron file is very slow but this is due to type 2 shadings. Shaola Ren : We shouldn't spend too much time on optimizing 6 and 7. Have a look at it, but don't get stuck in that problem. Optimizing 2 and 3 is more important, because these shadings occur much more often in the real world. If you haven't already, please have a look at the profiler of Netbeans (or watch a few videos on youtube). You can start an application in profiler mode, and it will show you (depending on the settings) where the time is spent. You right click on the left pane and choose "profile", or use the icon on the toolbar. Then choose "CPU" and try different settings and see what happens. There is no fixed rule on how to use the profiler, but one is to analyse slowness at locations you don't expect. Note that the software will be much slower if the profiler is enabled.
        Hide
        xinshu Shaola Ren added a comment -

        Thanks, I'm happy to see the code in the trunk.

        I just looked at the example_030.pdf, especially for the page 2, the slow performance is in expectation, even if a better structure is used to store the triangles. The reason is, given an image, if you enlarge it n times in x and y directions, the rendering speed will be slowed by n^2 times as long as getRaster() is used as the current mechanism. I thought about this in a previous comment.

        However, I think I will focus on the structure first.

        Show
        xinshu Shaola Ren added a comment - Thanks, I'm happy to see the code in the trunk. I just looked at the example_030.pdf, especially for the page 2, the slow performance is in expectation, even if a better structure is used to store the triangles. The reason is, given an image, if you enlarge it n times in x and y directions, the rendering speed will be slowed by n^2 times as long as getRaster() is used as the current mechanism. I thought about this in a previous comment. However, I think I will focus on the structure first.
        Hide
        xinshu Shaola Ren added a comment -

        We are aware of the performance issue at the very beginning, and I talked about using a better structure to store the CoonsTriangle several times, and I mentioned sort and search before as well, the situation is the work is not done yet. For the structure to store the CoonsTriangle, I am thinking about to apply a Quadtree in the left time, before I did the work, I cannot say more about how the performance will be, and I can't guarantee anything . However, if someone else has a really better suggestion, I am glad to take it.

        The answer for "break", you cannot use a break, as there may be more than one point in the unit patch mapped to the same position of the real patch, two reasons, one is digitization, the other is folding or overlap. Digitization, like a length 10 line linearly mapped to only a length 2 line (just assume they have the same unit), if it's in real space, there is no such problem that more than one point mapped to the same point, for the non-negative integer space, the problem exists. Folding, that's obvious, that's why there are priority rules for type 6 and 7 shading. It looks the macfeeU5.pdf have some overlapped patches, if a break is used, may cause some unexpected white spots, however, I didn't try. For other files, a break may not cause such a problem that's just because the issue is not triggered, you still cannot set a break in the current code.

        "Neighbor hit", that's possible, the same reason as above, you have to check if there are any other matched triangles for the current structure, however, I didn't have this in mind before, thanks. I'll look at the attached file.

        Show
        xinshu Shaola Ren added a comment - We are aware of the performance issue at the very beginning, and I talked about using a better structure to store the CoonsTriangle several times, and I mentioned sort and search before as well, the situation is the work is not done yet. For the structure to store the CoonsTriangle, I am thinking about to apply a Quadtree in the left time, before I did the work, I cannot say more about how the performance will be, and I can't guarantee anything . However, if someone else has a really better suggestion, I am glad to take it. The answer for "break", you cannot use a break, as there may be more than one point in the unit patch mapped to the same position of the real patch, two reasons, one is digitization, the other is folding or overlap. Digitization, like a length 10 line linearly mapped to only a length 2 line (just assume they have the same unit), if it's in real space, there is no such problem that more than one point mapped to the same point, for the non-negative integer space, the problem exists. Folding, that's obvious, that's why there are priority rules for type 6 and 7 shading. It looks the macfeeU5.pdf have some overlapped patches, if a break is used, may cause some unexpected white spots, however, I didn't try. For other files, a break may not cause such a problem that's just because the issue is not triggered, you still cannot set a break in the current code. "Neighbor hit", that's possible, the same reason as above, you have to check if there are any other matched triangles for the current structure, however, I didn't have this in mind before, thanks. I'll look at the attached file.
        Hide
        tilman Tilman Hausherr added a comment - - edited

        Yes these shadings are slow, but they are faster than the Gouraud-shaded donut (google for ch14.pdf)

        Anyway, optimizing is the next step here, but I wanted to have the code of my GSoC student "in the wild" as soon as it was clean and correct, because the math on which this is based is very complex. The point is to have "something that works" first and I'm happy with is. Optimizations can now be compared to that. Be patient, the summer has just begun.

        I tried set a break in the loop a few weeks ago and got not-so-good images. However that may have had a different cause, probably solved by now (the problems with the McAfee file).

        Show
        tilman Tilman Hausherr added a comment - - edited Yes these shadings are slow, but they are faster than the Gouraud-shaded donut (google for ch14.pdf) Anyway, optimizing is the next step here, but I wanted to have the code of my GSoC student "in the wild" as soon as it was clean and correct, because the math on which this is based is very complex. The point is to have "something that works" first and I'm happy with is. Optimizations can now be compared to that. Be patient, the summer has just begun. I tried set a break in the loop a few weeks ago and got not-so-good images. However that may have had a different cause, probably solved by now (the problems with the McAfee file).
        Hide
        pslabycz Petr Slaby added a comment - - edited

        In my test suite, I have one rendering fixed and no regressions. Cool, thanks.

        My only complaint is the performance. The attached file (example_030.pdf) needs several minutes to render, especially the second page needs way too long. Without really understanding the algorithms, I had a look at PatchMeshesShadingContext#getRaster(). Could you perhaps sort the triangles and search for them instead of looping through all and checking which one contains the current point? The loop continues even after a matching triangle has been found. Could you at least break there? Also, the row/col loops always shift the current point by one. Isn't it likely that the same triangle or its neighbor will get a hit?

        Just ideas, keep up the good work.

        Show
        pslabycz Petr Slaby added a comment - - edited In my test suite, I have one rendering fixed and no regressions. Cool, thanks. My only complaint is the performance. The attached file (example_030.pdf) needs several minutes to render, especially the second page needs way too long. Without really understanding the algorithms, I had a look at PatchMeshesShadingContext#getRaster(). Could you perhaps sort the triangles and search for them instead of looping through all and checking which one contains the current point? The loop continues even after a matching triangle has been found. Could you at least break there? Also, the row/col loops always shift the current point by one. Isn't it likely that the same triangle or its neighbor will get a hit? Just ideas, keep up the good work.
        Hide
        tilman Tilman Hausherr added a comment -

        Congratulations, I committed your work into the trunk in http://svn.apache.org/r1607727 .

        Show
        tilman Tilman Hausherr added a comment - Congratulations, I committed your work into the trunk in http://svn.apache.org/r1607727 .
        Hide
        xinshu Shaola Ren added a comment -

        just completed most of the javadoc for type 6 and 7 shading if not all, the repository https://bitbucket.org/xinshu/pdfbox.git is up to date ( https://bitbucket.org/xinshu/pdfbox).

        Show
        xinshu Shaola Ren added a comment - just completed most of the javadoc for type 6 and 7 shading if not all, the repository https://bitbucket.org/xinshu/pdfbox.git is up to date ( https://bitbucket.org/xinshu/pdfbox ).
        Hide
        xinshu Shaola Ren added a comment -

        Thanks, that video is interesting. I will gradually complete the javadoc in this coming week, that's a relatively easy part, thanks for your suggestions, they are useful.

        Show
        xinshu Shaola Ren added a comment - Thanks, that video is interesting. I will gradually complete the javadoc in this coming week, that's a relatively easy part, thanks for your suggestions, they are useful.
        Hide
        tilman Tilman Hausherr added a comment -

        I ran my tests with the refactored code, all is fine here.

        Show
        tilman Tilman Hausherr added a comment - I ran my tests with the refactored code, all is fine here.
        Hide
        tilman Tilman Hausherr added a comment -

        I see you've been active with refactoring, this is good

        Yes the javadocs should be done too. It doesn't have to be long, but it should be a summary of whats being done / how it is being used by other classes if it is an interface or an abstract class. Nobody likes to do it, but the more you wait, the more annoying it becomes to do, so don't wait

        Private classes are not required to have a javadoc, but they should have an explanation if it isn't obvious from the code. Or at least a hint of whats being done. E.g. " getLen" => length of a line. "isEdgeALine" -> would like to know.

        If you used a wikipedia article, or an online paper as help, include the link where applicable. I couldn't have done types 1, 4, 5 without wikipedia and at one university course resource

        • CoordinateColorPair.java: classes that are used only by you don't have to be public. Just leave out the keyword "public".
        • PatchMeshesShadingContext.java readPatch(): if I remember this correctly, an EOF at that place is a bug in the source file (the flag was read successfully but not the rest), thus LOG.ERROR.
        • that "decode" line you commented out: just remove it
        • setLevel: this isn't a setter, it isn't a getter, I suggest you name it "calculateLevel" or whatever. I assume this is what we discussed about here, i.e. you're making a decision how far you'll chop the patch into triangles depending on the size of the patch.
        • remove classes that have a comment "This class is not used" Just delete them.

        I'll run the code tonight and/or this weekend and give more feedback.

        https://www.youtube.com/watch?v=TiqDqd-1pwU
        watch at 29:00 he shows the patch on the top right of the file TENSOR.PDF, and it seems you did the correct implementation

        The stuff at 22:00 is also about shading, but I feel that this goes over the scope of this project. I don't even know if we support "knockout transparency groups", we just started with transparency groups a week ago or so.

        Show
        tilman Tilman Hausherr added a comment - I see you've been active with refactoring, this is good Yes the javadocs should be done too. It doesn't have to be long, but it should be a summary of whats being done / how it is being used by other classes if it is an interface or an abstract class. Nobody likes to do it, but the more you wait, the more annoying it becomes to do, so don't wait Private classes are not required to have a javadoc, but they should have an explanation if it isn't obvious from the code. Or at least a hint of whats being done. E.g. " getLen" => length of a line. "isEdgeALine" -> would like to know. If you used a wikipedia article, or an online paper as help, include the link where applicable. I couldn't have done types 1, 4, 5 without wikipedia and at one university course resource CoordinateColorPair.java: classes that are used only by you don't have to be public. Just leave out the keyword "public". PatchMeshesShadingContext.java readPatch(): if I remember this correctly, an EOF at that place is a bug in the source file (the flag was read successfully but not the rest), thus LOG.ERROR. that "decode" line you commented out: just remove it setLevel: this isn't a setter, it isn't a getter, I suggest you name it "calculateLevel" or whatever. I assume this is what we discussed about here, i.e. you're making a decision how far you'll chop the patch into triangles depending on the size of the patch. remove classes that have a comment "This class is not used" Just delete them. I'll run the code tonight and/or this weekend and give more feedback. https://www.youtube.com/watch?v=TiqDqd-1pwU watch at 29:00 he shows the patch on the top right of the file TENSOR.PDF, and it seems you did the correct implementation The stuff at 22:00 is also about shading, but I feel that this goes over the scope of this project. I don't even know if we support "knockout transparency groups", we just started with transparency groups a week ago or so.
        Hide
        xinshu Shaola Ren added a comment -

        refactoring, cleaning up / removing duplicate code are done and code is up to date in the usual place, except there is no detailed java doc yet.

        Show
        xinshu Shaola Ren added a comment - refactoring, cleaning up / removing duplicate code are done and code is up to date in the usual place, except there is no detailed java doc yet.
        Hide
        xinshu Shaola Ren added a comment -

        I have updated the code.
        OK, I will do that in the next few days or next week, it requires more carefulness for this task.

        Show
        xinshu Shaola Ren added a comment - I have updated the code. OK, I will do that in the next few days or next week, it requires more carefulness for this task.
        Hide
        tilman Tilman Hausherr added a comment -

        When you're done with refactoring, cleaning up / removing double code, I'd like to commit the files, so that the people who use the 2.0 version can use your enhancements. Previously I thought that there must be only "one single commit", but it was explained on the GSoC mailing list that it is OK to commit intermediate releases.

        Show
        tilman Tilman Hausherr added a comment - When you're done with refactoring, cleaning up / removing double code, I'd like to commit the files, so that the people who use the 2.0 version can use your enhancements. Previously I thought that there must be only "one single commit", but it was explained on the GSoC mailing list that it is OK to commit intermediate releases.
        Hide
        xinshu Shaola Ren added a comment -

        Thanks.
        A quick message about applying dividing level judging, for the lamp_cairo and macfeeU5, the rendering time can drop to around 20 s in my laptop, other test files don't have too much change, now only the shading type 7 is done, I will update code after finished shading type 6. How well the code will work on an image depends on how well the algorithm is, for the current test suit, it works.

        Show
        xinshu Shaola Ren added a comment - Thanks. A quick message about applying dividing level judging, for the lamp_cairo and macfeeU5, the rendering time can drop to around 20 s in my laptop, other test files don't have too much change, now only the shading type 7 is done, I will update code after finished shading type 6. How well the code will work on an image depends on how well the algorithm is, for the current test suit, it works.
        Hide
        tilman Tilman Hausherr added a comment -

        Two test files with a "Danke schön" to CIB Software GmbH

        The coons file makes an NPE. You didn't initialize "implicitEdge" with an array in Type6ShadingContext, that is why. In Type7 it seems to be correct, i.e. you initialize the array.

        Show
        tilman Tilman Hausherr added a comment - Two test files with a "Danke schön" to CIB Software GmbH The coons file makes an NPE. You didn't initialize "implicitEdge" with an array in Type6ShadingContext, that is why. In Type7 it seems to be correct, i.e. you initialize the array.
        Hide
        tilman Tilman Hausherr added a comment -

        There's was a bug in the existing shadings (PDFBOX-2156) that is also in your code, although it doesn't apply to your test files - please change transformPoint() so that it looks like this:

                if (ctm != null)
                {
                    ctm.createAffineTransform().transform(p, p);
                }
                xform.transform(p, p);
        
        Show
        tilman Tilman Hausherr added a comment - There's was a bug in the existing shadings ( PDFBOX-2156 ) that is also in your code, although it doesn't apply to your test files - please change transformPoint() so that it looks like this: if (ctm != null ) { ctm.createAffineTransform().transform(p, p); } xform.transform(p, p);
        Hide
        xinshu Shaola Ren added a comment -

        Thanks.
        Re your last comment, you are absolutely right, hahaha..., I thought you may point out this, that's because I changed the level = 4 to level = 3 in order to get a faster speed in other test cases especially for the lamp_cario and macfeeU5 to see there is nothing wrong with the code, and I know when I changed the level back to 4, everything will remain the same as before. For this time's updating, only the code related to shading type 6 had a relatively more change than shading type 7, shading type 7 is almost suitable to edit the level parameter at the beginning.

        Show
        xinshu Shaola Ren added a comment - Thanks. Re your last comment, you are absolutely right, hahaha..., I thought you may point out this, that's because I changed the level = 4 to level = 3 in order to get a faster speed in other test cases especially for the lamp_cario and macfeeU5 to see there is nothing wrong with the code, and I know when I changed the level back to 4, everything will remain the same as before. For this time's updating, only the code related to shading type 6 had a relatively more change than shading type 7, shading type 7 is almost suitable to edit the level parameter at the beginning.
        Hide
        tilman Tilman Hausherr added a comment -

        I ran my tests; some patch boundaries look more like a line than like a curve, especially tensor-nofunction-CMYK.pdf and tensor-nofunction-RGB.pdf (all at 96dpi). The weird thing is that I could observe these effects only with tensor patches, not with coons patches. The coons patches are 100% identical.

        Show
        tilman Tilman Hausherr added a comment - I ran my tests; some patch boundaries look more like a line than like a curve, especially tensor-nofunction-CMYK.pdf and tensor-nofunction-RGB.pdf (all at 96dpi). The weird thing is that I could observe these effects only with tensor patches, not with coons patches. The coons patches are 100% identical.
        Hide
        tilman Tilman Hausherr added a comment -

        Sure, go ahead. I'll look at your code later today or this WE.

        I remember I tried inserting a break in your code but took that back for some reason.

        Please correct PageDrawer.shfill() by inserting "graphics.setClip(null);" before the last line, see PDFBOX-2153. Then try rendering the eci file and you'll be pleasantly suprised

        Show
        tilman Tilman Hausherr added a comment - Sure, go ahead. I'll look at your code later today or this WE. I remember I tried inserting a break in your code but took that back for some reason. Please correct PageDrawer.shfill() by inserting "graphics.setClip(null);" before the last line, see PDFBOX-2153 . Then try rendering the eci file and you'll be pleasantly suprised
        Hide
        xinshu Shaola Ren added a comment -

        For some images, the slow speed is in expectation, such as if an image is composed by hundreds of patches and each patch is composed of no more than 10 pixels, but the dividing level is still fixed to some value which is too large for such patch to cause a waste of time, another reason is that the listOfCoonsTriangle and patchList are not well structured, the current code has to traverse the lists from beginning till all the matched elements visited, this issue exists in the shading type 5 as well, although a break can be used there.

        update: Adjusted code suitable to set the dividing level for each patch, after I updated the code I noticed that the getLevel() in the repository should be named setLevel(). To determine the dividing level, I need to consider several sampled points' curvature in a cubic Bezier curve rather than the dimension as I thought before. I think I will focus on this issue temporarily.

        Show
        xinshu Shaola Ren added a comment - For some images, the slow speed is in expectation, such as if an image is composed by hundreds of patches and each patch is composed of no more than 10 pixels, but the dividing level is still fixed to some value which is too large for such patch to cause a waste of time, another reason is that the listOfCoonsTriangle and patchList are not well structured, the current code has to traverse the lists from beginning till all the matched elements visited, this issue exists in the shading type 5 as well, although a break can be used there. update: Adjusted code suitable to set the dividing level for each patch, after I updated the code I noticed that the getLevel() in the repository should be named setLevel(). To determine the dividing level, I need to consider several sampled points' curvature in a cubic Bezier curve rather than the dimension as I thought before. I think I will focus on this issue temporarily.
        Hide
        tilman Tilman Hausherr added a comment -

        Attaching page 9 from http://www.crestron.com/downloads/pdf/product_brochures/crestron_shading_solutions_brochure.pdf . This is a brochure about windows shading that contains type 2 and 7 shadings It renders fine (with the exception of an element at the "tablet" on the right but this is probably a different problem), but it is very slow: 760 seconds at 96dpi.

        Show
        tilman Tilman Hausherr added a comment - Attaching page 9 from http://www.crestron.com/downloads/pdf/product_brochures/crestron_shading_solutions_brochure.pdf . This is a brochure about windows shading that contains type 2 and 7 shadings It renders fine (with the exception of an element at the "tablet" on the right but this is probably a different problem), but it is very slow: 760 seconds at 96dpi.
        Hide
        tilman Tilman Hausherr added a comment -

        Great! All mcafee files work properly. I compared the shadings with previous correct ones and all are identical, except one (gwg) which is BETTER now. (The old one had a yellow spot that I hadn't noticed). I will add one of the mcafee files to my test suite.

        And it means you're slightly ahead of your "Plan A" schedule

        Show
        tilman Tilman Hausherr added a comment - Great! All mcafee files work properly. I compared the shadings with previous correct ones and all are identical, except one (gwg) which is BETTER now. (The old one had a yellow spot that I hadn't noticed). I will add one of the mcafee files to my test suite. And it means you're slightly ahead of your "Plan A" schedule
        Hide
        xinshu Shaola Ren added a comment -

        And try to determine the dividing level by the real dimension of a patch rather than a fixed value.

        Show
        xinshu Shaola Ren added a comment - And try to determine the dividing level by the real dimension of a patch rather than a fixed value.
        Hide
        xinshu Shaola Ren added a comment -

        Applied Bresenham's line algorithm, there is no weird spots for test file macfeeU5.pdf. In my opinion, next step, I will try to order listOfCoonsTriangle to optimize the time efficiency, before testing, not too sure how much will be improved.
        code is available in the usual place.

        Show
        xinshu Shaola Ren added a comment - Applied Bresenham's line algorithm, there is no weird spots for test file macfeeU5.pdf. In my opinion, next step, I will try to order listOfCoonsTriangle to optimize the time efficiency, before testing, not too sure how much will be improved. code is available in the usual place.
        Hide
        tilman Tilman Hausherr added a comment -

        Using algorithms named after a person is usually a good idea

        Show
        tilman Tilman Hausherr added a comment - Using algorithms named after a person is usually a good idea
        Hide
        xinshu Shaola Ren added a comment -

        I roughly knew what happened when those unexpected spots came out after tracking pixels of each patch. It seems the algorithm to test whether a point on a line is not good enough, I attached a file lineRasterization.jpg, the left part shows the result of current code, the right part shows the case which I think I should use, it is called "Bresenham line algorithm", hopefully, this will solve the current problem and be done next week.

        Show
        xinshu Shaola Ren added a comment - I roughly knew what happened when those unexpected spots came out after tracking pixels of each patch. It seems the algorithm to test whether a point on a line is not good enough, I attached a file lineRasterization.jpg, the left part shows the result of current code, the right part shows the case which I think I should use, it is called "Bresenham line algorithm", hopefully, this will solve the current problem and be done next week.
        Hide
        xinshu Shaola Ren added a comment -

        Sorry, that condition Math.abs(a.getX() - b.getX()) < 1 should change to Math.abs(a.getX() - b.getX()) < 0.001, as in other parts I use this accuracy. However, this change won't give a big difference. I should check this bug carefully before saying anything surely.

        Show
        xinshu Shaola Ren added a comment - Sorry, that condition Math.abs(a.getX() - b.getX()) < 1 should change to Math.abs(a.getX() - b.getX()) < 0.001, as in other parts I use this accuracy. However, this change won't give a big difference. I should check this bug carefully before saying anything surely.
        Hide
        xinshu Shaola Ren added a comment -

        Thanks, that is helpful, it means something wrong in the precondition judgement part in the contains() method, in this branch
        else if (degeneracy == 2)
        {
        if (overlaps(corner[0], corner[1]) && !overlaps(corner[0], corner[2]))

        { return isOnLine(corner[0], corner[2], p); }

        else /** maybe I should separate this branch into two cases, in the current code I merged the left two cases into one**/

        { return isOnLine(corner[0], corner[1], p); }

        }

        I'll check this.

        Show
        xinshu Shaola Ren added a comment - Thanks, that is helpful, it means something wrong in the precondition judgement part in the contains() method, in this branch else if (degeneracy == 2) { if (overlaps(corner [0] , corner [1] ) && !overlaps(corner [0] , corner [2] )) { return isOnLine(corner[0], corner[2], p); } else /** maybe I should separate this branch into two cases, in the current code I merged the left two cases into one**/ { return isOnLine(corner[0], corner[1], p); } } I'll check this.
        Hide
        tilman Tilman Hausherr added a comment -

        While doing other things, I ran the software with a trace if the "l" variable is zero (because this means a divide by zero), and I got many hits in the "then" branch. I.e. Math.abs(a.getX() - b.getX()) < 1, but also a.getY() = b.getY().

        Show
        tilman Tilman Hausherr added a comment - While doing other things, I ran the software with a trace if the "l" variable is zero (because this means a divide by zero), and I got many hits in the "then" branch. I.e. Math.abs(a.getX() - b.getX()) < 1, but also a.getY() = b.getY().
        Hide
        xinshu Shaola Ren added a comment -

        the precondition to call the method getColorOnALine is that two points a and b are not overlapped, then I used the difference of points coordinates in x direction to scale the color, if a and b has the same x position I used the y direction.

        if (Math.abs(a.getX() - b.getX()) < 1), this condition deals with the a.X = b.X.

        the case a.Y = b.Y is included in those if ... else ... branches automatically

        I saw the new image you attached.

        I think this is caused by the method to determine whether a point is inside or outside a patch, this bug should be in the CoonsTriangle class. Even when I set the dividing level to 0, that means I only use the original control points, several white points still appear in the rendered image. I am working on it.

        With these various cases to take care of, the code looks ugly now.

        Show
        xinshu Shaola Ren added a comment - the precondition to call the method getColorOnALine is that two points a and b are not overlapped, then I used the difference of points coordinates in x direction to scale the color, if a and b has the same x position I used the y direction. if (Math.abs(a.getX() - b.getX()) < 1), this condition deals with the a.X = b.X. the case a.Y = b.Y is included in those if ... else ... branches automatically I saw the new image you attached. I think this is caused by the method to determine whether a point is inside or outside a patch, this bug should be in the CoonsTriangle class. Even when I set the dividing level to 0, that means I only use the original control points, several white points still appear in the rendered image. I am working on it. With these various cases to take care of, the code looks ugly now.
        Hide
        tilman Tilman Hausherr added a comment -

        attached mcafeeu5.pdf rendered with 300dpi, the problem area has black red and white pixels.

        Show
        tilman Tilman Hausherr added a comment - attached mcafeeu5.pdf rendered with 300dpi, the problem area has black red and white pixels.
        Hide
        tilman Tilman Hausherr added a comment -

        Is getColorOnALine ever called with a.X = b.X or a.Y = b.Y ?

        Show
        tilman Tilman Hausherr added a comment - Is getColorOnALine ever called with a.X = b.X or a.Y = b.Y ?
        Hide
        xinshu Shaola Ren added a comment -

        The several while and black spots should be caused by unexpected calculation error, it may take time to fix this bug, I started to work on this problem.

        Show
        xinshu Shaola Ren added a comment - The several while and black spots should be caused by unexpected calculation error, it may take time to fix this bug, I started to work on this problem.
        Hide
        tilman Tilman Hausherr added a comment -

        mcafeeU5.pdf is a PDF file that is reduced so that only the type 7 shading is active. I couldn't yet test this file at a higher resolution (will do tomorrow), but other PDF files with the logo had different color pixels (black, white and red) at the place below the right leg of the "M". This one (96dpi) only has white and black "bad" pixels. White could mean that a pixel is outside of a patch, but black is really suspicious.

        The best thing to do would be to make a log print if the pre-RGB-conversion values (CMYK) are outside of a certain range. (You get the range by logging everything for a few seconds, which gives you an idea what values you get)

        • if it never happens, it would suggest that there is a color conversion problem; then check the post-RGB-conversion values
        • if the post-RGB values are always within a certain range, then it would mean that there's a real mystery
        • if the pre-RGB conversion values (CMYK) are outside of the range, this suggest there's a calculation bug

        Good luck!

        Show
        tilman Tilman Hausherr added a comment - mcafeeU5.pdf is a PDF file that is reduced so that only the type 7 shading is active. I couldn't yet test this file at a higher resolution (will do tomorrow), but other PDF files with the logo had different color pixels (black, white and red) at the place below the right leg of the "M". This one (96dpi) only has white and black "bad" pixels. White could mean that a pixel is outside of a patch, but black is really suspicious. The best thing to do would be to make a log print if the pre-RGB-conversion values (CMYK) are outside of a certain range. (You get the range by logging everything for a few seconds, which gives you an idea what values you get) if it never happens, it would suggest that there is a color conversion problem; then check the post-RGB-conversion values if the post-RGB values are always within a certain range, then it would mean that there's a real mystery if the pre-RGB conversion values (CMYK) are outside of the range, this suggest there's a calculation bug Good luck!
        Hide
        tilman Tilman Hausherr added a comment -

        After doing the described tests, I think there is only one problem left, this is the weird spot in the mcafee files. It is always below the right "leg" of the "M". And it happens with every mcafee file. I will try to create a PDF that has only the shading and nothing more to see what happens.

        Show
        tilman Tilman Hausherr added a comment - After doing the described tests, I think there is only one problem left, this is the weird spot in the mcafee files. It is always below the right "leg" of the "M". And it happens with every mcafee file. I will try to create a PDF that has only the shading and nothing more to see what happens.
        Hide
        tilman Tilman Hausherr added a comment -

        The renderings look good to me, even the "failed" ones (I'd agree that the problem with the XYZ file might be a color conversion issue, i.e. "not your fault"). I'll have a look at your new code and update my local code with yours, render again at 300dpi (including some additional mcafee files from their website), also compare the new rendering results with some old ones that I saved. This will hopefully be done this evening or tomorrow.

        Show
        tilman Tilman Hausherr added a comment - The renderings look good to me, even the "failed" ones (I'd agree that the problem with the XYZ file might be a color conversion issue, i.e. "not your fault"). I'll have a look at your new code and update my local code with yours, render again at 300dpi (including some additional mcafee files from their website), also compare the new rendering results with some old ones that I saved. This will hopefully be done this evening or tomorrow.
        Hide
        xinshu Shaola Ren added a comment -

        I thought about the macfee file more, before, my attention was attracted to the degeneracy issue, I didn't have a good understanding about what you said "Even at 300dpi, the gwg and the mcafee files don't come out well. Could it be that you're working with a too "coarse" dividing into triangles, so that only large patches look nice?". However, I am not too sure about the problem now, this method dealt with each patch separately, if each small letter in the image part of macfee is combined by several individual patches, then the method I used shouldn't cause any problem, I will think this issue more.

        Show
        xinshu Shaola Ren added a comment - I thought about the macfee file more, before, my attention was attracted to the degeneracy issue, I didn't have a good understanding about what you said "Even at 300dpi, the gwg and the mcafee files don't come out well. Could it be that you're working with a too "coarse" dividing into triangles, so that only large patches look nice?". However, I am not too sure about the problem now, this method dealt with each patch separately, if each small letter in the image part of macfee is combined by several individual patches, then the method I used shouldn't cause any problem, I will think this issue more.
        Hide
        xinshu Shaola Ren added a comment -

        rendering lamp_cairo.pdf, tensor4-nofunction.pdf and GWG060_Shading_x1a.pdf to image correctly
        as I added some code to test degeneracy, the software works slower than before, for lamp_cairo.pdf, it used 160 s to draw the picture in my laptop.

        failedTest.rar: still have some problem when rendering McAfee-ShadingType7.pdf, eci_altona-test-suite-v2_technical_H.pdf and XYZsweep.pdf, for those 3 test files, the bug may not be in my code, or not in the shading type 6 and 7 calculation.

        the code are available at https://bitbucket.org/xinshu/pdfbox.git
        for webview https://bitbucket.org/xinshu/pdfbox

        Show
        xinshu Shaola Ren added a comment - rendering lamp_cairo.pdf, tensor4-nofunction.pdf and GWG060_Shading_x1a.pdf to image correctly as I added some code to test degeneracy, the software works slower than before, for lamp_cairo.pdf, it used 160 s to draw the picture in my laptop. failedTest.rar: still have some problem when rendering McAfee-ShadingType7.pdf, eci_altona-test-suite-v2_technical_H.pdf and XYZsweep.pdf, for those 3 test files, the bug may not be in my code, or not in the shading type 6 and 7 calculation. the code are available at https://bitbucket.org/xinshu/pdfbox.git for webview https://bitbucket.org/xinshu/pdfbox
        Hide
        xinshu Shaola Ren added a comment -

        Thanks for your information and updated files. When one patch's real dimension is too large, there is indeed the "too coarse" problem in my method as I just simply define one general dividing level what I used now is 4, that means each cubic Bezier curve is divided into 1 << 4 = 16 segments, for a better version this level may be determined by the dimension of a patch but not in the current code yet and I didn't think about this issue carefully either now.

        There is also another problem in my code, as I divide one patch into small quadrilaterals, there are two cases that I didn't consider before, when a quadrilateral degenerates into a point or a line, which cause some parts of a shading type 7 image to be lost, you will see some parts of a graph have unexpected background color, I attached two such results lamp_cairo7_1.png and lamp_cairo7_0.png, these two graph have different dividing level.

        I thought another way to deal with the dividing issue, the finer the divided quadrilateral is the longer the time will be taken to calculate, when a patch is too large, I can first take it as a small patch, after calculation, I can use another method to zoom in the small patch to its real size, this can avoid the heavy calculation from control points to graph, but I still didn't think about the concrete method to accomplish this zoom in function.

        I believe there should be many other imperfect aspects in this method. I haven't tested the 4 flags file and gwg file yet, now I started working on the degenerated quadrilateral cases.

        All your information is useful. Thanks.

        Show
        xinshu Shaola Ren added a comment - Thanks for your information and updated files. When one patch's real dimension is too large, there is indeed the "too coarse" problem in my method as I just simply define one general dividing level what I used now is 4, that means each cubic Bezier curve is divided into 1 << 4 = 16 segments, for a better version this level may be determined by the dimension of a patch but not in the current code yet and I didn't think about this issue carefully either now. There is also another problem in my code, as I divide one patch into small quadrilaterals, there are two cases that I didn't consider before, when a quadrilateral degenerates into a point or a line, which cause some parts of a shading type 7 image to be lost, you will see some parts of a graph have unexpected background color, I attached two such results lamp_cairo7_1.png and lamp_cairo7_0.png, these two graph have different dividing level. I thought another way to deal with the dividing issue, the finer the divided quadrilateral is the longer the time will be taken to calculate, when a patch is too large, I can first take it as a small patch, after calculation, I can use another method to zoom in the small patch to its real size, this can avoid the heavy calculation from control points to graph, but I still didn't think about the concrete method to accomplish this zoom in function. I believe there should be many other imperfect aspects in this method. I haven't tested the 4 flags file and gwg file yet, now I started working on the degenerated quadrilateral cases. All your information is useful. Thanks.
        Hide
        tilman Tilman Hausherr added a comment -

        I attached a PDF with all 4 flags.

        I get a seemingly correct rendering after making slight changes in the flag 1,2,3 handling, your code looked different than the spec. Please test it yourself.

        Some more differences:
        Even at 300dpi, the gwg and the mcafee files don't come out well. Could it be that you're working with a too "coarse" dividing into triangles, so that only large patches look nice?

        Show
        tilman Tilman Hausherr added a comment - I attached a PDF with all 4 flags. I get a seemingly correct rendering after making slight changes in the flag 1,2,3 handling, your code looked different than the spec. Please test it yourself. Some more differences: Even at 300dpi, the gwg and the mcafee files don't come out well. Could it be that you're working with a too "coarse" dividing into triangles, so that only large patches look nice?
        Hide
        tilman Tilman Hausherr added a comment -

        There's another bug in my code, and thus also in your code, see PDFBOX-2115. In TypeNShadingContext, where "N" is 4, 5, 6 and 7, please correct getFilteredStream to getUnfilteredStream. This affects the McAfee file, the ECI file, and the gwg file. Sorry about that.

        Show
        tilman Tilman Hausherr added a comment - There's another bug in my code, and thus also in your code, see PDFBOX-2115 . In TypeNShadingContext, where "N" is 4, 5, 6 and 7, please correct getFilteredStream to getUnfilteredStream. This affects the McAfee file, the ECI file, and the gwg file. Sorry about that.
        Hide
        xinshu Shaola Ren added a comment -

        Thanks, your bug fix suggestion is right. I will follow your suggestions to modify the code. "Triangle" class is never used, I should delete it.

        Show
        xinshu Shaola Ren added a comment - Thanks, your bug fix suggestion is right. I will follow your suggestions to modify the code. "Triangle" class is never used, I should delete it.
        Hide
        tilman Tilman Hausherr added a comment -

        The lamp_cairo file has also bitsPerCoordinate = 32, so maybe the above bugfix can help.

        Show
        tilman Tilman Hausherr added a comment - The lamp_cairo file has also bitsPerCoordinate = 32, so maybe the above bugfix can help.
        Hide
        tilman Tilman Hausherr added a comment -

        Re BDC and i: these are PDF operators that PDFBox doesn't support. They are explained on p.985 of the spec ("operator summary"). "i" = set flatness tolerance, this is not related to you; BDC = "Begin a marked-content sequence with an associated property list, terminated by a balancing EMC operator." - who knows. I usually disregard these messages.

        Show
        tilman Tilman Hausherr added a comment - Re BDC and i: these are PDF operators that PDFBox doesn't support. They are explained on p.985 of the spec ("operator summary"). "i" = set flatness tolerance, this is not related to you; BDC = "Begin a marked-content sequence with an associated property list, terminated by a balancing EMC operator." - who knows. I usually disregard these messages.
        Hide
        tilman Tilman Hausherr added a comment - - edited

        There's a bug in Type4ShadingContext and Type5ShadingContext (and in Type6ShadingContext and Type7ShadingContext too), I have opened issue PDFBOX-2111 to change

                long maxSrcCoord = (int) Math.pow(2, bitsPerCoordinate) - 1;
                long maxSrcColor = (int) Math.pow(2, bitsPerColorComponent) - 1;
        

        to

                long maxSrcCoord = (long) (Math.pow(2, bitsPerCoordinate) - 1);
                long maxSrcColor = (long) (Math.pow(2, bitsPerColorComponent) - 1);
        

        The problem is that maxSrcCoord is 7FFFFFFF instead of FFFFFFFF when the bitsPerCoordinate is 32.

        Show
        tilman Tilman Hausherr added a comment - - edited There's a bug in Type4ShadingContext and Type5ShadingContext (and in Type6ShadingContext and Type7ShadingContext too), I have opened issue PDFBOX-2111 to change long maxSrcCoord = ( int ) Math .pow(2, bitsPerCoordinate) - 1; long maxSrcColor = ( int ) Math .pow(2, bitsPerColorComponent) - 1; to long maxSrcCoord = ( long ) ( Math .pow(2, bitsPerCoordinate) - 1); long maxSrcColor = ( long ) ( Math .pow(2, bitsPerColorComponent) - 1); The problem is that maxSrcCoord is 7FFFFFFF instead of FFFFFFFF when the bitsPerCoordinate is 32.
        Hide
        tilman Tilman Hausherr added a comment - - edited

        Yes, refactoring is always a good idea. Some more things to do:

        • replace all println with LOG.debug. Be careful with the LOG object, that it has the correct class (wrong class in Type7ShadingContext)
        • put your full name as author (unless you have a personal reason not to). But IMHO the code is like other published science work that also has your full name.
        • each class should have a short description. That description should mention that the implementation was done as part of GSoC2014.
        • classes shouldn't be public if they are used only within the package. It is probably to just remove the "public" from every class you created.
        • each public method should have a javadoc with a short description and tell what the parameters mean
        • the other methods too, if it isn't obvious from the code or from the name what they do
          (Yes, I'm aware that the existing code is not always compliant to these rules, but we're improving)
        • "Triangle" class - is this a duplicate of CoonsTriangle class?
        • handle EOF exception in the TypeNShadingContact classes
        Show
        tilman Tilman Hausherr added a comment - - edited Yes, refactoring is always a good idea. Some more things to do: replace all println with LOG.debug. Be careful with the LOG object, that it has the correct class (wrong class in Type7ShadingContext) put your full name as author (unless you have a personal reason not to). But IMHO the code is like other published science work that also has your full name. each class should have a short description. That description should mention that the implementation was done as part of GSoC2014. classes shouldn't be public if they are used only within the package. It is probably to just remove the "public" from every class you created. each public method should have a javadoc with a short description and tell what the parameters mean the other methods too, if it isn't obvious from the code or from the name what they do (Yes, I'm aware that the existing code is not always compliant to these rules, but we're improving) "Triangle" class - is this a duplicate of CoonsTriangle class? handle EOF exception in the TypeNShadingContact classes
        Hide
        tilman Tilman Hausherr added a comment - - edited

        Wonderful news

        About the images that can't be displayed: there is always the possibility that it is one of the problems what appears with some of the other shadings, i.e. that getRaster() is never called.

        (edit: deleted rest of comment here, I mixed up something)

        Show
        tilman Tilman Hausherr added a comment - - edited Wonderful news About the images that can't be displayed: there is always the possibility that it is one of the problems what appears with some of the other shadings, i.e. that getRaster() is never called. (edit: deleted rest of comment here, I mixed up something)
        Hide
        xinshu Shaola Ren added a comment -

        test result for tensor-nonfunction-RGB.pdf, correct. The related file in JIRA for last comment is shading7.rar. code is available in bitbucket.

        Show
        xinshu Shaola Ren added a comment - test result for tensor-nonfunction-RGB.pdf, correct. The related file in JIRA for last comment is shading7.rar. code is available in bitbucket.
        Hide
        xinshu Shaola Ren added a comment -

        1. rendering correct images: asy-coons-but-really-tensor7.pdf, asy-tensor7.pdf, TENSOR7.pdf

        the common characters of these files are, each image has a single data object stream, color space is DeviceRGB

        2. rendering part of the whole file: McAfee-ShadingType7.pdf

        this file is made of several shading type 2 image and 1 shading type 7 image, the shading type 7 is not converted by the program

        in a usual file the parameter sequence is like this:
        10 0 obj
        <</ShadingType 7
        /ColorSpace/DeviceRGB
        /Decode[-16384
        16384
        -16384
        16384
        0
        1
        0
        1
        0
        1]
        /BitsPerCoordinate 24
        /BitsPerComponent 16
        /BitsPerFlag 8/Length 121>>stream
        ... endstream
        endobj

        in this file:
        18 0 obj
        <<
        /AntiAlias false
        /BitsPerComponent 8
        /BitsPerCoordinate 32
        /BitsPerFlag 8
        /ColorSpace /DeviceCMYK
        /Decode [1500.39 1711.32 -2589.48 -2378.55 0.0 1.0 0.0 1.0 0.0 1.0
        0.0 1.0]
        /Filter /FlateDecode
        /Length 64760
        /ShadingType 7
        >>
        stream ... endstream
        endobj

        when "ShadingType 7" is not at the beginning, the software has problem to deal with the corresponding data, the shading type 2 part has a similar situation, this may explain why the converted image lost the red top bar and the correct color of the letters in the gray area

        when testing this file, the program throws this message: "org.apache.pdfbox.util.PDFStreamEngine processOperator INFO: unsupported/disabled operation: BDC"

        3. with color problems: XYZsweep7.pdf

        the color space of this file is "ColorSpace 9 0 R", I think what I did in the shading package is right, there must be some problem in the interpretation of the ColorSpace.

        when testing this file, the program throus this message: "org.apache.pdfbox.util.PDFStreamEngine processOperator INFO: unsupported/disabled operation: i"

        4. cannot get image: lamp_cairo7.pdf

        an file combined by many shading type 7 data streams, the software cannot work correctly here

        Now, shading type 7 and shading type 6 have some duplicated code, I will create several shared classes to remove these duplicates.

        Show
        xinshu Shaola Ren added a comment - 1. rendering correct images: asy-coons-but-really-tensor7.pdf, asy-tensor7.pdf, TENSOR7.pdf the common characters of these files are, each image has a single data object stream, color space is DeviceRGB 2. rendering part of the whole file: McAfee-ShadingType7.pdf this file is made of several shading type 2 image and 1 shading type 7 image, the shading type 7 is not converted by the program in a usual file the parameter sequence is like this: 10 0 obj <</ShadingType 7 /ColorSpace/DeviceRGB /Decode[-16384 16384 -16384 16384 0 1 0 1 0 1] /BitsPerCoordinate 24 /BitsPerComponent 16 /BitsPerFlag 8/Length 121>>stream ... endstream endobj in this file: 18 0 obj << /AntiAlias false /BitsPerComponent 8 /BitsPerCoordinate 32 /BitsPerFlag 8 /ColorSpace /DeviceCMYK /Decode [1500.39 1711.32 -2589.48 -2378.55 0.0 1.0 0.0 1.0 0.0 1.0 0.0 1.0] /Filter /FlateDecode /Length 64760 /ShadingType 7 >> stream ... endstream endobj when "ShadingType 7" is not at the beginning, the software has problem to deal with the corresponding data, the shading type 2 part has a similar situation, this may explain why the converted image lost the red top bar and the correct color of the letters in the gray area when testing this file, the program throws this message: "org.apache.pdfbox.util.PDFStreamEngine processOperator INFO: unsupported/disabled operation: BDC" 3. with color problems: XYZsweep7.pdf the color space of this file is "ColorSpace 9 0 R", I think what I did in the shading package is right, there must be some problem in the interpretation of the ColorSpace. when testing this file, the program throus this message: "org.apache.pdfbox.util.PDFStreamEngine processOperator INFO: unsupported/disabled operation: i" 4. cannot get image: lamp_cairo7.pdf an file combined by many shading type 7 data streams, the software cannot work correctly here Now, shading type 7 and shading type 6 have some duplicated code, I will create several shared classes to remove these duplicates.
        Hide
        tilman Tilman Hausherr added a comment -

        Hopefully a "simple" tensor test case created with PostScript.

        Show
        tilman Tilman Hausherr added a comment - Hopefully a "simple" tensor test case created with PostScript.
        Hide
        tilman Tilman Hausherr added a comment -

        Thanks Here's the PostScript file, just for the record.

        Show
        tilman Tilman Hausherr added a comment - Thanks Here's the PostScript file, just for the record.
        Hide
        xinshu Shaola Ren added a comment -

        passed the 4 flag test file for shading type 6
        code are available at https://bitbucket.org/xinshu/pdfbox.git
        for web view https://bitbucket.org/xinshu/pdfbox

        Show
        xinshu Shaola Ren added a comment - passed the 4 flag test file for shading type 6 code are available at https://bitbucket.org/xinshu/pdfbox.git for web view https://bitbucket.org/xinshu/pdfbox
        Hide
        xinshu Shaola Ren added a comment -

        Thank Andreas Lehmkühler

        Show
        xinshu Shaola Ren added a comment - Thank Andreas Lehmkühler
        Hide
        lehmi Andreas Lehmkühler added a comment -

        I've added Shaola to the "contributors" group and assigning shouldn't be a problem anymore

        Show
        lehmi Andreas Lehmkühler added a comment - I've added Shaola to the "contributors" group and assigning shouldn't be a problem anymore
        Hide
        xinshu Shaola Ren added a comment -

        For the "assign", it's fine, I was just curious about this item, and I think it's no harm to ask you this question, so I did

        For the current method I used, I don't need to consider the counterclockwise and clockwise direction, as the grid is generated automatically, all situations and priority rules are followed directly. I almost deleted all the code in CoonsPatch class and CubicBezierCurve class I wrote before May 28 and rewrite this new version by adding another class CoonsTriangle. Obviously, there is some redundant code there, I will edit this stuff last.

        Although, the previous version is hardly used in the current code, the previous version helped me a lot to understand the whole problem.

        Yes, the last strategy works, first dividing a patch to small 4-side patches, then dividing each small patch to two triangles, then create a triangle list as shading type 5, but having difference with what you coded in shading type 5, I will write a detailed document about this method later.

        For the "broken line" you mentioned, I looked at that, that is in my first comment in this thread, they are not broken lines, just with arrows, one arrow followed by a whole paragraph, no content missed.

        Yes, I am happy with this progress.

        Show
        xinshu Shaola Ren added a comment - For the "assign", it's fine, I was just curious about this item, and I think it's no harm to ask you this question, so I did For the current method I used, I don't need to consider the counterclockwise and clockwise direction, as the grid is generated automatically, all situations and priority rules are followed directly. I almost deleted all the code in CoonsPatch class and CubicBezierCurve class I wrote before May 28 and rewrite this new version by adding another class CoonsTriangle. Obviously, there is some redundant code there, I will edit this stuff last. Although, the previous version is hardly used in the current code, the previous version helped me a lot to understand the whole problem. Yes, the last strategy works, first dividing a patch to small 4-side patches, then dividing each small patch to two triangles, then create a triangle list as shading type 5, but having difference with what you coded in shading type 5, I will write a detailed document about this method later. For the "broken line" you mentioned, I looked at that, that is in my first comment in this thread, they are not broken lines, just with arrows, one arrow followed by a whole paragraph, no content missed. Yes, I am happy with this progress.
        Hide
        tilman Tilman Hausherr added a comment - - edited

        I just tried, I can't "assign" it to you, apparently this is only possible to committers. But all committers know that it is yours

        Was any of the test files in a different direction that the others? I ask because one early hand drawing showed clockwise and counterclockwise.

        Could you please edit your earlier comments to join the lines that are broken?

        Also, which strategy was the successful one? I assume it is the last one (i.e. the one in the first comment).

        I'd say that was a very successful week!

        Show
        tilman Tilman Hausherr added a comment - - edited I just tried, I can't "assign" it to you, apparently this is only possible to committers. But all committers know that it is yours Was any of the test files in a different direction that the others? I ask because one early hand drawing showed clockwise and counterclockwise. Could you please edit your earlier comments to join the lines that are broken? Also, which strategy was the successful one? I assume it is the last one (i.e. the one in the first comment). I'd say that was a very successful week!
        Hide
        xinshu Shaola Ren added a comment -

        OK, for the ECI test file, it's indeed as you said, the left lower 5 colored rectangles are not displayed. I don't think it's necessary to send another email to you about what I did in this week, all the stuff is here now, I should use this thread earlier, it's more convenient. Next week, I will start to work on shading type 7. I noticed that this project is still not assigned to anybody, I think I definitely can accomplish it now

        Show
        xinshu Shaola Ren added a comment - OK, for the ECI test file, it's indeed as you said, the left lower 5 colored rectangles are not displayed. I don't think it's necessary to send another email to you about what I did in this week, all the stuff is here now, I should use this thread earlier, it's more convenient. Next week, I will start to work on shading type 7. I noticed that this project is still not assigned to anybody, I think I definitely can accomplish it now
        Hide
        tilman Tilman Hausherr added a comment -

        Great !!!

        Btw don't waste any time on the ECI test file if it doesn't display immediately. It doesn't display for type 4 and 5 either, getRaster() is never called for some reason. I.e. the cause is outside of the shading package. There are several such files, there's even one with type 2 shading.

        Show
        tilman Tilman Hausherr added a comment - Great !!! Btw don't waste any time on the ECI test file if it doesn't display immediately. It doesn't display for type 4 and 5 either, getRaster() is never called for some reason. I.e. the cause is outside of the shading package. There are several such files, there's even one with type 2 shading.
        Hide
        xinshu Shaola Ren added a comment - - edited

        Update:
        I meant the technical part for shading type 6 is solved, for other details I will work on them later...
        Shading type 7 should be similar to shading type 6...

        ************************************************************
        Rendering correct shading type 6 image.
        This is the test result for my shading type 6 code.
        code are available at https://bitbucket.org/xinshu/pdfbox.git
        for web view https://bitbucket.org/xinshu/pdfbox

        related file in JIRA shading6Done.rar

        Show
        xinshu Shaola Ren added a comment - - edited Update: I meant the technical part for shading type 6 is solved, for other details I will work on them later... Shading type 7 should be similar to shading type 6... ************************************************************ Rendering correct shading type 6 image. This is the test result for my shading type 6 code. code are available at https://bitbucket.org/xinshu/pdfbox.git for web view https://bitbucket.org/xinshu/pdfbox related file in JIRA shading6Done.rar
        Hide
        xinshu Shaola Ren added a comment -

        extracted contour of a folded shading type 6 image

        Show
        xinshu Shaola Ren added a comment - extracted contour of a folded shading type 6 image
        Hide
        xinshu Shaola Ren added a comment -

        an even older stuff

        the reading data part is almost done

        the code are available at https://bitbucket.org/xinshu/pdfbox.git

        for webview https://bitbucket.org/xinshu/pdfbox

        This is stuff edited from the emails from me and Tilman, I am sorry that I didn't post my questions on Jira

        earlier, hopefully these emails don't have any thing that is not suitable to be published publicly, if there are

        such issues, Tilman Please, Feel free to delete or edit them. I am sorry for this unconvenience.

        related file is Shadingtype6week1.pdf

        May 23
        From Shaola to Tilman
        Hello Tilman,

        I modified the shading package, and the code are available at https://bitbucket.org/xinshu/pdfbox.git, midway done,

        may have bugs.

        However, It’s better to summarize the progress made in this week and talk to you to get some feedback. Any

        suggestion is appreciated, take you time.

        I encountered some questions which I put in this powerpoint(attached) and highlighted by blue color. If these

        questions are too vague, you don’t need to give an explicit answer.

        Thanks!

        From Tilman to Shaola

        Quick answer

        • to use LOG.debug() you must set debug level. This is done in the file "log4j.properties" in the default package

        of your application.
        Alternatively, use LOG.info() and it should work immediately (with the command line utility) Here's a sample log4j

        file with debug level enabled:

        log4j.rootLogger=DEBUG, A1
        #log4j.rootLogger=INFO, A1

        1. A1 is set to be a ConsoleAppender.
          log4j.appender.A1=org.apache.log4j.ConsoleAppender
        2. A1 uses PatternLayout.
          log4j.appender.A1.layout=org.apache.log4j.PatternLayout
          log4j.appender.A1.layout.ConversionPattern=%d {dd.MM.yyyy HH:mm:ss.SSS}

          %-5p [%t] %C:%L - %m%n

        System.out.println() is the quick way, but you should get used to use "apache log4j". Download it at
        https://logging.apache.org/log4j/1.2/
        and attach it to your calling application.

        Yes, it takes that long to build. You could probably write a script to copy the class file that is created while

        editing and insert it to an existing jar file. I assume you could also skip the tests. I just tested this
        https://maven.apache.org/surefire/maven-surefire-plugin/examples/skipping-test.html
        just add -DskipTests

        Hello Shaola,

        /ShadingType 6
        /ColorSpace/DeviceRGB
        /Decode[-16384
        16384
        -16384
        16384
        0
        1
        0
        1
        0
        1]
        /BitsPerCoordinate 24
        /BitsPerComponent 16
        /BitsPerFlag 8

        BitsPerCoordinate = 24, it means that the max value in the stream for a coordinate is 0xFFFFFF = 16777215. This is

        then mapped to the target which has an interval [-16384..16384] with "interpolate". The values you get must then be

        "transformed" into the physical coordinates, which is done in GouraudShadingContext.transformVertices(). You can

        probably reuse this. At first, just make yourself a copy; later in the project, it should possibly be merged so

        that no code exists twice.
        https://en.wikipedia.org/wiki/Don%27t_repeat_yourself

        Re "transform", this is two things:
        1) PDF related transformations, i.e. mentioned in the PDF
        2) java graphics transform: depends on the size of the image. Usually this is a scale, 4.16 for 300dpi.

        I don't see that you did the transform, which may explain why you get such weird coordinates... and yes, after the

        transforms, you get physical coords.

        Look at Gouraud shading, the transform is done at the beginning only, i.e. only once. In getRaster(), you then

        work with "real, screen" coordinates.

        I don't think it is useful to generate the points separately, as they are painted only once. The raster in which

        the other shading classes are writing into is a "Table", somehow. Some people render at 300dpi. An A4 page is about

        2500 x 3500 pixels.

        Re getraster(): yes, getraster only paints a small section. It is called again and again and again. X and Y are

        physical pixels.

        I strongly recommend to first "get something simple that works". Even if slow. From there, you can try to make

        changes, and if these go wrong, you can always go back to the "simple" solution.

        Hint: output the "raw" coordinates and the interval boundaries in hex. This is done with System.out.println

        (String.format("%x", val)). This gives you a better idea of the relationships between the numbers.

        Minor thing:
        getParamSpaceColor(int i, int j)

        are these coordinates? If yes, please name them x and y. Same for getPatchCoordinates.

        I hope I answered most, if not all.

        Good luck!

        From Shaola to Tilman

        2) java graphics transform: depends on the size of the image. Usually this is a scale, 4.16 for 300dpi.

        I don't see that you did the transform, which may explain why you get such weird coordinates... and yes, after

        the transforms, you get physical coords.

        I will check this, as the transform matrix is optional, I just doubted this but didn't test.

        Look at Gouraud shading, the transform is done at the beginning only, i.e. only once. In getRaster(), you then

        work with "real, screen" coordinates.

        I don't think it is useful to generate the points separately, as they are painted only once. The raster in

        which the other shading classes are writing into is a "Table", somehow. Some people render at 300dpi. An A4 page is

        about 2500 x 3500 pixels.

        This information is useful, it prevents me to think more in this direction.

        I strongly recommend to first "get something simple that works". Even if slow. From there, you can try to make

        changes, and if these go wrong, you can always go back to the "simple" solution.

        I will.

        Minor thing:
        getParamSpaceColor(int i, int j)

        are these coordinates? If yes, please name them x and y. Same for getPatchCoordinates.

        These are not real coordinates, as before getting real coordinates, cubic Bezier curve needs an assistant parameter

        to get its points position, the returned value of getPatchCoordinates() is real coordinate, similar to

        getParamSpaceColor, that is the mapping step. However, I don't need to generate all the point separately as you

        said, I have to think it in other way as you did in the GouraudShadingContext to check whether a specific point is

        inside an image and rewrite these methods.

        I hope I answered most, if not all.

        Thanks for you quick, useful and exhaustive response.

        The coordinate problem is solved, I need to apply the transform, thanks. The method to accomplish getRaster()

        should be different from what I thought before, please see the attachment. If there is anything wrong obviously,

        please remind me.

        From Tilman to Shaola

        Hi Shaola,

        Yes it is tricky to think this in reverse; there's a similar problem in the Radial Shading, the developer who did

        this had to solve an equation. (There's a long comment in the code about that)

        From Shaola to Tilman

        Thanks for mentioning the radial shading.

        1. I would use the sub-dividing method to judge whether a point is below or above a cubic Bezier curve, then

        combining the results of 4 curves to decide whether a point is inside or out of a patch, this works in a O(lg)

        time complexity, which should be good enough.

        2. to solve the possible points, in the radial shading case, that equation has an analytic solution, in this

        shading type 6 case, only one equation and the equation has two unknowns with boundaries, the highest order is 4,

        there is no analytic solution. I will try to solve the equation numerically.

        Best,
        Shaola

        Show
        xinshu Shaola Ren added a comment - an even older stuff the reading data part is almost done the code are available at https://bitbucket.org/xinshu/pdfbox.git for webview https://bitbucket.org/xinshu/pdfbox This is stuff edited from the emails from me and Tilman, I am sorry that I didn't post my questions on Jira earlier, hopefully these emails don't have any thing that is not suitable to be published publicly, if there are such issues, Tilman Please, Feel free to delete or edit them. I am sorry for this unconvenience. related file is Shadingtype6week1.pdf May 23 From Shaola to Tilman Hello Tilman, I modified the shading package, and the code are available at https://bitbucket.org/xinshu/pdfbox.git , midway done, may have bugs. However, It’s better to summarize the progress made in this week and talk to you to get some feedback. Any suggestion is appreciated, take you time. I encountered some questions which I put in this powerpoint(attached) and highlighted by blue color. If these questions are too vague, you don’t need to give an explicit answer. Thanks! From Tilman to Shaola Quick answer to use LOG.debug() you must set debug level. This is done in the file "log4j.properties" in the default package of your application. Alternatively, use LOG.info() and it should work immediately (with the command line utility) Here's a sample log4j file with debug level enabled: log4j.rootLogger=DEBUG, A1 #log4j.rootLogger=INFO, A1 A1 is set to be a ConsoleAppender. log4j.appender.A1=org.apache.log4j.ConsoleAppender A1 uses PatternLayout. log4j.appender.A1.layout=org.apache.log4j.PatternLayout log4j.appender.A1.layout.ConversionPattern=%d {dd.MM.yyyy HH:mm:ss.SSS} %-5p [%t] %C:%L - %m%n System.out.println() is the quick way, but you should get used to use "apache log4j". Download it at https://logging.apache.org/log4j/1.2/ and attach it to your calling application. Yes, it takes that long to build. You could probably write a script to copy the class file that is created while editing and insert it to an existing jar file. I assume you could also skip the tests. I just tested this https://maven.apache.org/surefire/maven-surefire-plugin/examples/skipping-test.html just add -DskipTests Hello Shaola, /ShadingType 6 /ColorSpace/DeviceRGB /Decode[-16384 16384 -16384 16384 0 1 0 1 0 1] /BitsPerCoordinate 24 /BitsPerComponent 16 /BitsPerFlag 8 BitsPerCoordinate = 24, it means that the max value in the stream for a coordinate is 0xFFFFFF = 16777215. This is then mapped to the target which has an interval [-16384..16384] with "interpolate". The values you get must then be "transformed" into the physical coordinates, which is done in GouraudShadingContext.transformVertices(). You can probably reuse this. At first, just make yourself a copy; later in the project, it should possibly be merged so that no code exists twice. https://en.wikipedia.org/wiki/Don%27t_repeat_yourself Re "transform", this is two things: 1) PDF related transformations, i.e. mentioned in the PDF 2) java graphics transform: depends on the size of the image. Usually this is a scale, 4.16 for 300dpi. I don't see that you did the transform, which may explain why you get such weird coordinates... and yes, after the transforms, you get physical coords. Look at Gouraud shading, the transform is done at the beginning only, i.e. only once. In getRaster(), you then work with "real, screen" coordinates. I don't think it is useful to generate the points separately, as they are painted only once. The raster in which the other shading classes are writing into is a "Table", somehow. Some people render at 300dpi. An A4 page is about 2500 x 3500 pixels. Re getraster(): yes, getraster only paints a small section. It is called again and again and again. X and Y are physical pixels. I strongly recommend to first "get something simple that works". Even if slow. From there, you can try to make changes, and if these go wrong, you can always go back to the "simple" solution. Hint: output the "raw" coordinates and the interval boundaries in hex. This is done with System.out.println (String.format("%x", val)). This gives you a better idea of the relationships between the numbers. Minor thing: getParamSpaceColor(int i, int j) are these coordinates? If yes, please name them x and y. Same for getPatchCoordinates. I hope I answered most, if not all. Good luck! From Shaola to Tilman 2) java graphics transform: depends on the size of the image. Usually this is a scale, 4.16 for 300dpi. I don't see that you did the transform, which may explain why you get such weird coordinates... and yes, after the transforms, you get physical coords. I will check this, as the transform matrix is optional, I just doubted this but didn't test. Look at Gouraud shading, the transform is done at the beginning only, i.e. only once. In getRaster(), you then work with "real, screen" coordinates. I don't think it is useful to generate the points separately, as they are painted only once. The raster in which the other shading classes are writing into is a "Table", somehow. Some people render at 300dpi. An A4 page is about 2500 x 3500 pixels. This information is useful, it prevents me to think more in this direction. I strongly recommend to first "get something simple that works". Even if slow. From there, you can try to make changes, and if these go wrong, you can always go back to the "simple" solution. I will. Minor thing: getParamSpaceColor(int i, int j) are these coordinates? If yes, please name them x and y. Same for getPatchCoordinates. These are not real coordinates, as before getting real coordinates, cubic Bezier curve needs an assistant parameter to get its points position, the returned value of getPatchCoordinates() is real coordinate, similar to getParamSpaceColor, that is the mapping step. However, I don't need to generate all the point separately as you said, I have to think it in other way as you did in the GouraudShadingContext to check whether a specific point is inside an image and rewrite these methods. I hope I answered most, if not all. Thanks for you quick, useful and exhaustive response. The coordinate problem is solved, I need to apply the transform, thanks. The method to accomplish getRaster() should be different from what I thought before, please see the attachment. If there is anything wrong obviously, please remind me. From Tilman to Shaola Hi Shaola, Yes it is tricky to think this in reverse; there's a similar problem in the Radial Shading, the developer who did this had to solve an equation. (There's a long comment in the code about that) From Shaola to Tilman Thanks for mentioning the radial shading. 1. I would use the sub-dividing method to judge whether a point is below or above a cubic Bezier curve, then combining the results of 4 curves to decide whether a point is inside or out of a patch, this works in a O(lg ) time complexity, which should be good enough. 2. to solve the possible points, in the radial shading case, that equation has an analytic solution, in this shading type 6 case, only one equation and the equation has two unknowns with boundaries, the highest order is 4, there is no analytic solution. I will try to solve the equation numerically. Best, Shaola
        Hide
        xinshu Shaola Ren added a comment -

        those are old stuffs, hopefully there are useful for someone

        got correct contour of shading type 6 image

        the code are available at https://bitbucket.org/xinshu/pdfbox.git

        for webview https://bitbucket.org/xinshu/pdfbox

        related files are in file shading6ContourTest.rar

        This is stuff edited from the emails from me and Tilman, I am sorry that I didn't post my questions on Jira

        earlier, hopefully these emails don't have any thing that is not suitable to be published publicly, if there are

        such issues, Tilman Please, Feel free to delete or edit them. I am sorry for this unconvenience.

        From Shaola to Tilman

        Hi Tilman,

        Now, I can get correct shape of an image of shading type 6, this is the item 1 of my last email. The result of the

        two test files are attached, you will see each patch has a solid color, that's because I still didn't work on color

        calculation, I just gave each point inside a patch the same color. Generally, to accomplish this task(the shape), I

        need to consider 3 cases which I drew in patchCase.jpg labeled with 1, 2, 3. For case 1 and 2, each of them can

        have another 3 subcases which I labeled them with "1,2 could be" at the bottom of patchCase.jpg. The two test files

        only involve cases 1 and 2, the 3rd case is more complex, I need to split one patch into 2 quasi-triangle patch.

        Now the code does not work for case 3.

        The color of a patch is not calculated yet, which is the item 2 of my last email.

        The progress is a little bit slower than I thought, there are many unexpected issues. I think I need to follow plan

        B in my proposal.

        From Tilman to Shaola

        Hi Shaola,

        Don't panic. IMHO you're doing pretty good. Don't forget that you just started a week ago.

        From Tilman to Shaola

        Hello Shaola,

        Look what I found:
        https://www.google.ca/patents/US6552725

        HOWEVER the bad news is that most likely you can't use that solution because it is patented. Apache is a US based

        corporation and software patents are valid there.

        I uploaded more examples in JIRA. Only one of them deals with coons patches.

        Tilman

        From Shaola to Tilman

        Hello Tilman,

        Thanks, the attachment is the contour results of several test files, for coons26.pdf, the result is weird.

        The two new test cases have true hasFunction parameter, they helped me to adjust my reading method to deal with

        this case. I noticed that in the GouraudShadingContext.java, this issue in the method readVertex is not taken into

        account, although in the getRaster(), this case is considered, but I think it will generate a null pointer

        exception when it reads an image of shading type 4 or 5 with a true hasFunction parameter, I didn't test this yet.

        For other issues, with time I think they should be worked out in a way.

        From Tilman to Shaola
        Hi Shaola,

        I believe this is a misunderstanding because the arrangement of the values is different for type 6 than type 4/5.

        See this part of the spec for type 5 on page 324:

        If this entry is present, the color data for each vertex must be specified by a single parametric variable

        rather than by n separate color components.
        ...
        The data stream provides a sequence of Bézier control points and color values that define the shape and colors

        of each patch. All of a patch’s control points are given first, followed by the color values for its corners. Note

        that this differs from a triangle mesh (shading types 4 and 5), in which the coordinates and color of each vertex

        are given together.

        So function = true means that there will be one value. You can handle this as if you had a grayscale image, which

        also means that there is 1 color value.

        Re sequence: you first interpolate to get the value of a point, then you feed that value to the function, which

        will return a Color array. That one you then convert to RGB as in the existing code. In other words, you don't have

        to bother much about the function thing.

        Attached: two examples of coons patches without a function. One RGB and one gray.

        Hi Shaola,

        No, the amount of color values goes like this, if I've understood it correctly:

        hasFunction = true ==> 1 value

        hasFunction = false: depends of colorspace

        gray => 1 value
        rgb => 3 values
        cmyk => 4 values
        other color spaces... who knows.

        Attached you see a coons patch with two color values ("duotone", this is a weird mix of red and black that I took

        from a ps file of Prof. Bill Casselman) and one with 4 (cmyk).

        However I suspect that you did indeed find a bug in my software, i.e. numberofcolorcomponents should be 1 if

        function. Oops. I will research this now that I'm getting better in postscript and create a Gouraud shading with

        function.

        Tilman

        From Shaola to Tilman,

        Hello Tilman,

        I know, the description for has function in shading type 5 and 6 is similar, see file PDF3200_2008.pdf page 198,

        the top paragraph. I just suspected that part, now I see the difference, the null pointer exception happened in my

        code is because for type 6 I need to read at least 2 color values, but there is only 1 color value when hasFunction

        is true, for type 5, there is only 1 color value after each vertex no matter hasFunction is true or false. Thanks.

        With the new test files you attached, I think I can put the evalFunction(values) away without worry it at least

        now.

        I just checked your update in jira PDFBOX-1915, I downloaded the new files. Thanks for reminding me, I received the

        update emails in dev list mail, there are some others, so I didn't pay attention to this specific one.

        Best,
        Shaola

        Hello Tilman,

        I am sorry that I bothered you too much today, now I can get the right data sequence with hasFunction = true. The

        folded image's contour can be got right, as this is just the contour, the folded line is not showed up which is as

        expected not an error. I attached the result. This test file has a non-zero edgeflag, at least now it can prove

        that the read of data stream and management of non-zero edgeflag case are correct.

        I updated my web repository, there is too much redundant code as this is still in process.

        Best,
        Shaola

        Yes, there is some trick, however for the shading type 6, it seems I just got it right with you hint, but not

        exactly as you said. Sometimes, even a not that right answer is helpful, thanks.

        Show
        xinshu Shaola Ren added a comment - those are old stuffs, hopefully there are useful for someone got correct contour of shading type 6 image the code are available at https://bitbucket.org/xinshu/pdfbox.git for webview https://bitbucket.org/xinshu/pdfbox related files are in file shading6ContourTest.rar This is stuff edited from the emails from me and Tilman, I am sorry that I didn't post my questions on Jira earlier, hopefully these emails don't have any thing that is not suitable to be published publicly, if there are such issues, Tilman Please, Feel free to delete or edit them. I am sorry for this unconvenience. From Shaola to Tilman Hi Tilman, Now, I can get correct shape of an image of shading type 6, this is the item 1 of my last email. The result of the two test files are attached, you will see each patch has a solid color, that's because I still didn't work on color calculation, I just gave each point inside a patch the same color. Generally, to accomplish this task(the shape), I need to consider 3 cases which I drew in patchCase.jpg labeled with 1, 2, 3. For case 1 and 2, each of them can have another 3 subcases which I labeled them with "1,2 could be" at the bottom of patchCase.jpg. The two test files only involve cases 1 and 2, the 3rd case is more complex, I need to split one patch into 2 quasi-triangle patch. Now the code does not work for case 3. The color of a patch is not calculated yet, which is the item 2 of my last email. The progress is a little bit slower than I thought, there are many unexpected issues. I think I need to follow plan B in my proposal. From Tilman to Shaola Hi Shaola, Don't panic. IMHO you're doing pretty good. Don't forget that you just started a week ago. From Tilman to Shaola Hello Shaola, Look what I found: https://www.google.ca/patents/US6552725 HOWEVER the bad news is that most likely you can't use that solution because it is patented. Apache is a US based corporation and software patents are valid there. I uploaded more examples in JIRA. Only one of them deals with coons patches. Tilman From Shaola to Tilman Hello Tilman, Thanks, the attachment is the contour results of several test files, for coons26.pdf, the result is weird. The two new test cases have true hasFunction parameter, they helped me to adjust my reading method to deal with this case. I noticed that in the GouraudShadingContext.java, this issue in the method readVertex is not taken into account, although in the getRaster(), this case is considered, but I think it will generate a null pointer exception when it reads an image of shading type 4 or 5 with a true hasFunction parameter, I didn't test this yet. For other issues, with time I think they should be worked out in a way. From Tilman to Shaola Hi Shaola, I believe this is a misunderstanding because the arrangement of the values is different for type 6 than type 4/5. See this part of the spec for type 5 on page 324: If this entry is present, the color data for each vertex must be specified by a single parametric variable rather than by n separate color components. ... The data stream provides a sequence of Bézier control points and color values that define the shape and colors of each patch. All of a patch’s control points are given first, followed by the color values for its corners. Note that this differs from a triangle mesh (shading types 4 and 5), in which the coordinates and color of each vertex are given together. So function = true means that there will be one value. You can handle this as if you had a grayscale image, which also means that there is 1 color value. Re sequence: you first interpolate to get the value of a point, then you feed that value to the function, which will return a Color array. That one you then convert to RGB as in the existing code. In other words, you don't have to bother much about the function thing. Attached: two examples of coons patches without a function. One RGB and one gray. Hi Shaola, No, the amount of color values goes like this, if I've understood it correctly: hasFunction = true ==> 1 value hasFunction = false: depends of colorspace gray => 1 value rgb => 3 values cmyk => 4 values other color spaces... who knows. Attached you see a coons patch with two color values ("duotone", this is a weird mix of red and black that I took from a ps file of Prof. Bill Casselman) and one with 4 (cmyk). However I suspect that you did indeed find a bug in my software, i.e. numberofcolorcomponents should be 1 if function. Oops. I will research this now that I'm getting better in postscript and create a Gouraud shading with function. Tilman From Shaola to Tilman, Hello Tilman, I know, the description for has function in shading type 5 and 6 is similar, see file PDF3200_2008.pdf page 198, the top paragraph. I just suspected that part, now I see the difference, the null pointer exception happened in my code is because for type 6 I need to read at least 2 color values, but there is only 1 color value when hasFunction is true, for type 5, there is only 1 color value after each vertex no matter hasFunction is true or false. Thanks. With the new test files you attached, I think I can put the evalFunction(values) away without worry it at least now. I just checked your update in jira PDFBOX-1915 , I downloaded the new files. Thanks for reminding me, I received the update emails in dev list mail, there are some others, so I didn't pay attention to this specific one. Best, Shaola Hello Tilman, I am sorry that I bothered you too much today, now I can get the right data sequence with hasFunction = true. The folded image's contour can be got right, as this is just the contour, the folded line is not showed up which is as expected not an error. I attached the result. This test file has a non-zero edgeflag, at least now it can prove that the read of data stream and management of non-zero edgeflag case are correct. I updated my web repository, there is too much redundant code as this is still in process. Best, Shaola Yes, there is some trick, however for the shading type 6, it seems I just got it right with you hint, but not exactly as you said. Sometimes, even a not that right answer is helpful, thanks.
        Hide
        xinshu Shaola Ren added a comment -

        A strategy to decide patch coordinates and color

        the code are available at https://bitbucket.org/xinshu/pdfbox.git

        for web view https://bitbucket.org/xinshu/pdfbox

        This is stuff edited from the emails from me and Tilman, I am sorry that I didn't post my questions on Jira

        earlier, hopefully these emails don't have any thing that is not suitable to be published publicly, if there are such

        issues, Tilman, Please, Feel free to delete or edit them. I am sorry for this unconvenience.

        Hello Shaola,

        I can't really decide about the strategy because it involves math and this is my weak point. What I have understood

        so far is:

        • you have problem using the strategy mentioned in the project description, i.e. deciding color and position

        (inside/outside) in getRaster() based on the current point. Because you can easily draw a coons patch by having an

        image to draw into, but not the opposite way, i.e. having a point and then decide.

        • you can possibly do it if you are using a helper table, but that can cost memory
        • another strategy is to divide the patch into tiny triangles (which will create something not-so-perfect like I

        e-mailed you)

        As I said, I favor a strategy that gives results first. One could also use a misc strategy, i.e. one for the

        unfolded patches and one for the folded ones.

        You can also ask math questions on http://math.stackexchange.com, as long as these are specific questions on small

        problems, and that you credit the answer in your code.

        Some general stuff:

        • did you read my "community bonding period" message in the dev list? I realize that we're not respecting the

        rules, i.e. this technical talk should be in the JIRA issue. The best would be that you write a summary and post it

        there, or open a comment with copy&paste with each of the mails, and also attach that drawing, and the patch

        outlines. I think this is about 3-5 mails only.
        You don't have to do it immediately, but it should be done by the end of the week.

        • the more general talk about pdfbox can be in the dev list.
        • please post the bitbucket URL in the JIRA issue
        • The advantage is that other developers can also give you good advice, not just me
        • what you're working on is kindof the "top of the pyramid" for shadings. Several other open source programs

        support only shadings 1-3, same for several closed source programs. If you succeed, the Google summer of code is a

        great addition to your CV!

        Tilman

        Am 28.05.2014 16:35, schrieb 任少辣:
        > Hello Tilman,
        >
        > I thought it more, may be first just focus on getting an image close to the original image, I mean the expected

        image will be less smooth than the original one.
        >
        > I can avoid to generate all the points information by creating a triangle list similar to shading type 5 after

        step 2, then the accomplishment is reduced to triangle meshes. The cubic Bezier curve information and bilinear

        interpolation of color are reserved as well, as they are used in step 1 and 2. For this updated method, I have more

        confidence if you can bear the error I mean the image will be less smooth as I need to approximate a curve segment

        to a line segment, with a trade off of speed, the error can be adjusted by changing the density of the grid.
        >
        > Sorry for the frequent changes, but we should admit that just learning the information in the pdf document is not

        sufficient, at least I think this is the truth.
        >
        > Best,
        > Shaola
        >
        > Sorry, there is a calculation typo in the last email if you received, 20 x 9 x 10^4 bytes ~ 2 MB, not 20 x 9 x

        10^2 bytes ~ 2 MB
        >
        > Maybe it is worth to try my original method, with this method, I think at least it may give a complete result for

        the test files I already have.
        >
        > The details of the method is as following, it generates every point in a patch, now every point in a patch is

        created by search.
        >
        > A unit patch mapped to a real patch, the real patch can be described by the assistant variable u and v in the

        unit patch.
        >
        > 1. dividing the unit patch into a m x n grid, then using cubic bezier curve, I can map this grid to the real

        patch, during this process, the coordinate and color of cross point can be determined directly (cubic bezier curve

        and bilinear interpolation).
        >
        > 2. in the mapped patch, the curve which forms the mapped grid will be taken as a composition of many line

        segments, then the whole mapped patch is formed by many small quadrilaterals, splitting each quadrilateral into two

        triangle as I showed in the graph to solve the potential folding issue, now for each triangle, the color and

        position of each corner are already calculated, for the points inside a triangle, the color is calculated by

        barycentric interpolation. The color priority at each point is considered automatically.
        >

        *******************************************************************************************************************

        ******************************************************************
        > This difficult part of this method is to ensure to generate every points inside the patch, I did some code last

        week, but didn't test thoroughly.
        >
        > 3. for each generated point type is Point not Point2D, they will be stored in a hashmap, point is key, the value

        is the corresponding color value, the value cannot be an array, should be an object, so a class PixelColor is

        needed, I only store these point inside a patch.
        >
        > 4. all the above steps will be done by a separate method in Type6ShadingContext.java, the method will be only

        called once for each patch, as I will create another field in class Type6ShadingContext called private

        HashMap<Point, PixelColor> positionAndColor, this field is initialized using the previous method in

        Type6ShadingContext's constructor.
        >
        > 5. for multiple patches, I may need to unite their hashmap positionAndColor together to totalmap.
        >
        > 6. to accomplish getRaster(), for each (i + row, j + col), I will check whether it is contained in the totalmap,

        if contains, gives it the corresponding color, if not, gives it the background color if applicable.
        >
        > Memory consumption, each (key, value) pair, key 4 + 4 bytes, value 4 + 4 + 4 bytes, for the tested files I have

        now, the patch part is about 300 pixels x 300 pixels, so about 20 x 9 x 10^4 bytes ~ 2 MB, as using hashmap, I

        would say 6 MB will be used. For larger images, it maybe a problem, but very large images will create problems(both

        speed and memory) for the searching method as well.
        >
        > I think I need your opinion before I really start to code this method, as there is a risk to waste time before

        getting a decent result. My oponion is that it is worth to try if there is no better method.
        >
        > Best,
        > Shaola

        Show
        xinshu Shaola Ren added a comment - A strategy to decide patch coordinates and color the code are available at https://bitbucket.org/xinshu/pdfbox.git for web view https://bitbucket.org/xinshu/pdfbox This is stuff edited from the emails from me and Tilman, I am sorry that I didn't post my questions on Jira earlier, hopefully these emails don't have any thing that is not suitable to be published publicly, if there are such issues, Tilman, Please, Feel free to delete or edit them. I am sorry for this unconvenience. Hello Shaola, I can't really decide about the strategy because it involves math and this is my weak point. What I have understood so far is: you have problem using the strategy mentioned in the project description, i.e. deciding color and position (inside/outside) in getRaster() based on the current point. Because you can easily draw a coons patch by having an image to draw into, but not the opposite way, i.e. having a point and then decide. you can possibly do it if you are using a helper table, but that can cost memory another strategy is to divide the patch into tiny triangles (which will create something not-so-perfect like I e-mailed you) As I said, I favor a strategy that gives results first. One could also use a misc strategy, i.e. one for the unfolded patches and one for the folded ones. You can also ask math questions on http://math.stackexchange.com , as long as these are specific questions on small problems, and that you credit the answer in your code. Some general stuff: did you read my "community bonding period" message in the dev list? I realize that we're not respecting the rules, i.e. this technical talk should be in the JIRA issue. The best would be that you write a summary and post it there, or open a comment with copy&paste with each of the mails, and also attach that drawing, and the patch outlines. I think this is about 3-5 mails only. You don't have to do it immediately, but it should be done by the end of the week. the more general talk about pdfbox can be in the dev list. please post the bitbucket URL in the JIRA issue The advantage is that other developers can also give you good advice, not just me what you're working on is kindof the "top of the pyramid" for shadings. Several other open source programs support only shadings 1-3, same for several closed source programs. If you succeed, the Google summer of code is a great addition to your CV! Tilman Am 28.05.2014 16:35, schrieb 任少辣: > Hello Tilman, > > I thought it more, may be first just focus on getting an image close to the original image, I mean the expected image will be less smooth than the original one. > > I can avoid to generate all the points information by creating a triangle list similar to shading type 5 after step 2, then the accomplishment is reduced to triangle meshes. The cubic Bezier curve information and bilinear interpolation of color are reserved as well, as they are used in step 1 and 2. For this updated method, I have more confidence if you can bear the error I mean the image will be less smooth as I need to approximate a curve segment to a line segment, with a trade off of speed, the error can be adjusted by changing the density of the grid. > > Sorry for the frequent changes, but we should admit that just learning the information in the pdf document is not sufficient, at least I think this is the truth. > > Best, > Shaola > > Sorry, there is a calculation typo in the last email if you received, 20 x 9 x 10^4 bytes ~ 2 MB, not 20 x 9 x 10^2 bytes ~ 2 MB > > Maybe it is worth to try my original method, with this method, I think at least it may give a complete result for the test files I already have. > > The details of the method is as following, it generates every point in a patch, now every point in a patch is created by search. > > A unit patch mapped to a real patch, the real patch can be described by the assistant variable u and v in the unit patch. > > 1. dividing the unit patch into a m x n grid, then using cubic bezier curve, I can map this grid to the real patch, during this process, the coordinate and color of cross point can be determined directly (cubic bezier curve and bilinear interpolation). > > 2. in the mapped patch, the curve which forms the mapped grid will be taken as a composition of many line segments, then the whole mapped patch is formed by many small quadrilaterals, splitting each quadrilateral into two triangle as I showed in the graph to solve the potential folding issue, now for each triangle, the color and position of each corner are already calculated, for the points inside a triangle, the color is calculated by barycentric interpolation. The color priority at each point is considered automatically. > ******************************************************************************************************************* ****************************************************************** > This difficult part of this method is to ensure to generate every points inside the patch, I did some code last week, but didn't test thoroughly. > > 3. for each generated point type is Point not Point2D, they will be stored in a hashmap, point is key, the value is the corresponding color value, the value cannot be an array, should be an object, so a class PixelColor is needed, I only store these point inside a patch. > > 4. all the above steps will be done by a separate method in Type6ShadingContext.java, the method will be only called once for each patch, as I will create another field in class Type6ShadingContext called private HashMap<Point, PixelColor> positionAndColor, this field is initialized using the previous method in Type6ShadingContext's constructor. > > 5. for multiple patches, I may need to unite their hashmap positionAndColor together to totalmap. > > 6. to accomplish getRaster(), for each (i + row, j + col), I will check whether it is contained in the totalmap, if contains, gives it the corresponding color, if not, gives it the background color if applicable. > > Memory consumption, each (key, value) pair, key 4 + 4 bytes, value 4 + 4 + 4 bytes, for the tested files I have now, the patch part is about 300 pixels x 300 pixels, so about 20 x 9 x 10^4 bytes ~ 2 MB, as using hashmap, I would say 6 MB will be used. For larger images, it maybe a problem, but very large images will create problems(both speed and memory) for the searching method as well. > > I think I need your opinion before I really start to code this method, as there is a risk to waste time before getting a decent result. My oponion is that it is worth to try if there is no better method. > > Best, > Shaola
        Hide
        tilman Tilman Hausherr added a comment -

        Reuploaded the previous files to show that they have a function. Also created files without function and with different color spaces. (Gray, RGB, CMYK, Duotone)

        Show
        tilman Tilman Hausherr added a comment - Reuploaded the previous files to show that they have a function. Also created files without function and with different color spaces. (Gray, RGB, CMYK, Duotone)
        Hide
        tilman Tilman Hausherr added a comment - - edited

        Two examples of a coons patch in PostScript. I found the first one on the usenet (messageid 20021112083949.7bf2c92e.rswan@sympatico.ca posted by Robert Swan in 2002), the second one is modified from the first. When converting to PDF with ghostscript, set version 1.5 in the options, to avoid it being converted into an image.

        Show
        tilman Tilman Hausherr added a comment - - edited Two examples of a coons patch in PostScript. I found the first one on the usenet (messageid 20021112083949.7bf2c92e.rswan@sympatico.ca posted by Robert Swan in 2002), the second one is modified from the first. When converting to PDF with ghostscript, set version 1.5 in the options, to avoid it being converted into an image.
        Hide
        tilman Tilman Hausherr added a comment -

        GWG test file with ShadingType 2, 3 and 7.

        Show
        tilman Tilman Hausherr added a comment - GWG test file with ShadingType 2, 3 and 7.
        Hide
        tilman Tilman Hausherr added a comment -

        Patch H of the Altona Test Suite 2.0, this contains every type of shading. The bad news is that even those that are implemented are not rendered correctly.
        http://www.eci.org/en/downloads#altona_test_suite

        Show
        tilman Tilman Hausherr added a comment - Patch H of the Altona Test Suite 2.0, this contains every type of shading. The bad news is that even those that are implemented are not rendered correctly. http://www.eci.org/en/downloads#altona_test_suite
        Hide
        smalser Sergey Smal added a comment -

        Sorry, i visited that site before registration opens, that's why i asked a question.
        I find everything I need, thanks again

        Show
        smalser Sergey Smal added a comment - Sorry, i visited that site before registration opens, that's why i asked a question. I find everything I need, thanks again
        Hide
        tilman Tilman Hausherr added a comment -

        Hello Sergey, it is a project for GSoC 2014, that is how you found it If your question is how you can apply, this is done at https://www.google-melange.com/ .

        Show
        tilman Tilman Hausherr added a comment - Hello Sergey, it is a project for GSoC 2014, that is how you found it If your question is how you can apply, this is done at https://www.google-melange.com/ .
        Hide
        smalser Sergey Smal added a comment -

        Thanks a lot for your reply!
        How can I get this issue as a project for GSoC 2014?

        Show
        smalser Sergey Smal added a comment - Thanks a lot for your reply! How can I get this issue as a project for GSoC 2014?
        Hide
        tilman Tilman Hausherr added a comment -

        Yes there's only the PDF spec and the test images (you can possibly generate more test images with Postscript or Asymptote. There are possibly resources about the sub-problems, i.e. whether a point is inside or outside a patch, or how to interpolate but I can't really tell if a google search would be successful because I don't have the math background.

        Here's one I just found, it has a LOT of math:
        http://www.mapleprimes.com/posts/100287-Coons-Patch-Examples

        Another one, sadly only in german:
        http://www10.informatik.uni-erlangen.de/Teaching/Courses/SS2005/AlgoIII/Folien/Algo3%2016.pdf

        Show
        tilman Tilman Hausherr added a comment - Yes there's only the PDF spec and the test images (you can possibly generate more test images with Postscript or Asymptote. There are possibly resources about the sub-problems, i.e. whether a point is inside or outside a patch, or how to interpolate but I can't really tell if a google search would be successful because I don't have the math background. Here's one I just found, it has a LOT of math: http://www.mapleprimes.com/posts/100287-Coons-Patch-Examples Another one, sadly only in german: http://www10.informatik.uni-erlangen.de/Teaching/Courses/SS2005/AlgoIII/Folien/Algo3%2016.pdf
        Hide
        smalser Sergey Smal added a comment -

        Hello, my name is Sergey Smal, I'm student of MIPT from Russia.
        I'm plannig to take part in GSoC 2014 and find that issue very interesting for me.

        I've already tested pdfbox-app-1.8.4 with some PDFs and look through code from repository.
        I think that I can solve this issue because I have rather good mathematical background and experience in java programming.
        BTW: have some experience with "cubic Bezier curves". I found bug and proposed a solution of it in degrfa library

        Is PDF specification is all that I need to implement type 6 and 7 of shading methods?
        If you have any additional links for those methods, can you share them?

        Show
        smalser Sergey Smal added a comment - Hello, my name is Sergey Smal, I'm student of MIPT from Russia. I'm plannig to take part in GSoC 2014 and find that issue very interesting for me. I've already tested pdfbox-app-1.8.4 with some PDFs and look through code from repository. I think that I can solve this issue because I have rather good mathematical background and experience in java programming. BTW: have some experience with "cubic Bezier curves". I found bug and proposed a solution of it in degrfa library Is PDF specification is all that I need to implement type 6 and 7 of shading methods? If you have any additional links for those methods, can you share them?

          People

          • Assignee:
            xinshu Shaola Ren
            Reporter:
            tilman Tilman Hausherr
          • Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development