mbedward / jiffle Goto Github PK

Adopt the same repo structure as for JAITools with a stable working branch rather than a releases archive branch.

See JAITools issue 222 for more details.

Original author: [email protected] (April 03, 2011 01:40:47)

Until now, Jiffle has used the bounds of the first destination image to define the processing area. Defining the processing area separately from image areas instead will make it possible to deal with multiple destination images with differing bounds, and to allow scripts to be written in terms of non-image coordinates such as geographic or proportional.

Source and destination image areas will relate to the processing area via AffineTransforms, with the identity transform being the default.

This issue supersedes issue 1.

Original issue: http://code.google.com/p/jiffle/issues/detail?id=17

Original author: [email protected] (April 04, 2011 08:52:07)

As per discussion with Andrea on IRC, have a single submit method for JiffleExecutor which takes a runtime object and a progress listener. It is up to the client to set the source and destination images, plus transforms if required, prior to submitting the runtime object. This makes the API simpler and less error-prone.

As a map of images is no longer being passed to the executor, add a getImages method to the runtime class to allow JiffleExecutorTaskResult to retrieve the images as before.

Original issue: http://code.google.com/p/jiffle/issues/detail?id=18

Original author: [email protected] (April 07, 2011 01:23:43)

This is related to the seq function and is another idea lifted from the R language.

rep(42, 3) gives 42, 42, 42

rep(1:3, 3) or rep(1:3, times=3) gives 1,2,3,1,2,3,1,2,3

rep(1:3, each=3) gives 1,1,1,2,2,2,3,3,3

Note that the R syntax uses named arguments. Not sure whether this should be introduced into Jiffle. There isn't much call for it with the existing functions but it does make for concise and readable code.

Original issue: http://code.google.com/p/jiffle/issues/detail?id=22

Original author: [email protected] (March 24, 2011 04:08:56)

Presently, Jiffle requires a Map<String, Jiffle.ImageRole> (the image parameters map) to tell the compiler which variable names to treat as source or destination images. This is a pain for the user, especially when we force them to provide a second map of types <String, RenderedImage> if working with a JiffleRuntime object directly.

Two options to remove the need for the image parameters map are:

1. Have the compiler infer source and destination image variables from the script. This is actually what Jiffle used to do in its early days, following the approach taken by r.mapcalc.
2. Require source and destination image variables to be declared in the script itself.

My feeling is that option 2 is preferable because it essentially documents the variables for anyone reading the script and is less likely to break as Jiffle develops. Although option 1 could be re-implemented at the moment, I'm wary of forcing yet another change on users later on if the language develops in such a way that unambiguous inference because too hard for the compiler.

No idea what syntax would be best. On the mailing list I posted this suggestion:

init {
SrcImage src;
DestImage dest;
foo = 42; // un-typed var is treated as an image-scope scalar
}

dest = src + foo;

But I don't like it much :)

Original issue: http://code.google.com/p/jiffle/issues/detail?id=4

Original author: [email protected] (March 29, 2011 10:54:31)

This is issue 142 in jai-tools.

Moving the image operator here so that jai-tools build no longer depends on Jiffle.

Original issue: http://code.google.com/p/jiffle/issues/detail?id=10

Original author: [email protected] (March 31, 2011 04:48:45)

DoubleComparison has been deprecated in JAI-tools 1.1.x and removed from trunk (JAI-tools 145).

Original issue: http://code.google.com/p/jiffle/issues/detail?id=11

Original author: [email protected] (June 17, 2011 07:09:42)

The next release of JAITools will be 1.2.0. Jiffle trunk sources don't require any features that will not be in that release.

Original issue: http://code.google.com/p/jiffle/issues/detail?id=27

Original author: [email protected] (March 23, 2011 11:04:41)

(Was jai-tools issue 76)

Add new grammar, interface and abstract base class to generate runtime class source and objects for use in an OpImage.

The main difference is that instead of writing results of script evaluation to images directly, we return results to the controlling class.

Comment by project member michael.bedward, Jan 24, 2011
Interfaces now:
JiffleRuntime: presently just a marker interface
- JiffleDirectRuntime: provides void evaluate(x, y) and evaluateAll)
- JiffleIndirectRuntime: provides double evaluate(x, y)

Base classes now:
AbstractDirectRuntime
AbstractIndirectRuntime

Added EvaluationModel enum to Jiffle class with constants: DIRECT, INDIRECT

Removed all caching of source code and runtime info from Jiffle class for the moment.

Jiffle now has the following methods:

public JiffleDirectRuntime getRuntimeInstance()
Returns object suitable for direct evaluation (the default), ie. the runtime class implements JiffleDirectRuntime and extends AbstractDirectRuntime

public JiffleRuntime getRuntimeInstance( EvaluationModel type )
Returns an object for either direct or indirect evaluation according to the type arg.

public <T extends JiffleRuntime> T getRuntimeInstance( Class<? extends JiffleRuntime> baseClass )
Infers the evaluation model from the user-supplied base class and returns an object with class extending this base class.

Initial code and unit tests committed to trunk (r1316)

Comment by project member michael.bedward, Feb 28, 2011
Further work on this will be after the 1.10 release.

Comment by project member michael.bedward, Mar 15, 2011
I don't think it's possible to use AreaOpImage as the base for a JiffleOpImage because there's no way of predicting the buffer size since it can be a function of runtime values. So I guess it should be based on SourcelessOpImage. Will do some experiments along that line this week.

Original issue: http://code.google.com/p/jiffle/issues/detail?id=2

Original author: [email protected] (April 01, 2011 01:02:58)

Currently, JiffleExecutor accepts a Jiffle object via this method:

public int submit(Jiffle jiffle, 
        Map<String, RenderedImage> images,
        JiffleProgressListener progressListener)

Add another version to accept a JiffleDirectRuntime object:

public int submit(JiffleDirectRuntime runtime, 
        Map<String, RenderedImage> images,
        JiffleProgressListener progressListener)

This reduces overhead when repeatedly running the same script with different images.

Original issue: http://code.google.com/p/jiffle/issues/detail?id=12

Original author: [email protected] (June 16, 2011 10:16:26)

The Maven groupId and root package name is now org.jaitools, in line with the new dashless JAITools project

Original issue: http://code.google.com/p/jiffle/issues/detail?id=26

Original author: [email protected] (March 28, 2011 10:28:51)

This is a hang-over from before the last round of changes to code generation templates. Need to remove the bounds vars and the setBounds method from AbstractindirectRuntime and rely on the base class instead.

Original issue: http://code.google.com/p/jiffle/issues/detail?id=8

Original author: [email protected] (April 01, 2011 02:31:21)

Add the following...

getJiffle() // to retrieve the compiled Jiffle object

getRuntimeSource() // to retrieve the Java source

Original issue: http://code.google.com/p/jiffle/issues/detail?id=14

ANTLR v4 allows for a cleaner separation between grammar files and Java sources.

With previous versions of Jiffle based on ANTLR v3, many compilation tasks required Java code embedded within grammars which was convoluted and brittle. Multiple grammar files were required to follow the v3 idiom of progressive modification of an AST.

ANTLR v4 encourages a single, language-neutral grammar. Jiffle scripts will be compiled to parse trees which are then walked using ordinary Java classes. This should make the compiler sources much easier to understand, maintain and extend.

Original author: [email protected] (April 04, 2011 14:54:39)

Add a getVarNames method to JiffleRuntime to retrieve mage scope variable names that can be used with the getVar and setVar methods.

Original issue: http://code.google.com/p/jiffle/issues/detail?id=20

Original author: [email protected] (April 20, 2011 05:10:40)

jiffle trunk (0.2-SNAPSHOT) should now depend on the new jai-tools trunk version (2.0-SNAPSHOT)

Original issue: http://code.google.com/p/jiffle/issues/detail?id=24

Original author: [email protected] (March 23, 2011 11:08:37)

Add some way of doing running samples in Jiffle so that it's possible to calculate mean of whole image for example. The StreamingSampleStats class can do this (as used in ZonalStats op). We just need a nice syntax to hide the fiddly bits from the script.

Original issue: http://code.google.com/p/jiffle/issues/detail?id=3

Original author: [email protected] (April 11, 2011 13:48:07)

Current CoordinateTransform code doesn't take into account Y-axis direction. For example, when passing geo-spatial bounds to CoordinateTransforms.getTransform method, the transform is calculated as if the image Y coordinates and geo Y coordinates run in the same direction.

One work around with version 0.1.0 is to construct an AffineTransform manually and pass this to the AffineCoordinateTransform constructor.

Original issue: http://code.google.com/p/jiffle/issues/detail?id=23

Original author: [email protected] (June 03, 2011 04:45:19)

witching sources in trunk and the 0.1.x branch over to the simplified (two clause) BSD licence.

Original issue: http://code.google.com/p/jiffle/issues/detail?id=25

Original author: [email protected] (March 29, 2011 04:58:27)

This would let Jiffle scripts be used to just calculate image properties (e.g. number of values > threshold). Only makes sense for JiffleDirectRuntime objects.

Original issue: http://code.google.com/p/jiffle/issues/detail?id=9

Original author: [email protected] (April 01, 2011 07:34:22)

The method will return source for a direct model runtime class. This is analogous to the no-arg getRuntimeInstance method which returns a direct model runtime object.

Original issue: http://code.google.com/p/jiffle/issues/detail?id=16

Original author: [email protected] (March 27, 2011 10:53:13)

This corresponds to jai-tools issue 139

Original issue: http://code.google.com/p/jiffle/issues/detail?id=6

Original author: [email protected] (April 04, 2011 09:54:42)

Add version of the source and dest methods to take a CoordinateTransform argument. Also add world and defaultTransform methods to set the world bounds and resolution and the default coordinate transform respectively.

Original issue: http://code.google.com/p/jiffle/issues/detail?id=19

Original author: [email protected] (March 25, 2011 06:56:06)

At the moment the Jiffle parser requires that an options block precede an init block (if present). Relax this so that they can be in any order. The only constraint is that they must each precede the script body.

Original issue: http://code.google.com/p/jiffle/issues/detail?id=5

Original author: [email protected] (April 01, 2011 01:07:53)

After running a JiffleDirectRuntime object directly you can retrieve values of any image scope variables with the getVar( name ) method. We should make the variable values available in JiffleExecutorResult as well.

Original issue: http://code.google.com/p/jiffle/issues/detail?id=13

Original author: [email protected] (April 01, 2011 02:53:16)

I dropped this option when refactoring the runtime source generating code a while ago and forgot to put it back in.

Original issue: http://code.google.com/p/jiffle/issues/detail?id=15

Original author: [email protected] (March 23, 2011 11:02:04)

(Was Issue 21 in jai-tools list)

Jiffle assumes that the processing area bounds applies to all source and destination images (although we now have the 'outside' option to set a global value for out-of-bounds source pixels).

Associating an AffineTransform with a source image would allow users to deal with non-overlapping image bounds. It could also be used to work with images of different (client-defined) resolutions.

Original issue: http://code.google.com/p/jiffle/issues/detail?id=1

Original author: [email protected] (March 28, 2011 04:14:08)

ST4 has just been released. Upgrade Jiffle to use it for code generation as soon as it has been deployed to Maven Central (or perhaps deploy the ST4 jars to OSGeo if they won't be at Central for some time).

Original issue: http://code.google.com/p/jiffle/issues/detail?id=7

Original author: [email protected] (April 06, 2011 10:03:52)

Jiffle has a syntax for integer sequences that can be used in foreach blocks. Example:

foreach (dx in -2:2)

Add a seq function to allow for other step values. Example:

seq(-100, 100, 25)

Original issue: http://code.google.com/p/jiffle/issues/detail?id=21