I finally solved the memory consumption issue. I found a workaround to the black background: a white rectangle as big as the image in the original SVG.
Then taking out the alpha (transform the ARGB renderedImage to BGR) is simple - no need to work on pixels:
BufferedImage buf = new BufferedImage(1,1,BufferedImage.TYPE_3BYTE_BGR);
RenderedImage fr = new FormatRed (GraphicsUtil.wrap(renderedImage), buf.getColorModel());
Now I can make it run in 2MB for a 1240x1754 image.
Thank you a lot for the help.
Felicia
Felicia Ionascu wrote:
Hi Thomas,
Thanks a lot for the TiledImageTranscoder. I think it would be very necessary to have it in batik, as it saves enormous resources.
I have just one more thing to solve: the background of the final TIFF is black. I saw that in TIFFTranscoder.writeImage a transformation on pixels is performed to transform the background.
I tried to do the same for my RenderedImage before encoding it with TIFFImageEncoder.
In the API, it says that getTile() method returns a raster which gives direct access to pixels in the RenderedImage. But the implementation in AbstractRed works with copies of the data! I seems that changing pixels in a raster obtained with getTile doesn't affect original RenderedImage data.
The only workaround I see is using a BufferedImage, but it's a pity that I increase the allocated memory again just for getting rid of the black background...
And after all, why GraphicsNodeRed8Bit.genRect() creates a black-background image?
Regards,
Felicia
Thomas E Deweese wrote:
"FI" == Felicia Ionascu <[EMAIL PROTECTED]> writes:FI> Thomas E Deweese wrote: [deleted stuff...]FI> I modified a transcoder to return directly a BufferedImage. IThis is exactly what the StaticRenderer does. The transcoders really shouldn't use the StaticRenderer (they should work at a lower level) but I didn't write them and the StaticRenderer is such a simple way to get a BufferedImage it was easier.
FI> observed though that memory allocated somewhere in StaticRenderer
FI> (I think) is not freed. Looks like dispose() doesn't work...
Well most of it should be freed when the StaticRenderer is GC'd.
I think the 'dispose' method should clean up most references (it may
be in another method). I also remembered that the StaticRenderer caches the results in a Tile Cache so interactive panning can be
faster. But as I said transcoders shouldn't be using StaticRenderer
the class is really intended for interactive use (hence the caching
and double buffering capabilities).
That all said, for large images the last thing you want is to create a BufferedImage. This requires the entire image to be in memory at one time. You want to work with RenderedImages which are tiled and demand pull, so only the parts currently being worked on are in memory.FI> How can I avoid this? With StaticRenderer.getOffScreen(), the FI> image I obtain is BufferedImage. Take a look at the TiledImageTranscoder I committed. It uses RenderedImages to avoid allocating full page buffers. FI> And in the meantime, inside StaticRenderer allocations are done FI> which are not garbage-collected...FI> Could you please be more precise about where to look? I can't findYou might try passing a Graphics2D from a grayscale image into the paint method of the GVT tree. This might work, of course for complex content it will fail - but I don't know how widespread the failures would be.
FI> any GVTTree class.
The GVT (Graphics Vector Toolkit) is all the classes in the
batik.gvt package. The basic class is GraphicsNode which makes up our
rendering tree (the GVT tree), essentially all the graphics elements
in an SVG file get converted to GraphicsNodes in the GVT tree. For examples of using the GVT tree directly take a look at
batik.gvt.filter.GraphicsNodeRed8Bit in it's genRect method is
constructs a BufferedImage from a WritableRaster get's a graphics2D
from it and sets it up to call paint on it's associated GraphicsNode.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-- ------------------------------------------------------------ Felicia IONASCU Oc� Print Logic Technologies mailto:[EMAIL PROTECTED] 1, rue Jean Lemoine phone : +33 (0)1 48 98 81 99 94015 Cr�teil cedex, France fax: +33 (0)1 48 98 54 50 http://www.oce.com/ ------------------------------------------------------------ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
