A few comments inline, but first up thanks for engaging the community and
attending last nights meeting.

1) For proof of concept / demo purposes, identify a compute intensive (i.e.
slow) image processing chain / sequence of

> operations frequently required by GeoServer users.  So far, Jody, Andrea,
> and Jukka have mentioned crop, affine, warp,
> transform (pls clarify -- coordinates?  or transform like FFT or DCT?),
> resize (resample), rendering maps from vector
> data...
>

Their are two transforms:
-  co-ordinate transform between two coordinate reference systems (for
example a global 4326 dataset being projected to an albers equal area
projection)
- affine transform used to position the final image, or perform a rotation
etc..

2) The demo should be something that:
>
>   -everyone knows what to expect; i.e. not
>    difficult to tell it has been done right
>

The above sequence is based on the common processing chain used for map
generation. It is the only one that qualifies as frequently required by
GeoServer users.

  -any speed improvement would have a major
>    impact on GeoServer users, especially
>    those with limited server resources
>    or those using cloud servers
>
>   -if the operation(s) requires video encode
>    or decode (e.g. H.264 or H.265), for
>    example due to cloud based operation,
>    that's fine (our accelerated version
>    of OpenCV handles that)
>
>   -if the operation(s) requires network I/O,
>    that's also fine (for same reason)
>

>From last night call it sounded like your users may want more of an image
processing (i.e. data product) generation.

An easy one that would be of benefit to the community is the production of
hillshade <https://en.wikipedia.org/wiki/Terrain_cartography#Shaded_relief>
visualization
from a digital elevation model. The calculation is online
<http://pangea.stanford.edu/~samuelj/musings/dems-in-python-pt-3-slope-and-hillshades-.html>:
from raw dem to the production of slope and gradient  and then generate the
final colours.

If that is not enough of a challenge (only one fork) you could try
production of hypsometric hillside (so the colors used for the calculation
change depending on elevation and environment factors). Natural Earth
<http://www.naturalearthdata.com/features/> has a good example.


> 3) I assume that given the above input, my team can identify which JAI
> APIs are used.  We would then implement an interface layer between
> GeoServer and JAI that translates those APIs into equivalent or combination
> of OpenCV APIs.
>

I hope last nights meeting identified the approach to use (add additional
operators to the JAI-Ext project) acting as a "native" implementation that
can be selected if the appropriate libraries are in place.

I *really* like this approach, it is nice and clean and gives us a strong
performance boost for those in position to install.

The trick here though is that JAI-Ext is a seperate project (many of the
same players are here, just wanted to point out you would be working in a
different codebase).
------------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Reply via email to