Issue 120604 - curious colors in gradients, when using small step-count
Summary: curious colors in gradients, when using small step-count
Alias: None
Product: Draw
Classification: Application
Component: viewing (show other issues)
Version: 4.0.0-dev
Hardware: All Windows XP
: P3 Normal (vote)
Target Milestone: 4.0.0
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Blocks: 120957
  Show dependency treegraph
Reported: 2012-08-17 09:47 UTC by Regina Henschel
Modified: 2013-07-12 16:20 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Testcases for axial gradient (11.90 KB, application/vnd.oasis.opendocument.presentation)
2012-08-17 09:47 UTC, Regina Henschel
no flags Details
History of axial filling (44.54 KB, image/png)
2012-09-06 18:51 UTC, Regina Henschel
no flags Details
Calculate colors using a macro (45.08 KB, application/vnd.oasis.opendocument.spreadsheet)
2012-09-13 14:24 UTC, Regina Henschel
no flags Details
suggestions for texture (2D) and gradienttools (3D) (3.19 KB, patch)
2012-09-25 18:35 UTC, Regina Henschel
rb.henschel: review? (rb.henschel)
Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description Regina Henschel 2012-08-17 09:47:20 UTC
Created attachment 78992 [details]
Testcases for axial gradient

Open attached document. It shows some test cases.

I expect, that an axial gradient is a mirrored linear gradient. So a linear filling of 10cm height should be the same as the half of an axial gradient in 20cm height. This works well with a step count of 256 (max possible value in UI). But when you set the step count to 5, you see these errors:
- The number of steps in the axial fill is not 2*5=10 but 8
- The inner color does not come near enough to the center color.

Compared to a square filling all is good in maximal step count 256. Setting the step count to 5 you can see these errors (or at least inconsistencies)
- The colors of the linear gradient have a different scale than the colors in the square gradient. The square gradient reaches the end color, the linear gradient does not reach it.
- The colors of the axial gradient reach neither the start not the end color.
- The colors of an axial gradient are reversed in comparison to a square gradient. A square gradient has the end color in center, but the axial gradient has the start color in center. 

Show the axial gradient in presentation mode or print it (I have used image writer), then the gradient is totally wrong. (This is an old error, but I have not fount an issue, that tracks it already.)
Comment 1 Regina Henschel 2012-08-17 11:51:50 UTC
I suggest to make the steps consistent over all gradient styles. If the interval [0;1] has the end color on scale position 1 and the start color on scale position 0 and ]a;b] in one of the subintervals, then draw this interval in the color of scale position b, the upper border of the interval. Reasoning: Users can always force to see the start color (scale position 0) in there drawing by setting an appropriate border. That is not possible for the end color.
Comment 2 Armin Le Grand 2012-08-20 10:44:27 UTC
ALG: Adding myself to CC.
Comment 3 Regina Henschel 2012-09-06 18:51:52 UTC
Created attachment 79324 [details]
History of axial filling

The attached picture collects screenshots of several versions. From SO 5.2 to OOo2.4.3 (at least) the axial gradient uses the color step count n as given in the UI. OOo3.2.1 uses 2n-1 steps and AOO3.4.1 uses 2n-2 steps. The ODF does specify how many steps to use in axial gradients.

The colors in OOo3.2.1 and AOO3.4.1 are different.

The axial gradient has still the old step count, when the shape is in presentation mode in Impress or when it is converted or exported to bitmap or when it is exported to pdf or flash.
Comment 4 Regina Henschel 2012-09-13 14:24:32 UTC
Created attachment 79492 [details]
Calculate colors using a macro

I have written issue 120604 for the export error of gradient style axial.

So this issue can track the errors in edit mode. Those are:
Gradient style linear does not use the end color.
Gradient style axial does not use the start color, does not use the end color, and has a wrong number of steps.

This defects can be best seen when using step counts smaller than 10.
The gradient style square shows the correct colors and can be used for comparison.

I think, the issue can be used for both errors, because the same file is effected.

The attachment contains a spreadsheet with macro. The macro takes the RGB-values left from the selected cell and fills the selected cell with that color. You can use it to examine color calculations.
Comment 5 Regina Henschel 2012-09-24 22:54:24 UTC
I've started working on this issue.
Comment 6 Regina Henschel 2012-09-25 18:35:01 UTC
Created attachment 79636 [details]
suggestions for texture (2D) and gradienttools (3D)

In gradienttools.hxx there is currently a case
 "if(nSteps > 2L && nSteps < 128L)"
Why "> 2L"?

Is there something else needed for linear and axial gradients?

The other gradient styles have a little bit false colors too. The step to the end color is too large. But before I will adapt them too, I need to know whether you agree with the colors in linear and axial gradient, and if yes, whether square/rectangular and circle/ellipsoid should be adapted to the new blending of linear/axial.

Tip for testing: Using "Chart 12" and "Yellow" gives steps, which can be clearly distinguished.
Comment 7 Armin Le Grand 2012-10-01 17:46:09 UTC
ALG: Took the time to completely redefine this one, esp. under the aspect to make things safer. There are no longer two vectors, one for transformation and one for colors, where size of colors should be size of transformation + 1 (for start color); changed to use an explicit struct combining both and creating both in one loop; start color is isolated and used extra. Made some more adjustments for safety and runtime. Doing some more tests (AA, non-AA, XOr-Paint (old non-AA modes)), ...
Comment 8 Regina Henschel 2012-10-01 18:35:44 UTC
Fine :)
I need some time to find the comment in fillgradientprimitive2d.cxx, which tells me, why it does not work (=crash) to simple increase the number of transformations.
BTW, the fact that aUnitPolygon for axial gradient is starting in -1,-1 is unexpected too, though it is a nice trick to get the mirroring with fabs(y). Perhaps you can add a comment?
Comment 9 Armin Le Grand 2012-10-02 09:11:09 UTC
ALG: I decided to change all to use a unit geometry (rectangle and circle currently only) all being defined from (-1,-1,1,1), thus it is now unified and the meaning is no lnger dependent of the gradient type (which only brings dangers).
Comment 10 Armin Le Grand 2012-10-02 09:24:34 UTC
ALG: COmmited those basic changes. Need to check for 3D now (still looking wrong)...
Comment 11 Armin Le Grand 2012-10-02 12:09:30 UTC
ALG: Okay, committed adaptions for coordinate back mappers for texture transformations. Should be done.
Comment 12 Armin Le Grand 2012-10-04 16:27:56 UTC
ALG: Needed to adapt coordinate back mappers (3D gradients) a little bit. There was the wrong color when using axial and a border, and the bottom/right of rectangles with gradient mapping were suspect. Also adapted and made basegfx smarter in some parts. Committed with revision 1394141.