On Fri, 09 Mar 2007 09:07:48 +0100, Sven Neumann <[EMAIL PROTECTED]> wrote:

>> 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.

yes , you may be right. I was resting on a preconception of the centre of  
rot. being integer or half-integer as it is by default. But I think the  
recent fp input allows 0.01 increments. Maybe the desirablility of that  
needs to be checked.

0.5 did solve some drift but finer offsets may produce other errors or  
need some follow through.

there is also the question of differing x and y resolution.

you are probably right that the optimisation is inappropriately tested but  
it was not the cause of the test case I ran that was symetrical and  
integer centred. The drift remains when the lines you indicated are  

>> 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.

Yes, I dont know if I'll have time to have a serious look at this but I  
think the offset needs to remain fp as long as possible , not get  
truncated, and all gint() casts need to be checked.

These drifts may sound trivial but can lead to noticable noise after very  
few operations. Take a small, simple geometric shape , rotate L 15, rotate  
R 15, the ammount of non-symetric noise is not good.

Thanks for taking the comments on board, I think it's important that the  
gimp does not degrade image quality more than is mathematically  

Gimp-developer mailing list

Reply via email to