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

[Jayathirth D V]

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/3648d04c/attachment.html>