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