Hi Jayathirth,
The issue with testing performance with white images is that the tests
allow the code to eliminate 3 indexed fetches which take time. Primary
colors end up being the one obscure case where the new code might be
faster. But, non-primary colors would be slower by a fair amount, so
performance testing with converting a randomized or non-primary-color
image are the more telling case. An image filled with 255,255,128 would
be the worst case because it would involve all of the tests and still
have to do all of the lookups.
My question about how this works with custom colormaps was not really
addressed by your response. A simple test to make sure the colormap has
accurate (or very close) conversions for the primary colors may be
enough to validate the colormap for the indicated tests. If the
colormap contains no pure conversions for some of the primary colors
then they may need to be dithered anyway...
...jim
On 2/15/16 3:39 AM, Jayathirth D V wrote:
Hi Jim,
I performed performance analysis with white image so that all conditions
are checked in the new branch added. There is no major difference in
time taken before and after change. For each input I have tested time
taken for drawImage() API to convert from every format to Byte indexed
type. For every unique conversion test is run for 100 times. Please find
the details:
Input
type
Min
before change
(ns)
Min
after change
(ns)
Max
before change
(ns)
Max
after change
(ns)
Average
before change
(ns)
Average
after
change
(ns)
INT_RGB
523437
481491
1230724
1270440
789452
666144
INT_ARGB
500232
493986
12406307
1308816
793384
654015
INT_ARGB_PRE
500233
492201
1037057
981277
710250
699214
INT_BGR
537716
562706
1446703
2046001
862377
863256
3BYTE_BGR
483275
481045
1181638
1384676
651427
580961
4BYTE_ABGR
544410
499786
1292305
968783
690106
683881
4BYTE_ABGR_PRE
504249
505588
1680086
1216445
756101
687750
USHORT_565_RGB
507818
505588
978153
1346746
652908
655782
USHORT_555_RGB
510496
509604
952272
1162004
650418
670811
BYTE_GRAY
481491
478367
1140585
1799231
691160
583250
USHORT_GRAY
506927
507373
1375751
1255267
728202
646902
BYTE_BINARY
541733
496217
1083466
959411
730527
728461
The changes are tested with plain images having primary colors like RED,
GREEN, BLUE, BLACK and WHITE.
Thanks,
Jay
-----Original Message-----
From: Jim Graham
Sent: Friday, February 12, 2016 4:05 AM
To: Jayathirth D V; 2d-dev@openjdk.java.net; Philip Race; Prasanta Sadhukhan
Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7116979 :
Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED
Hi Jayathirth,
Did you do any performance analysis of this change? You are adding 6
tests and multiple branches to per-pixel code.
The effectiveness of this technique depends on the colormap that we have
set up. For the BufferedImage.TYPE_INDEXED constructor we produce a
fairly nice colormap, but if someone creates a custom colormap then the
colors could be anything. We create a decent inversion for just about
any colormap, but that doesn't mean that using only "the best match for
solid red" will produce a better result for a dithered approximation for
red. It is true that if there is a really good match for red then we
should just use that, but if there are no direct matches for red then we
may choose to paint a red region with solid orange even though there is
another color in the colormap that when mixed with orange approximates a
red tone better. For example, if a colormap contains no pure red, but
contains:
240, 20, 0
240, 0, 20
(I'm not sure if 20 is within our current error deltas that we use for
dithering, but this is an example not a test case.)
Then using one of these alone might skew the color towards orange or
purple. Using both together in a dither pattern might keep the overall
hue impression as red, but with a small amount of noise in its saturation.
What types of colormaps was this tested with?
...jim
On 2/11/16 6:37 AM, Jayathirth D V wrote:
Hi,
_Please review the following fix in JDK9:_
__
Bug :https://bugs.openjdk.java.net/browse/JDK-7116979
Webrev :http://cr.openjdk.java.net/~jdv/7116979/webrev.00/
Issue : When Image containing black pixels are converted from any
format to Byte Indexed format some of the pixels are not black. They
are following pattern similar to dithering.
Root cause : When we convert any format type to ByteIndexed we are
adding Error delta values to R,G,B components using dithering indices.
This is causing some pixels values to not point to proper index in
color table.
Solution : There is no need to add error delta for primary colors
containing basic values in R,G,B components. Exclude such pixels from
delta addition.
Thanks,
Jay
