I'm not sure, it might depend on a variety of factors. I know Java ImageIO can
use disk-backed caching, but that's just for manufacturing the BufferedImage
and so I don't know if it's disk-backed-ness carries over into the
BufferedImage it produces.
I don't handle DPI -- I create a BufferedImag
I think both Java2D and JAI have API for tiles. Do you know if that has
anything to do with loading only part at a time, or what they're for?
-
Ross Mellgren wrote:
Well, it has to keep the whole source (packed) in memory and the target
(unpacked / 32 bit RGB
Does JAI need everything in RAM?
Also, how do you deal with DPI?
-
Ross Mellgren wrote:
Well, it has to keep the whole source (packed) in memory and the target
(unpacked / 32 bit RGBA) in memory, so I would assume that as long as
AffineTransformOp is not doin
Hi Ross,
That looks good. It seems you're doing a much better job of handling
gif than I would have. Maybe we should move this discussion to the
main list to get everyone's input on what features would be useful.
Tim, If you've already created a branch, let me know and I'll get my
stuff in ther
Well, it has to keep the whole source (packed) in memory and the target
(unpacked / 32 bit RGBA) in memory, so I would assume that as long as
AffineTransformOp is not doing something untoward it's probably around (src
width * src height * src bytes/pixel) + (dest width * dest height * 4 bytes)
Cool stuff Ross, whats the overhead like in terms of memory etc?
I might have a bit of time to put this into a module and stuff it on review
board.
Cheers, Tim
On 15 Jan 2010, at 15:03, Ross Mellgren wrote:
> According to Jon on the call, he said he was putting together just such a
> lift m
According to Jon on the call, he said he was putting together just such a lift
module (for image stuff), so I figured I'd toss this over in case it was of use
to him in that module.
If anyone else wants to use it independently, consider it a contribution to
lift, and licensed the same way.
-Ro
