Hi Erik,

There are likely 2 different issues that you are dealing with here.
First is the issue of dithering during drawing vs. during imaging.  We
currently do dithering when rendering an image into a lower color
resolution destination, but we don't do any dithering at all when we do
draw and fill types of rendering.

So, if you are using draw/fill<Geometry>(...) types of calls then you
would be seeing thresholding of the solid color.  This is something that
we always meant to go back and fix, but there isn't much call for high
quality rendering to low color resolution destinations in today's world
of high memory and deep color displays.  To force some dithering you
could use a workaround to force the geometry calls to use imaging
operations.  One workaround would be to render to a higher color
destination and then copy the high color image into the B/W destination
using a drawImage().  That should force dithering.  Another workaround
would be to use a custom Paint which simply returns a raster containing
a solid color.  We currently implement Paint rendering as a series of
imaging operations so that would invoke our dithering as well.  You
could use your own custom Paint or you could use a GradientPaint with
both colors the same for example.  A color with an alpha value of less
than 1.0 (.9999f for float constructors or 254 for int constructors)
might also trigger a slower dithering algorithm.

On the other hand, even if you do use one of those workarounds, I'm
afraid our dithering implementation is optimized more for a decent
performance and acceptable quality compromise on 8-bit destinations than
it is for lower color destinations.  There isn't much call for rendering
to lower color destinations these days given the wide prevalence of full
color screens and imagery so this has been a low priority.

The low priority of this type of rendering is perhaps reflected by the
fact that I couldn't find any open bugs against this problem, though I
know that anyone who would try to render into a monochrome image would
run into this.  Please submit a bug with some example code so that we
can track the issue and provide a place for others to vote if they are
affected by this problem as well...

                       ...jim

Erik Vanherck wrote:
Hi,

In a certain piece of code we were using Jai to dither a rendering of our
chart objects, however this caused some performance issues and we noticed
the RenderingHints.KEY_DITHERING so we tried moving the dithering into the
rendering of the chart that was already using the graphics2D of a
bufferedImage. While very performant, it doesn't yield the expected
result. Instead of dithered it gives us a thresholded black and white
image. I found very little information about the dithering hint while
googling and searching the forums, except people asking how to turn it off
;-)

Now my question is, should the pseudo code below work ?

<--- code snippet --->

byte[] map = {(byte)0xFF, (byte)0x00};
final BufferedImage buf = new BufferedImage(Math.round(fWidth*scale),
Math.round(fHeight*scale), BufferedImage.TYPE_BYTE_BINARY, new
IndexColorModel(1,2,map,map,map));
final Graphics2D g2 = (Graphics2D)buf.getGraphics();
g2.setRenderingHint(RenderingHints.KEY_DITHERING,RenderingHints.VALUE_DITHER_ENABLE);
g2.scale(scale,scale);
fChart.setGraphics2D(g2);
fChart.render();
return buf;

<--- code snippet --->

For reference we are using jdk 1.4.2_08 and any solution should work in
java.awt.headless mode.

Any feedback is highly appreciated

Best regards,
Erik

---------

Erik Vanherck  -  Product Delivery Manager
Inventive Designers
Visit http://www.inventivedesigners.com
Visit http://www.inventivedesigners.com/scriptura for Scriptura
information !

Phone: +32 - 3 - 8210170
Fax: +32 - 3 - 8210171
Email: [EMAIL PROTECTED]

"Computers in the future may weigh no more than 1.5 tons." - Popular
Mechanics, forecasting the relentless march of science, 1949
 --------------------------------------------------
Inventive Designers' Email Disclaimer:
 http://www.inventivedesigners.com/email-disclaimer

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA2D-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".


===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA2D-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

Reply via email to