RSS/Atom feed Twitter
Site is read-only, email is disabled

API change for samplers to pass inverse Jacobian data to samplers

This discussion is connected to the gegl-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

18 of 19 messages available
Toggle history

Please log in to manage your subscriptions.

API change for samplers to pass inverse Jacobian data to samplers Adam Turcotte 25 Jun 22:50
  API change for samplers to pass inverse Jacobian data to samplers Nicolas Robidoux 25 Jun 22:53
  API change for samplers to pass inverse Jacobian data to samplers Nicolas Robidoux 26 Jun 04:47
   API change for samplers to pass inverse Jacobian data to samplers Nicolas Robidoux 26 Jun 14:13
    API change for samplers to pass inverse Jacobian data to samplers Nicolas Robidoux 29 Jun 15:16
     API change for samplers to pass inverse Jacobian data to samplers Martin Nordholts 29 Jun 21:42
      API change for samplers to pass inverse Jacobian data to samplers Nicolas Robidoux 29 Jun 21:53
       API change for samplers to pass inverse Jacobian data to samplers Martin Nordholts 29 Jun 21:57
      API change for samplers to pass inverse Jacobian data to samplers Adam Turcotte 29 Jun 22:42
       API change for samplers to pass inverse Jacobian data to samplers Martin Nordholts 29 Jun 22:44
       API change for samplers to pass inverse Jacobian data to samplers Nicolas Robidoux 30 Jun 00:26
  API change for samplers to pass inverse Jacobian data to samplers Martin Nordholts 29 Jun 21:35
1c8827380907021326w3c1717f1... 07 Oct 20:29
  API change for samplers to pass inverse Jacobian data to samplers Adam Turcotte 02 Jul 22:27
   API change for samplers to pass inverse Jacobian data to samplers Sven Neumann 02 Jul 22:34
    API change for samplers to pass inverse Jacobian data to samplers Martin Nordholts 02 Jul 22:40
     API change for samplers to pass inverse Jacobian data to samplers Sven Neumann 02 Jul 22:51
    API change for samplers to pass inverse Jacobian data to samplers Adam Turcotte 03 Jul 04:14
     API change for samplers to pass inverse Jacobian data to samplers Sven Neumann 03 Jul 20:38
Adam Turcotte
2009-06-25 22:50:35 UTC (over 15 years ago)

API change for samplers to pass inverse Jacobian data to samplers

In working on an implementation of Exact Area Box Filtering (modified so it does well both upsampling, downsampling, and actually, for arbitrary warps), which is particularly well-suited for downsampling, I have determined that the sampler should receive the inverse of the Jacobian matrix from the (currently, affine) transformation that is calling it. This inverse need not be exact--it can be an approximation, though the more accurate the approximation, the better the results. The motivation for this modification is that future developments such as warps, perspective, and other transformations of the same type will also be able to rely on the new sampler and use it to maximal effect.

I propose modifying each affine transformation's create_matrix () method to generate both the Jacobian and (an approximation of) the inverse Jacobian. In addition, I will need to expand the OpAffine struct to include an additional GeglMatrix3 (call it matrix_inverse or inverse_jacobian?) to store this data.

Now, I will also require passing this new matrix to the sampler. This appears to necessitate a slight API change, though the pre-existing samplers will simply ignore this new information. This expansion encourages further development of methods that take advantage of this inverse Jacobian data and sets a framework for future transformations that may also want to pass inverse Jacobian data to samplers that use it.

My question at the moment is: what is the best way to pass this data to the sampler?

Note: Passing the Jacobian matrix itself may be better, but Nicolas is of the opinion that degenerate cases are easier to handle if the inverse is passed.

Adam Turcotte

Nicolas Robidoux
2009-06-25 22:53:56 UTC (over 15 years ago)

API change for samplers to pass inverse Jacobian data to samplers

In the case of affine transformations, there is no need to approximate the inverse Jacobian: computing it exactly is trivial. For warps which follow a complex algorithm, it may however be necessary to approximate.

Nicolas Robidoux

Nicolas Robidoux
2009-06-26 04:47:31 UTC (over 15 years ago)

API change for samplers to pass inverse Jacobian data to samplers

Adam Turcotte writes:

In addition, I will need to expand the OpAffine struct to include an additional GeglMatrix3 (call it matrix_inverse or inverse_jacobian?) to store this data.

GeglMatrix3? Is this a 3x3 matrix type?

(Ignore the following if it is not.)

Maybe the matrix created by the create_matrix () method is not really the "plain Jacobian matrix" even for affine transformations.

I understand that there are convenient representations of common image transforms in terms of 3x3 matrices, but I wonder if using a 3x3 to store either the Jacobian or its inverse just confuses things, at least for our purposes.

My suggestion: If create_matrix () returns a 3x3, keep the inverse Jabocian computation out of create_matrix ().

Because I am far from certain that there would ever be a need to do matrix operations on the inverse Jacobian, I actually am not even sure that it is necessary to store it in an explicit matrix type. For documentation sake? Can anyone foresee a use for the inverse Jacobian matrix being stored in a 3x3?

Nicolas Robidoux

Nicolas Robidoux
2009-06-26 14:13:34 UTC (over 15 years ago)

API change for samplers to pass inverse Jacobian data to samplers

Adam:

(Ignore if my last email about GeglMatrix3 was off the mark.)

Is it that affine transformations, stored in 3x3 matrices, get simplified when they are chained?

If so, where is the final overall 3x3 representation?

Hopefully, extracting the linear part from it to compute the inverse Jacobian could be done there.

Nicolas Robidoux

Nicolas Robidoux
2009-06-29 15:16:54 UTC (over 15 years ago)

API change for samplers to pass inverse Jacobian data to samplers

Because, AFAIK, representing transformations as 3x3 matrices is only natural for affine, perspective and combinations, but not for more general warps, it is my opinion that what should be passed to samplers (so that those which may downsample use it) should either be an array with four double entries or an object of a type which could be named GeglMatrix2.

Is it really worth it to create (name) a new GEGL type just for this purpose? A plain array sure seems more expedient.

Nicolas Robidoux

Martin Nordholts
2009-06-29 21:35:05 UTC (over 15 years ago)

API change for samplers to pass inverse Jacobian data to samplers

On 06/25/2009 10:50 PM, Adam Turcotte wrote:

My question at the moment is: what is the best way to pass this data to the sampler?

I feel bad about you not getting a reply, so I want to give a reply even though it's not a super helpful one:

Use whatever way you can come up with and that works for you. If it turns out we don't like your approach for whatever reason, we'll take it from there.

Best regards,
Martin

Martin Nordholts
2009-06-29 21:42:05 UTC (over 15 years ago)

API change for samplers to pass inverse Jacobian data to samplers

On 06/29/2009 03:16 PM, Nicolas Robidoux wrote:

a type which could be named
GeglMatrix2.

Is it really worth it to create (name) a new GEGL type just for this purpose? A plain array sure seems more expedient.

Since GeglMatrix3 exists, GeglMatrix2 also should exist for consistency.

Personally I don't see the point in duplicating a matrix lib in every software, i.e. I question the introduction of GeglMatrix3 in the first place, I mean there certainly must be high quality libs for matrix operations out there, but that's a different story...

/ Martin

Nicolas Robidoux
2009-06-29 21:53:23 UTC (over 15 years ago)

API change for samplers to pass inverse Jacobian data to samplers

Martin Nordhotls wrote:

Personally I don't see the point in duplicating a matrix lib in every software, i.e. I question the introduction of GeglMatrix3 in the first place, I mean there certainly must be high quality libs for matrix operations out there, but that's a different story...

IMHO, when all you are dealing with are 3x3 matrices (which are not arbitrary 3x3, since they represent affine + perspective transformations), it is likely that a general purpose matrix library would be slower. Even more so with 2x2.

So, my vote is actually for "not library."

Nicolas Robidoux

Martin Nordholts
2009-06-29 21:57:09 UTC (over 15 years ago)

API change for samplers to pass inverse Jacobian data to samplers

On 06/29/2009 09:53 PM, Nicolas Robidoux wrote:

IMHO, when all you are dealing with are 3x3 matrices (which are not arbitrary 3x3, since they represent affine + perspective transformations), it is likely that a general purpose matrix library would be slower. Even more so with 2x2.

So, my vote is actually for "not library."

I'd expect any high quality matrix library to provide optimized routines and data structures for 3x3 matrices.

/ Martin

Adam Turcotte
2009-06-29 22:42:11 UTC (over 15 years ago)

API change for samplers to pass inverse Jacobian data to samplers

On Mon, Jun 29, 2009 at 3:44 PM, Martin Nordholts wrote:

Since GeglMatrix3 exists, GeglMatrix2 also should exist for consistency.

Should GeglMatrix2 also reside within gegl-matrix.c, or should it be separate? I can quickly create GeglMatrix2 for the purposes of passing Jacobian information.

Adam Turcotte

Martin Nordholts
2009-06-29 22:44:58 UTC (over 15 years ago)

API change for samplers to pass inverse Jacobian data to samplers

On 06/29/2009 10:42 PM, Adam Turcotte wrote:

Should GeglMatrix2 also reside within gegl-matrix.c

It'll be fine to put it in gegl-matrix.c

/ Martin

Nicolas Robidoux
2009-06-30 00:26:43 UTC (over 15 years ago)

API change for samplers to pass inverse Jacobian data to samplers

Adam:

At this point I think that all that is needed is:

A function which computes the 2x2 inverse Jacobian from the 3x3 and puts it in a 2x2. Given that right now only affine functions are supported in GEGL this is the inverse of the top-left 2x2. The source code needs to make a note that when perspective is supported the Jacobian and its inverse will not be solely defined by the top left 2x2 submatrix. (It would make sense to fix the code before the end of the Summer so that the inverse Jacobian is correct when perspective is implemented in GEGL.)

Nicolas Robidoux

Adam Turcotte
2009-07-02 22:27:44 UTC (over 15 years ago)

API change for samplers to pass inverse Jacobian data to samplers

On Mon, Jun 29, 2009 at 4:47 PM, Martin Nordholts wrote:

It'll be fine to put it in gegl-matrix.c

I have added the typedef, but now I have the issue of adding this GeglMatrix2 as a property of the sampler. I notice that there are g_object_class_install_property ( ) lines that use g_param_spec_pointer () and g_param_spec_object () to specify a GParamSpec.

What is the correct method call for a GeglMatrix2?

Adam Turcotte

Sven Neumann
2009-07-02 22:34:41 UTC (over 15 years ago)

API change for samplers to pass inverse Jacobian data to samplers

Hi,

On Thu, 2009-07-02 at 16:27 -0400, Adam Turcotte wrote:

I have added the typedef, but now I have the issue of adding this GeglMatrix2 as a property of the sampler. I notice that there are g_object_class_install_property ( ) lines that use g_param_spec_pointer () and g_param_spec_object () to specify a GParamSpec.

What is the correct method call for a GeglMatrix2?

You should make GeglMatrix2 a boxed type and use g_param_spec_boxed() for it. gegl-utils.c has code that does this for GeglRectangle.

Sven

Martin Nordholts
2009-07-02 22:40:57 UTC (over 15 years ago)

API change for samplers to pass inverse Jacobian data to samplers

On 07/02/2009 10:34 PM, Sven Neumann wrote:

Hi,

On Thu, 2009-07-02 at 16:27 -0400, Adam Turcotte wrote:

I have added the typedef, but now I have the issue of adding this GeglMatrix2 as a property of the sampler. I notice that there are g_object_class_install_property ( ) lines that use g_param_spec_pointer () and g_param_spec_object () to specify a GParamSpec.

What is the correct method call for a GeglMatrix2?

You should make GeglMatrix2 a boxed type and use g_param_spec_boxed() for it. gegl-utils.c has code that does this for GeglRectangle.

Or he can just do as GeglProcessor does for its GeglRectangle property and use g_param_spec_pointer() and copy the data on a set/get.

/ Martin

Sven Neumann
2009-07-02 22:51:41 UTC (over 15 years ago)

API change for samplers to pass inverse Jacobian data to samplers

Hi,

On Thu, 2009-07-02 at 22:43 +0200, Martin Nordholts wrote:

You should make GeglMatrix2 a boxed type and use g_param_spec_boxed() for it. gegl-utils.c has code that does this for GeglRectangle.

Or he can just do as GeglProcessor does for its GeglRectangle property and use g_param_spec_pointer() and copy the data on a set/get.

Better fix GeglProcessor then and make it use the boxed GeglRectangle type properly.

Sven

Adam Turcotte
2009-07-03 04:14:46 UTC (over 15 years ago)

API change for samplers to pass inverse Jacobian data to samplers

On Thu, Jul 2, 2009 at 4:34 PM, Sven Neumann wrote:

You should make GeglMatrix2 a boxed type and use g_param_spec_boxed() for it. gegl-utils.c has code that does this for GeglRectangle.

Should the GType be declared inside gegl-matrix.h?

Should the required methods for this new Boxed Type be included in gegl-utils.c?

Thanks!

Adam Turcotte

Sven Neumann
2009-07-03 20:38:06 UTC (over 15 years ago)

API change for samplers to pass inverse Jacobian data to samplers

Hi,

On Thu, 2009-07-02 at 22:14 -0400, Adam Turcotte wrote:

On Thu, Jul 2, 2009 at 4:34 PM, Sven Neumann wrote:

You should make GeglMatrix2 a boxed type and use g_param_spec_boxed() for it. gegl-utils.c has code that does this for GeglRectangle.

Should the GType be declared inside gegl-matrix.h?

Should the required methods for this new Boxed Type be included in gegl-utils.c?

Keep them all in a single place. The GeglRectangle code should actually be moved out of gegl-utils.[ch] to new files gegl-rectangle.[ch].

Sven