Loading image data from my own InputStream

["Maass, Adam (Snapfish)" <ad...@hp.com>]

OK, so this is something of an odd request:


I have an application in which I want to, at runtime, dynamically replace an embedded image:

<image xlink:href="data:image/jpeg;base64,/9j/4AAQSkZJ....

I have a solution that works but is sub-optimal: I read the image I want to substitute, determine a content type for it, base-64 encode its data, and replace the xlink:href attribute of the image element.


What this means is that I have at least two (usually three!) representations of the image data in-memory - even before a subsequent transcode operation! (That is, one in a ByteArrayOutputStream to accumulate the data, one in the byte[] that ByteArrayOutputStream returns, and a third in the base-64 encoded version of that byte[].) The subsequent transcode operation will necessarily base-64 decode the data I just encoded, create a bitmap out of it, and presumably blit the bits into the resulting JPG.

This is far too many large data structures floating around! To reduce the count of large data structures, I really want to specify in the href element that the image data should come from some InputStream I have at hand. Then when Batik processes the image element, it reads the InputStream directly, and creates only the one or two copies of the image data it really truly needs. Is there a way to do this? If not, can someone point me in the right direction if I were to take this on on my own?


-Adam Maass

RE: Loading image data from my own InputStream

["Maass, Adam (Snapfish)" <ad...@hp.com>]

Thank you. Yes, this looks like it is going to work.

-Adam


From: jonathan wood [mailto:jonathanshawwood@gmail.com]
Sent: Friday, October 01, 2010 7:59 PM
To: batik-users@xmlgraphics.apache.org
Subject: Re: Loading image data from my own InputStream

Perhaps a custom URL Protocol?

http://xmlgraphics.apache.org/batik/using/extending.html#urlProtocols


On Fri, Oct 1, 2010 at 8:59 PM, Maass, Adam (Snapfish) <ad...@hp.com>> wrote:
OK, so this is something of an odd request:


I have an application in which I want to, at runtime, dynamically replace an embedded image:

<image xlink:href="data:image/jpeg;base64,/9j/4AAQSkZJ....

I have a solution that works but is sub-optimal: I read the image I want to substitute, determine a content type for it, base-64 encode its data, and replace the xlink:href attribute of the image element.


What this means is that I have at least two (usually three!) representations of the image data in-memory - even before a subsequent transcode operation! (That is, one in a ByteArrayOutputStream to accumulate the data, one in the byte[] that ByteArrayOutputStream returns, and a third in the base-64 encoded version of that byte[].) The subsequent transcode operation will necessarily base-64 decode the data I just encoded, create a bitmap out of it, and presumably blit the bits into the resulting JPG.

This is far too many large data structures floating around! To reduce the count of large data structures, I really want to specify in the href element that the image data should come from some InputStream I have at hand. Then when Batik processes the image element, it reads the InputStream directly, and creates only the one or two copies of the image data it really truly needs. Is there a way to do this? If not, can someone point me in the right direction if I were to take this on on my own?


-Adam Maass

Re: Loading image data from my own InputStream

[jonathan wood <jo...@gmail.com>]

Perhaps a custom URL Protocol?

http://xmlgraphics.apache.org/batik/using/extending.html#urlProtocols



On Fri, Oct 1, 2010 at 8:59 PM, Maass, Adam (Snapfish) <ad...@hp.com>wrote:

>  OK, so this is something of an odd request:
>
>
>
>
>
> I have an application in which I want to, at runtime, dynamically replace
> an embedded image:
>
>
>
> <image xlink:href="data:image/jpeg;base64,/9j/4AAQSkZJ….
>
>
>
> I have a solution that works but is sub-optimal: I read the image I want to
> substitute, determine a content type for it, base-64 encode its data, and
> replace the xlink:href attribute of the image element.
>
>
>
>
>
> What this means is that I have at least two (usually three!)
> representations of the image data in-memory – even before a subsequent
> transcode operation! (That is, one in a ByteArrayOutputStream to accumulate
> the data, one in the byte[] that ByteArrayOutputStream returns, and a third
> in the base-64 encoded version of that byte[].) The subsequent transcode
> operation will necessarily base-64 decode the data I just encoded, create a
> bitmap out of it, and presumably blit the bits into the resulting JPG.
>
>
>
> This is far too many large data structures floating around! To reduce the
> count of large data structures, I really want to specify in the href element
> that the image data should come from some InputStream I have at hand. Then
> when Batik processes the image element, it reads the InputStream directly,
> and creates only the one or two copies of the image data it really truly
> needs. Is there a way to do this? If not, can someone point me in the right
> direction if I were to take this on on my own?
>
>
>
>
>
> -Adam Maass
>
>
>
>
>