[regression] Filter troubles...

[Bill Haneman <Bi...@ireland.sun.com>]

Hi:

There seems to be a problem with the filters at the moment,
many of the sample files have regressed.  The problem seems
to affect the color mapping somehow - see batikBatik.svg and
chessboard.svg for example...

As I said already to Thomas, I recognise that the new behavior
might be the correct one :-( in which case we need to fix the
sample files.  Anyone have the answer?

Thanks,

-Bill

------
Bill Haneman x19279
Ireland Desktop Engineering
Sun Microsystems Ireland Ltd.

[regression] Filter troubles...

[Thomas E Deweese <th...@kodak.com>]

>>>>> "BH" == Bill Haneman <Bi...@ireland.sun.com> writes:

BH> There seems to be a problem with the filters at the moment, many
BH> of the sample files have regressed.  The problem seems to affect
BH> the color mapping somehow - see batikBatik.svg and chessboard.svg
BH> for example...

BH> As I said already to Thomas, I recognise that the new behavior
BH> might be the correct one :-( in which case we need to fix the
BH> sample files.  Anyone have the answer?

    The "problem" is definitely the change to processing in linear
sRGB.  I have 'fixed' batikBatik.svg by inserting gratuitous
feComponentTransfer filters with 'gamma = 2.4' at the start and
'gamma=.42' at the end of the various filter chains.  This makes
batikBatik look the way it did originally, of course it also slows it
down a bit (not too much I don't think).

    So this is the quick solution, the correct solution is to rework
the filters to behave correctly in linear sRGB.  So the various tables
in batikBatik should be replaced with tables that expect linear sRGB,
there would still be some differences given that the matrix is now
working on linear code values, but since that is the "correct" color
space for matrix manipulation (a linear operation), the current
processing is arguably "wrong" (what ever that means when the whole
thing is based on artistic intent vs. some concrete colorometric
analysis).

    Incidentally there was talk about adding some of the timing code
back in.  I know it would help me a lot to know if I introduce any
significant performance regressions or improvements.  As it is now I
end up 'eyeballing' it, or trying to use 'date' neither is very
accurate (a 2x change could easily go unnoticed, and almost did for
the linear sRGB stuff).