Skip to main content

[JAI] Dumbo question about rendered vs renderable

3 replies [Last post]
Anonymous

Apologies for the dumbo question, but I've read the JAI 1_0_1 guide a
number of times, and am still struggling to understand the distinctions
between the rendered/renderable deferred execution model.

This is one part of the explanation that I'm struggling with:

"A Rendered graph processes images in immediate mode. For any node in
the
graph, the image source is considered to have been evaluated at the
moment it is
instantiated and added to the graph. Or, put another way, as a new
operation is
added to the chain, it appears to compute its results immediately."

After having fooled with chained OpImages, I know that tile computation
doesn't start until the data is required. For example, if I do
something like:

RenderedOp cannyImage = JAI.create("Canny", cannyParameterBlock);
RenderedOp storedImage = JAI.create("FileStore", storeParameterBlock);

The Canny computation (and all of the chained OpImages therein) doesn't
begin until the FileStore tries to do its stuff. To me, this seems like
execution is deferred until a sink requires the data. I thought
Rendereds didn't work that way, since this is how Renderables performed
their work. Isn't the Rendered chain working like a pull model here?

Also, I understand that Renderables are resolution independent. I've
got the impression from somewhere that Renderables are associated with a
pyramid of subsampled data so that when rendering is pulled, the
resolution-specific computation can be done quickly, because the data is
at hand. (I probably misunderstand this) If so, does that mean that
Renderables are more memory hungry than Rendered?

Thanks.

Jason.
[att1.html]

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Brian Burkhalter

On Tue, 31 May 2005, Jason Grant wrote:

> The Canny computation (and all of the chained OpImages therein) doesn't
> begin until the FileStore tries to do its stuff. To me, this seems like
> execution is deferred until a sink requires the data. I thought
> Rendereds didn't work that way, since this is how Renderables performed
> their work. Isn't the Rendered chain working like a pull model here?

When either a rendered or renderable operation is created you are in effect
just adding a node to a graph. The abstraction for the node is the
OperationNode interface of which there are rendered and renderable
implementations (RenderedOp and RenderableOp).

When a RenderedOp chain is rendered as described at

http://java.sun.com/products/java-media/jai/forDevelopers/jai-apidocs/ja...

for example by requesting the image width or requesting data, a parallel chain
of nodes is created wherein the nodes are generally OpImage instances. It is
the OpImage chain which also generates data when they are requested by
getTile() or other methods. (Recall that "immediate" operations such as
FileStore and ImageWrite are rendered when the node is created.)

In the case of creating a RenderedImage from a RenderableOp chain, the node
creates a parallel chain generally consisting of OpImage nodes, not RenderedOp
nodes.

In either case a pull model is being used: the eventual source does not
generate any data until requested to do so. This is to be contrasted with the
push model used in the ImageProducer/ImageConsumer model used in Java 1.0/1.1.

Brian

----------------
Brian Burkhalter
Advanced Development, Graphics and Media
Software Chief Technology Office
Sun Microsystems, Inc.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any
unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai.dev.java.net
For additional commands, e-mail: interest-help@jai.dev.java.net

Bob Deen

>This is one part of the explanation that I'm struggling with:
>
>"A Rendered graph processes images in immediate mode. For any node in
>the
>graph, the image source is considered to have been evaluated at the
>moment it is
>instantiated and added to the graph. Or, put another way, as a new
>operation is
>added to the chain, it appears to compute its results immediately."
>
...
>execution is deferred until a sink requires the data. I thought
>Rendereds didn't work that way, since this is how Renderables performed
>their work. Isn't the Rendered chain working like a pull model here?

It's a distinction between logical and physical. Logically speaking, the
data in the chain is set at the moment it is created, i.e. the data you
get from requesting tiles should never change for the lifetime of that
chain. Physically, the tiles are not computed until requested.

However, JAI 1.1 introduced editable rendered chains, which means the
data *can* change (at the RenderedOp level... the OpImages that do the
work still never change and are simply replaced). When the image or a
parameter changes, RenderingChangeEvents are sent down the chain to notify
everyone.

>Also, I understand that Renderables are resolution independent. I've
>got the impression from somewhere that Renderables are associated with a
>pyramid of subsampled data so that when rendering is pulled, the
>resolution-specific computation can be done quickly, because the data is
>at hand. (I probably misunderstand this) If so, does that mean that
>Renderables are more memory hungry than Rendered?

I'm not an expert on Renderable mode but I think it depends on your data
source. If the data source has multiple resolutions, it could present the
most appropriate one for the given rendering. That's actually more memory
efficient, if you don't need full resolution and the data source is smart
enough not to load it at full res.

-Bob Deen @ NASA-JPL Multimission Image Processing Lab
Bob.Deen@jpl.nasa.gov

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai.dev.java.net
For additional commands, e-mail: interest-help@jai.dev.java.net

Brian Burkhalter

On Tue, 31 May 2005, Bob Deen wrote:

> >Also, I understand that Renderables are resolution independent. I've
> >got the impression from somewhere that Renderables are associated with a
> >pyramid of subsampled data so that when rendering is pulled, the
> >resolution-specific computation can be done quickly, because the data is
> >at hand. (I probably misunderstand this) If so, does that mean that
> >Renderables are more memory hungry than Rendered?
>
> I'm not an expert on Renderable mode but I think it depends on your data
> source. If the data source has multiple resolutions, it could present the
> most appropriate one for the given rendering. That's actually more memory
> efficient, if you don't need full resolution and the data source is smart
> enough not to load it at full res.

That's correct. When a renderable is used to create a RenderedImage the most
appropriate pixel dimensions available will be used. This will be most
efficient if a multi-resolution data source is available at the source node of
the operation chain, e.g., in the form of a multi-page TIFF file containing an
image pyramid. The scale is back propagated through the chain and the most
appropriate resolution level will be extracted from the file. The attendant
memory savings will then be propagated forward.

Brian

----------------
Brian Burkhalter
Advanced Development, Graphics and Media
Software Chief Technology Office
Sun Microsystems, Inc.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any
unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai.dev.java.net
For additional commands, e-mail: interest-help@jai.dev.java.net