From: walker@owl.asd.sgi.com (Christopher Walker)
Newsgroups: comp.sys.sgi
Subject: Re: IL: ilmemoryimg coord space reset -> 'img1 << img2' => 'img1 != img2'
Date: 15 Oct 1992 20:29:27 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA
NNTP-Posting-Host: owl.asd.sgi.com


In article <1992Oct15.000012.7442@news.arc.nasa.gov>, kevin@neuron.arc.nasa.gov writes:
> In article <1bhicaINNhbt@fido.asd.sgi.com>, walker@owl.asd.sgi.com (Christopher Walker) writes:
> |> ilMemoryImg doesn't have an input it has to assume some default.  I've thought
> |> about adding a constructor for ilMemoryImg that would take an ilImage* as a 
> |> parameter and automatically inherit that image's attributes and (optionally)
> |> copy the data from that image.  This would avoid most of this confusion and
> |> be easier to use.. what do you think?
> 
> I was surprised the first time I read about ilMemoryImg that it didn't 
> work like the other operators (take in an object and inherit).  How about 
> overloading the constructor as "ilMemoryImg(ilImage *img)" so that you
> could have it inherit attributes and do a copyTile as well?  It's nice for
> quick prototyping of IP algorithms to just have everything in memory and 
> deal with a small image until things work, then throw in the tiling stuff...

I think that's what I just said :-) (we are planning to support this in 2.0)

> 
> Also, under the current way of handling ilMemoryImg (setup->copyTile->
> getDataPtr), you end up having to call copyTile and process the entire
> backward chain for all tiles.  What might also be nice is to overload 
> the '[]' operator for MemoryImg objects instead of using copyTile->getDataPtr,
> then only process pages as they're accessed  (you'd have to malloc all
> at the beginning, but you'd save the processing time for doing all the
> pages).  That way, if I have a long chain and only access a little of 
> the image, only what I'm accessing has been processed.  Cute idea, maybe 
> a little less performant (added test per ref).

If you have an operator chain, and issue a getPixel or getTile on the end of 
the chain it will only compute the page that contains that pixel or tile.. why 
duplicate the functionality in ilMemoryImg?

> On a side note, what is the suggested way for handling global image operations?
> I'm just finishing up writing a blob-coloring algorithm, but it requires me
> to process the whole image to find what blobs may be connected to what blobs
> elsewhere in the image.  A similar example is ilHistEqImg, where you have to
> do a histogram before you can process any data.  I think the nice IL demand-
> driven model starts to break down on global operations and the ilMemoryImg
> is a nice way to hack out of it, but I don't really see any other way around
> it.  

Well, I don't know if I would use the term "breaks down" :-).

Another way around this problem is to force the page size on the operator that
needs to access the whole image to be the size of the image (i.e. a one page
image).. that's what we do for the 2D-FFT code (which has the same problem).

For ilHistEqImg the demand model works OK (actually ilImgStat is where the
histogram happens), but you would either want an ilRoi to restrict the stats
to the area being viewed (for a large image) or set the cache size on the
input to the HistEq large enough to hold the entire image (to avoid re-reading
data).