[postgis-devel] [raster] Implementations of rotation and pixelsize.

[maplabs at light42.com]

I have always referred to these for fundemental math :

    http://tog.acm.org/resources/GraphicsGems/
  

On Sat, 17 Sep 2011 20:43:07 +0000, Bryce L Nordgren  wrote:
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
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>