[postgis-devel] [raster] Implementations of rotation and pixel size.

[Bryce L Nordgren]

On Tue, Sep 13, 2011 at 6:20 PM, Bryce L Nordgren <bnordgren at gmail.com> wrote:
> On Tue, Sep 13, 2011 at 9:58 AM, David Zwarg <dzwarg+postgis at azavea.com> wrote:
>> I had used the wikipedia page as my starting point when I was working with
>> the raster rotation stuff: http://en.wikipedia.org/wiki/World_file

I wrote another page giving the math (with steps) for how to get size
and rotation (well for now just size) given the affine transform
coefficients. If we're willing to assume that there's no shearing,
then there's good news and bad news.

Bad news: I don't match wikipedia, the way I did it.

Good news: We can match wikipedia by swapping the order of "scaling"
and "rotation".

More bad news: it's not important that we match wikipedia, it's
important that we use the same model as whomever calculated the affine
transform (which may not be us).

Horrible news: the "talk" page for that particular wikipedia article
does not instill confidence that the authors have much of a clue about
what is really going on. Their math is completely unsourced, and while
they can copy numbers out of a file and stick them in the matrix, the
equation for pixel width appears out of thin air.

Even more bad news: if we want to handle images produced by more than
one suite of software, we need to know what model each piece of
software was using, and apply the correct reverse calculation. If they
all do it in the same way, that would simplify things, but I see
nothing which guarantees that. The alarming thing is that there's no
obvious way to detect when our assumptions are wrong.

Somewhat good news: after chucking "skewing", there's only two
combinations we need to worry about: "scaling followed by rotation" or
"rotation followed by scaling".  It's important to note that neither
ordering is "wrong". It's just that when we're undoing a calculation,
we need to know which one to undo.

So I'd suggest a survey of software packages and/or file formats.
Assemble anything which tells us how a particular format expects to
see those coefficients generated (if it places constraints on their
generation), or which documents the model used by software to compute
these coefficients. Your code as it stands is likely to be correct
half the time.

Bryce