Re: [Gimp-developer] transformation drift [was: preview window does not work]

2007-03-10 Thread Sven Neumann
Hi,

On Fri, 2007-03-09 at 09:07 +0100, Sven Neumann wrote:

 If you have a look at it now, be warned that there's a bug in the
 pixel-surround routines which I introduced two days ago. I am aware of
 the bug and I will either fix it over the next days or revert some
 optimizations. So please don't wonder about artefacts at the bottom of
 the source area, these are due to this bug.

Just FYI: That problem should be fixed now.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] transformation drift [was: preview window does not work]

2007-03-10 Thread gg
On Sat, 10 Mar 2007 21:24:13 +0100, Sven Neumann [EMAIL PROTECTED] wrote:

 Hi,

 On Fri, 2007-03-09 at 09:07 +0100, Sven Neumann wrote:

 If you have a look at it now, be warned that there's a bug in the
 pixel-surround routines which I introduced two days ago. I am aware of
 the bug and I will either fix it over the next days or revert some
 optimizations. So please don't wonder about artefacts at the bottom of
 the source area, these are due to this bug.

 Just FYI: That problem should be fixed now.


 Sven


thx for the update.
gg
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] transformation drift [was: preview window does not work]

2007-03-09 Thread Sven Neumann
Hi,

On Thu, 2007-03-08 at 09:45 +0100, [EMAIL PROTECTED] wrote:

 I have limitted time right now but I'll try to have a look in the next few  
 days, though I dont follow your logic.

If you have a look at it now, be warned that there's a bug in the
pixel-surround routines which I introduced two days ago. I am aware of
the bug and I will either fix it over the next days or revert some
optimizations. So please don't wonder about artefacts at the bottom of
the source area, these are due to this bug.

 The reason this is optimised like  
 this is because there is NO NEED for any fancy techniques since it's a  
 one-to-one mapping.

Is it really always a one-to-one mapping? I might be wrong but this
seems to be dependant on the choice of the center of rotation and I am
not sure if correctly check for this.

 I did start to look into this a while back but ran out of time. One source  
 of error I noted was that the code splits all transforms into an origin  
 and offset coordinates for just about all operations. Many of these are  
 done with the origin at the image centre. This means two truncations , two  
 rounding errors.

Sounds like we should investigate this further.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] transformation drift [was: preview window does not work]

2007-03-08 Thread David Gowers

On 3/8/07, Sven Neumann [EMAIL PROTECTED] wrote:


Hi,

 If you rotate by exactly 90 degrees, this is always done with
 INTERPOLATION_NONE, no matter what you select in the tool options.

Perhaps this is the culprit? An offset seems unavoidable if the
transformation is performed without interpolation. So perhaps all we
need to do is to remove this optimization (which is supposed to speed up
rotations by multiple of 90 degrees)?



BTW, do you think the rotation centre should be snapped to 0.5 pixel
increments when interpolation is NONE? It doesn't make sense to have any
more precision at that point (and can introduce glitches -- for instance,
try floating a rectangular region, then dragging the rotation centre to the
top left as precisely as you can, setting it to rotate 90 degrees, and
performing the rotation... -- compared to inputting the coordinates of the
top left yourself and then performing the 90 degree rotation. In the first
case, even fractional imprecision means the result is not even in the right
place.)

Anyway, in the case of a 90 degree rotation, it seems unlikely that the user
would want it misaligned with the pixels -- in which case no interpolation
is needed and the result should be exactly right.


Simple test case that uniformly fails, currently:

* Select a rectangular region of the picture.
* Float it
* Rotate it. Set the rotation centre to the exact top left (by first
positioning the centre near it, then editing the coordinates in the rotation
dialog to make them exact). Set the angle to 90 degrees and the
interpolation to NONE. Supersampling option appears to have no effect in
this case.
* The result may be offset by 1 pixel in X and/or Y axis; It is also missing
one line of pixels (which line is omitted varies.)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] transformation drift [was: preview window does not work]

2007-03-08 Thread gg
On Thu, 08 Mar 2007 11:54:25 +0100, David Gowers [EMAIL PROTECTED] wrote:

 On 3/8/07, Sven Neumann [EMAIL PROTECTED] wrote:

 Hi,

  If you rotate by exactly 90 degrees, this is always done with
  INTERPOLATION_NONE, no matter what you select in the tool options.

 Perhaps this is the culprit? An offset seems unavoidable if the
 transformation is performed without interpolation. So perhaps all we
 need to do is to remove this optimization (which is supposed to speed up
 rotations by multiple of 90 degrees)?


 BTW, do you think the rotation centre should be snapped to 0.5 pixel
 increments when interpolation is NONE? It doesn't make sense to have any
 more precision at that point (and can introduce glitches -- for instance,
 try floating a rectangular region, then dragging the rotation centre to  
 the
 top left as precisely as you can, setting it to rotate 90 degrees, and
 performing the rotation... -- compared to inputting the coordinates of  
 the
 top left yourself and then performing the 90 degree rotation. In the  
 first
 case, even fractional imprecision means the result is not even in the  
 right
 place.)

 Anyway, in the case of a 90 degree rotation, it seems unlikely that the  
 user
 would want it misaligned with the pixels -- in which case no  
 interpolation
 is needed and the result should be exactly right.


 Simple test case that uniformly fails, currently:

 * Select a rectangular region of the picture.
 * Float it
 * Rotate it. Set the rotation centre to the exact top left (by first
 positioning the centre near it, then editing the coordinates in the  
 rotation
 dialog to make them exact). Set the angle to 90 degrees and the
 interpolation to NONE. Supersampling option appears to have no effect in
 this case.
 * The result may be offset by 1 pixel in X and/or Y axis; It is also  
 missing
 one line of pixels (which line is omitted varies.)

I think you can achieve the same results without floating. Just try a  
rotate.

gg

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] transformation drift [was: preview window does not work]

2007-03-07 Thread Sven Neumann
Hi,

 If you rotate by exactly 90 degrees, this is always done with
 INTERPOLATION_NONE, no matter what you select in the tool options.

Perhaps this is the culprit? An offset seems unavoidable if the
transformation is performed without interpolation. So perhaps all we
need to do is to remove this optimization (which is supposed to speed up
rotations by multiple of 90 degrees)?

Peter, can you try to remove that code in
app/core/gimp-transform-region.c (line 208 and 209) and check if that
fixes your test case?


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer