I guess, the size of Print Jobs is independent from the scale factor in
>> g2d.scale(200, 200);
but depends only on the size of the BufferedImage in
>> g2d.drawImage(bi, null, null);
Hence, for downscaling, method b) will create the smaller print jobs.
I solved the problem of handling large (source) images and/or high resolution prints on large paper formats by breaking the image in several chunks, loading, (up or down) scaling and drawing them separately - reusing the BufferedImage used as destination of the affine Transformation. So I am able to print 6000x6000 images on A3(297mmx420mm) with a printer resolution of 600x600dpi, without the need to increase the default max heap size (-Xmx) of 64MB.
Are you talking about tiling? I was thinking about that, but don't really care about the program memory size at this point. My main concern was that for a small printer, it cannot buffer a 80 MB image, nor should it have to. At 300 dpi, 8.5 x 11 inches, which is only about a 1 MB of image storage necessary. For larger printers I'm assuming they will have much larger memory buffers and/or flow control. The point is I have to make my code flexible to handle any size printer and emit only as much print data as required per the scale of the image.
I guess I'm still hung up on the issue of why method's (a) and (b) both produced 80 MB print files while a second buffered image only produces a 90 KB print file.
It's a little tricky to assemble the chunks by g2.drawImage without creating artifacts, but it's not so hard in the case of bilinear interpolation. It may become harder for bicubic interpolation - but according my knowledge, bicubic is currently not yet supported by Java2D (may be by JAI).
Yep, Graphics2D.setRenderingHints(RenderingHints.KEY_INTERPOLATION, RenderingHints.VALUE_INTERPOLATION_BICUBIC) is supported. After reading the Java 2D API Graphics book again I suspect bicubic gives better results, but the book just doesn't come right out and say so.
I can see that tiling would be hard to handle when interpolation is involved, but I thought you had to use JAI to handle tiling?
Cheers, Eric
gunter
Eric Kolotyluk wrote:
Hmm, I'm using an old Canon LBP-430 printer. Maybe there's a difference in the printer drivers. Eventually I'll be using brand new large format Epson and HP printers for my product.
On the other hand, you're scaling larger, while I'm scaling a very large image (4865 x 5972) to letter size paper with a 1 inch margin (468 x 468) for a scale factor of 0.108. I'm not using rending hints as I'm scaling down. If it's not too much trouble, could you try scaling down with your printer and see if the a/b results are the same?
You have proved that (a) and (b) are very different in scaling up. Good work! I'm not sure if it works going the other way.
Normally I would have thought the Java printing support and/or the printing drivers would have scaled the output size accordingly too. Since the scale is 10% smaller, and it the area we're talking about, the output size should be 100 times smaller. For an 80 MB image, that should be 800 KB. If I do the following
| BufferedImage original = ImageIO.read(file.png); BufferedImage printable = new BufferedImage( (int)(scale * original.getWidth(), (int)(scale * original.getHeight(), BufferedImage.TYPE_3BYTE_BGR);
AffineTransform transform = new AffineTransform(); transform.scale(scale, scale);
Graphics2D g = original.createGraphics(); g.drawImage(original, transform, null);|
then print printable, the output file is only 900 KB, or about what I would expect. Unfortunately, the image fidelity is off because the original BufferedImage is loaded from a PNG file and is TYPE_CUSTOM with a "ColorModel: #pixelBits = 24 numComponents = 3 color space = [EMAIL PROTECTED] transparency = 1 has alpha = false isAlphaPre = false" As far as I know there is no way to clone a BufferedImage with different dimensions, but the same type and colour model. I tried creating BufferedImage of TYPE_CUSTOM, but the Java runtime complained. As an aside, the first time I tried this I used TYPE_INT_BGR, and the printed image came out very light and dithered. TYPE_3BYTE_BGR is suppose to be sRGB (I think).
More importantly, why do I need to create a second BufferedImage, why can't Graphics2D and/or the printer driver do the right thing to begin with? The mysteries of Java printing...
Thanks for providing me with the details of your experiment. When I have to scale up I'll know which method to use.
By the way, when would someone choose Bicubic interpolation?
Cheers, Eric
Gunter Zeilinger wrote:
Just tested under Java 1.4.1_01/Linux 2.4.18-686 -> cups 1.1.14 -> hp psc 750 with 300x300dpi:
a)
public int print(Graphics g, PageFormat pf, int pageIndex) { if (pageIndex == 0) { BufferedImage bi = new BufferedImage(2, 2, BufferedImage.TYPE_INT_RGB); bi.setRGB(0, 0, 0x000000); bi.setRGB(0, 1, 0xffffff); bi.setRGB(1, 0, 0xffffff); bi.setRGB(1, 1, 0x000000);
Graphics2D g2d = (Graphics2D) g; g2d.translate(pf.getImageableX(), pf.getImageableY()); g2d.scale(200, 200); g2d.setRenderingHint(RenderingHints.KEY_INTERPOLATION, RenderingHints.VALUE_INTERPOLATION_BILINEAR); g2d.drawImage(bi, null, null); return Printable.PAGE_EXISTS; } else { return Printable.NO_SUCH_PAGE; }
=> PrintJob size: 3k RenderingHints.VALUE_INTERPOLATION_BILINEAR ignored!
b) public int print(Graphics g, PageFormat pf, int pageIndex) { if (pageIndex == 0) { BufferedImage bi = new BufferedImage(2, 2, BufferedImage.TYPE_INT_RGB); bi.setRGB(0, 0, 0x000000); bi.setRGB(0, 1, 0xffffff); bi.setRGB(1, 0, 0xffffff); bi.setRGB(1, 1, 0x000000);
Graphics2D g2d = (Graphics2D) g; g2d.translate(pf.getImageableX(), pf.getImageableY()); AffineTransform af = g2d.getTransform(); g2d.scale(1. / af.getScaleX(), 1. / af.getScaleY()); af.scale(200, 200); AffineTransformOp op = new AffineTransformOp(af, AffineTransformOp.TYPE_BILINEAR);
BufferedImage dest = op.filter(bi, null); g2d.drawImage(dest, null, null); return Printable.PAGE_EXISTS; } else { return Printable.NO_SUCH_PAGE; }
=> PrintJob size: 426k bilinear Interpolation!
===========================================================================
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".
