>>>>> "FI" == Felicia Ionascu <[EMAIL PROTECTED]> writes:
FI> Hi Thomas, Thomas E Deweese wrote:
>> >>>>> "FI" == Felicia Ionascu <[EMAIL PROTECTED]> writes:
>>
FI> I had a very unpleasant surprise when monitoring the memory
FI> consumption for a simple call on a TIFFTranscoder.transcode(..).
FI> The image is 992 x 1403 pixels and I was expecting at max
FI> allocated 5MB of RAM. What I got was about three times more: about
FI> 18MB!
>>
FI> I searched in the sources, there are images created everywhere, in
FI> StaticRenderer, in ImageTranscoder...
>> Please remember, contributions are always welcome. Everyone has a
>> different itch to scratch.
FI> I think what's missing at this moment is a transcoder that returns
FI> a BufferedImage - an image in a "pure" format.
This 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.
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> What's also missing is being able to do all this with a
FI> black-and-white or other image type. Now, if you use the
FI> TIFFTranscoder, it creates an ARGB image, four times larger than a
FI> graylevel one.
Well the basic problem is that SVG more or less requires the image
to be processed in the sRGB colorspace. What are you going to do
about the 'opacity' property? or with a feColorMatrix filter?
Gradients? The list is quite long.
If you are just interested in something 'SVG like' then you might
be able to get away with this but you certainly won't be very
conforming to the SVG specification. It might be that for the content
you render this would be sufficient but as SVG is a standard you need
to address the rest of the SVG content model in some way.
I'm happy to discuss this issue but it needs to be thought through
more than I think you have so far.
You 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> Not to mention what happens if we want to create a multipage TIFF
FI> afterwards, as all the pages are kept in memory before being
FI> written out.
>> If you are doing multi-page TIFF then what is kept in memory or
>> not as pages are written is really your issue not Batik's. You
>> don't have to generate full page buffers for each page ahead of
>> time, you can generate them on demand.
FI> That's what I finally did, transcoding only parts (bands) of the
FI> original SVG, then recomposing them to a final big image... But
FI> this final image still eats a lot of memory.
FI> There is no way of doing all this on the disk? It's very
FI> embarrasing if the amount of RAM is limited, and I don't think
FI> it's just the case of my application.
>> I don't think you want to do it on the disk, you just want to do
>> it in a demand pull fashion. The rendering engine of Batik
>> supports this fully, it's just the current implementation of
>> transcoders that expect to work with full page buffers.
>>
>> I know this as I have generated 10kx20k Tiff images in the default
>> java partition, of course it takes writing some code, I haven't had
>> the time to generalize this and integrate it with the existing
>> transcoders but perhaps you would like to pick it up, polish it off
>> and contribute the result?
FI> I think it would be very interesting to have this in Batik and I'd
FI> like to give it a try. So please let me know how can I pick it
FI> up.
I'll commit it in the 'contrib' area, when my CVS issues are
resolved.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
