[OpenJDK 2D-Dev] Review Request for JDK-7116979 : Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED

[Brian Burkhalter]

How do create the palette?

Brian

On Feb 15, 2016, at 3:39 AM, Jayathirth D V <jayathirth.d.v at oracle.com> 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 at 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
> >

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20160215/c172ee8f/attachment.html>