[gdal-dev] RE: progressive rendering

[Norman Barker]

Tamas, Frank, all

I have created RFC 24 on 

http://trac.osgeo.org/gdal/wiki/rfc24_progressive_data_support

for comment; hopefully the likes of mpg, simboss and others will chip in
as well.  

Currently we are just defining an interface - but I am certainly
interested in coding the driver (and probably will) as well.

If JPIP means nothing to you then check out http://iasdemo.ittvis.com
and in the interest of fairness have a look at Lizardtech, Erdas and
Kakadu as well!

Thanks,

Norman

-----Original Message-----
From: Frank Warmerdam [mailto:warmerdam at pobox.com] 
Sent: Tuesday, August 19, 2008 3:45 PM
To: Norman Barker
Cc: gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] RE: progressive rendering

Norman Barker wrote:
> Mainly it is either end of response, image done, or window done to
> indicate that there is a buffer update and the display should be
> updated, anything else can pretty much be ignored.  
> 
> Ideally the callback should indicate the region that has changed,
since
> the server is entitled to change the region it streams if the client
has
> requested an invalid ROI.

Norman,

If we load this capability onto RasterIO() call I don't imagine we
would want to allow the client to change the area being loaded. If
an invalid ROI is requested the driver should either error out, or
only update the valid part of the buffer.

> The callback isn't per scan line, but a whole window (at a particular
> resolution level).
> </ncb>

Ah, gotcha.  I hadn't even considered this aspect!

> The simpliest case I can imagine would be passing (or installing) a
> callback that drivers *could* call periodically to indicate that some
> unspecified area of the RasterIO() buffer has been updated.
> 
> <ncb>
> The callback would need to include the x,y offsets, width, height and
> resx, resy since otherwise there needs to be too much state
> synchronization between the format driver and the client.  The
simplest
> would be to specify x,y, width, height at the base resolution of the
> image and to use resx, resy to sample for the display implying the
> buffer size.  The format driver would keep the cache.
> </ncb>

OK, now you have lost me.  The RasterIO() call includes a buffer,
and defines the size of that buffer (in x and y) and the size of
file window to load into that buffer.  I don't get what you mean
about there being too much state synchronization between the driver
and the client.

> Is the main objective to be able to update stuff on the screen while a
> buffer is being downloaded by JPIP or other slow access mechanisms?
> 
> <ncb>
> Definitely, this is the main objective.  A secondary objective is to
use
> the mechanism to download complete sections of a streaming image (so
to
> stream until a window done message) for use with gdal_translate for
> example.
> </ncb>

I don't follow the secondary objective.   How does having the callback
add value to just reading the data into the buffer in chunks and
then writing it to the output file?

Perhaps it would make sense to mock up a proposed RasterIO() variation
with the callback in RFC form so we can more easily talk about the same
thing?  This can be done in the trac wiki.

Best regards,
-- 
---------------------------------------+--------------------------------
------
I set the clouds in motion - turn up   | Frank Warmerdam,
warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent