Skip to main content

AreaOpImage and BorderExtender

9 replies [Last post]
dominikbrunner
Offline
Joined: 2007-03-28

Hi JAI community,

I am writing a SAR speckle filter based on moving windows using an AreaOpImage. In order to calculate the destination pixels, a rectangular source region around a source pixel is needed. For the calculation of the pixels at the borders of the image, an extension of the source image is required. I therefore initialize the AreaOpImage with a BorderExtender:

public XXXFilterOpImage(RenderedImage source, int width, int height, ImageLayout layout, RenderingHints hints) {
super(source, layout, hints, false, BorderExtender.createInstance(BorderExtender.BORDER_ZERO), width / 2, width / 2, height / 2, height / 2);
}

where "width" and "height" are the dimensions of the moving window.

The problem arises now in the implementation of the method:
protected void computeRect(PlanarImage[] srcs, WritableRaster wr, Rectangle rect) {}.

The source image ("srcs") is not extended as expected automatically by half of the size of the moving window. This behavior is quite strange since it seems that it makes the AreaOpImage not very useful for those applications. I got around this problem by extending the source image separately. But this is of course not the preferred way.

Does anybody has some experience with the AreaOpImage and knows how to get the image extended automatically?

Thanks for your help

Dominik

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
dominikbrunner
Offline
Joined: 2007-03-28

Hi,

I made some progress. By reading carefully the API I found out that only by using the method

protected void computeRect(Raster[] sources, WritableRaster dest, Rectangle destRect)

from class OpImage, which is called when cobbled sources are used, it is guaranteed that the image is extended with a border.

The Javadoc of method

protected void computeRect(PlanarImage[] sources, WritableRaster dest, Rectangle destRect)

does not mention this feature.

For me, the concept of cobbled and non cobbled sources is not very clear. Could anybody explain this in this context?

Having fixed the BorderExtension problem, I am running now in performance issues since the method computeRect is called quite often with only small tiles. Furthermore, it seems that the same tile is called for computation several times, again and again.

Thanks for any suggestions

cu

Dominik

Brian Burkhalter

On Sun, 15 Apr 2007, jai-interest@javadesktop.org wrote:

> Hi,
>
> I made some progress. By reading carefully the API I found out that only by using the method
>
> protected void computeRect(Raster[] sources, WritableRaster dest, Rectangle destRect)
>
> from class OpImage, which is called when cobbled sources are used, it is guaranteed that the image is extended with a border.
>
> The Javadoc of method
>
> protected void computeRect(PlanarImage[] sources, WritableRaster dest, Rectangle destRect)
>
> does not mention this feature.
>
> For me, the concept of cobbled and non cobbled sources is not very clear. Could anybody explain this in this context?

"Cobbled" means that if a given rectangular area of a source is requested then
all tiles overlapping that area are "cobbled" together into a contiguous
Raster.

> Having fixed the BorderExtension problem, I am running now in performance issues since the method computeRect is called quite often with only small tiles. Furthermore, it seems that the same tile is called for computation several times, again and again.

The optimum tile size is something that your application needs to tune for its
use case(s). From what I have seen 64x64 is the smallest useful size and
256x256 is often optimal. Naturally you may use aritrary tile dimensions not
just powers of two. Another consideration is the size of tiles in your source.
If the source is tiled going to larger tiles in the destination is probably OK
but going to smaller ones might cause multiple re-requests of the source tile
if it gets flushed between requests for different destination tiles that if
affects.

You also will need to tune your TileCache settings.

> Thanks for any suggestions
>
> cu
>
> Dominik
> [Message sent by forum member 'dominikbrunner' (dominikbrunner)]
>
> http://forums.java.net/jive/thread.jspa?messageID=212458
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai.dev.java.net
> For additional commands, e-mail: interest-help@jai.dev.java.net
>
>

----------------
Brian Burkhalter
Java Media, Imaging, and Graphics
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

dominikbrunner
Offline
Joined: 2007-03-28

Thanks Brian. "Cobbled" is more clear now.

I should have been more precise. I read in one single banded untiled source image with ImageRead using a FileImageInputSTream and RawImageInputStream (with ComponentSampleModel and ColorModel). If JAI does not do some internal tiling there should be only one big tile. When I apply now the self written moving window filter (using AreaOpImage) on the whole image, I get the large number of requests for tiles.

I reimplemented the filter using an UntiledOpImage and the filter ends within 1 minute (on a 30mb image). If I use the AreaOpImage version, it runs for hours! However, I wanted to make use of the automated BorderExtension provided by

protected void computeRect(Raster[] sources, WritableRaster dest, Rectangle destRect)

since this is for me the real advantage of AreaOpImage - or did I misunderstand the conecpt of AreaOpImage?

cu
Dominik

bpb
Offline
Joined: 2004-06-23

I think I know what is going on: probably JAI is setting default tiles. Try calling this method

http://download.java.net/media/jai/javadoc/1.1.3/jai-apidocs/javax/media/jai/JAI.html#setDefaultTileSize(java.awt.Dimension)

with an argument of 'null' and see whether that resolves the problem.

> Thanks Brian. "Cobbled" is more clear now.
>
> I should have been more precise. I read in one single
> banded untiled source image with ImageRead using a
> FileImageInputSTream and RawImageInputStream (with
> ComponentSampleModel and ColorModel). If JAI does not
> do some internal tiling there should be only one big
> tile. When I apply now the self written moving window
> filter (using AreaOpImage) on the whole image, I get
> the large number of requests for tiles.
>
> I reimplemented the filter using an UntiledOpImage
> and the filter ends within 1 minute (on a 30mb
> image). If I use the AreaOpImage version, it runs for
> hours! However, I wanted to make use of the automated
> BorderExtension provided by
>
> protected void computeRect(Raster[] sources,
> WritableRaster dest, Rectangle destRect)
>
> since this is for me the real advantage of
> AreaOpImage - or did I misunderstand the conecpt of
> AreaOpImage?
>
> cu
> Dominik

dominikbrunner
Offline
Joined: 2007-03-28

Thanks. That's it. By switching of the default tiling, the method computeRect is only called 9 times (since it seems that the border region [8 calls] is processed independently to the rest [1 call] of the image).

There remains just one question: Why does the computeRect(PlanarImage[] sources, WritableRaster dest, Rectangle destRect) method for non cobbled sources does not support the automatic extension of the border region? Is this bug or feature?

Dominik

Brian Burkhalter

On Tue, 24 Apr 2007, jai-interest@javadesktop.org wrote:

> Thanks. That's it. By switching of the default tiling, the method computeRect is only called 9 times (since it seems that the border region [8 calls] is processed independently to the rest [1 call] of the image).

Great.

> There remains just one question: Why does the computeRect(PlanarImage[] sources, WritableRaster dest, Rectangle destRect) method for non cobbled sources does not support the automatic extension of the border region? Is this bug or feature?

Well I guess it could be either. What I think would have to happen would be
for the caller of computeRect() to wrap the source PlanarImage in a Border
operation in this case.

If this is of interest we would appreciate it if you were to file an
ENHANCEMENT issue in the jai-core.dev.java.net project.

Thanks,

Brian

----------------
Brian Burkhalter
Java Media, Imaging, and Graphics
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

dominikbrunner
Offline
Joined: 2007-03-28

Ok, I created an enhancement issue.
Issue 93;
https://jai-core.dev.java.net/issues/show_bug.cgi?id=93

Thanks for your help

Dominik

Brian Burkhalter

Thanks. Now all that is missing is the fix. ;-)

Brian

On Fri, 27 Apr 2007, jai-interest@javadesktop.org wrote:

> Ok, I created an enhancement issue.
> Issue 93;
> https://jai-core.dev.java.net/issues/show_bug.cgi?id=93
>
> Thanks for your help
>
> Dominik
> [Message sent by forum member 'dominikbrunner' (dominikbrunner)]
>
> http://forums.java.net/jive/thread.jspa?messageID=214690
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai.dev.java.net
> For additional commands, e-mail: interest-help@jai.dev.java.net
>
>

----------------
Brian Burkhalter
Java Media, Imaging, and Graphics
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

Fork Labs

Hello Dominik,

My first guess would be to look at the source code of the boxfilter operation.

Regards,

Daniel Léonard

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