The method of magic bitboards basically applies a hash function to the important occupancy, or in other words, all the pieces that could potentially block the currently moving piece.
For example, let's suppose that we have a rook on e4.
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . 1 . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
and that our occupancy looks like this:
. . . . 1 . . .
. . . . . . . .
. . . . 1 . . .
. . . . . . . .
. . . . R . . 1
. . . . 1 . . .
. . . . . . . .
. . . . . . . .
After hashing, we get an index into our table, and by accessing that index we should obtain the move-mask.
Our move mask, i.e. the squares that the rook can move to (without considering squares our pieces currently occupy), should look like this:
. . . . . . . .
. . . . . . . .
. . . . 1 . . .
. . . . 1 . . .
1 1 1 1 R 1 1 1
. . . . 1 . . .
. . . . . . . .
. . . . . . . .
The closest occupancies to the rook are registered as legal squares. They have to be AND'd with NOT our pieces. This way, we register captures as legal squares.
Note that the occupancy on h4 does not affect the movemask at all. Regardless of whether the h4 piece is there, we are still generating the same attackmask. So, the h4 piece isn't really a blocker.
The reason why removing the edges reduces memory is because to store the bitboards, we have to check through every possible permutation of relevant blockers for a rook or bishop on a given square, generate the attack mask, and apply the magic hashing to it generate an index into our hash table, which contains all of the corresponding attack masks. By removing redundant bits that don't affect the generated move-mask we can significantly reduce the size of our table.
AND
ing the "move mask" with the occupiers bitboard. The reason the borders are ignored for this "move mask" is because a piece on the border has no effect on whether a bishop/rook can attack other squares.