Hi Mike, 
So over the last couple of days in spare moments I was testing this; comments here relevant as of commit 0f986a8.

I found the following issue with the case switching way of doing things.  It's to do with the interpolant.  Here's an example.  I made a small, 6x6 noise field and generated the following correlation function from it (this is the underlying lookup table with the center at the red dot in the (4, 4) pixel:
![original_cf_271212](https://f.cloud.github.com/assets/1454961/32611/11bf1d36-502f-11e2-9255-1b429c21c523.png)

I then applyMagnification to this to make it larger by a factor of 8, and redraw:
![original_x8_cf_271212](https://f.cloud.github.com/assets/1454961/32613/2c397ae4-502f-11e2-8207-c9b170d38437.png)

You can see that the interpolation is not happening properly at one interface of the bottom right and top left pixels.  This is because the case switching is happening at the level of the `xValue` call, rather than deeper at the `xtable` interpolant level.  Here's the case switching from `CorrelatedNoise.cpp`:
```
double SBCorrFunc::SBCorrFuncImpl::xValue(const Position<double>& p) const 
    {
        /*
         * Here we do some case switching to access only part of the stored data table, enforcing
         * two-fold rotational symmetry by taking data only from the region y < 0. where possible.
         *
         * There is an additional subtlety for even dimensioned data tables. As discussed in the
         * Pull Request for this addition to GalSim, see
         * https://github.com/GalSim-developers/GalSim/pull/329#discussion-diff-2381280, the shape
         * of the region in the data table that needs to be accessed is slightly non-trivial.  We 
         * use the entire region with y < 0., but also need to access to the upper half of the 
         * left-most column of data: this is not present in the lower right quadrant of the data
         * table, and so we redirect to the upper left if necessary.
         */
        if ( _is_even ) {
            //double dist_to_edge = _shdim * _multi.getScale();
            if ( p.y <= 0. ) {
                if ( p.x > _shdim ) {
                    return _xtab->interpolate(-p.x, -p.y, *_xInterp);
                } else {
                    return _xtab->interpolate(p.x, p.y, *_xInterp);
                }
            } else {
                if ( p.x < -_shdim ) {
                    return _xtab->interpolate(p.x, p.y, *_xInterp);
                } else {
                    return _xtab->interpolate(-p.x, -p.y, *_xInterp);
                }
            }
        } else {
            if ( p.y <= 0. ) {
                return _xtab->interpolate(p.x, p.y, *_xInterp);
            } else {
                return _xtab->interpolate(-p.x, -p.y, *_xInterp);                
            }
        }
    }
```
N.B. `_shdim` is the short half dimension of the image, which I define and store in a new `initialize()` function for the `SBCorrFunc` (as yet not renamed).

It seems to me that to get this working in a case-switching fashion would require redefining the way `interpolate` works for these special class of objects, probably with a new derived form of xTable.   I'm *really* starting to think that simply copy-pasting the sliver of data at the Python level will be by far the easier, and now clearer to explain, method of achieving the right behaviour at this edge...