Just to avoid disappointment: Pixel-perfect collision detection done this way is horribly inefficient (O(n2) if that rings any bells), and it doesn't look / feel as good as you think. Most 2D games do NOT use it; instead, they represent the sprites as geometric shapes of some kind (rectangles, circles, polygons, or combinations of these) and perform collision detection on those, using the actual bitmaps for display only. If you look closely at, for example, classic Mario titles, you'll see that the Mario sprite often overlaps a bit with solid tiles, creating a more natural look & feel.
If you insist on doing pixel-perfect, the best approach is to create a collision mask: Split your sprite into rows with a height of 1 pixel, find the first and last pixel on that row. Store these for every row of your sprite. Then do the same for columns. To check two such masks against each other, you need to first figure out which rows line up, and what their horizontal offset is. Using the min and max values from each, you can now check if the rows overlap. Do the same for the columns. If at least one pair of rows and one pair of columns overlap, you have a collision. This doesn't handle all shapes, but should be OK for most things you ever encounter in a 2D game, and it is far more efficient (O(n)), especially for larger sprites. It's still more wasteful than bounding boxes or bounding spheres (which are O(1)), so you should still do these to filter out the obvious non-collisions.
It may also be a good idea to use a different sprite for the collision mask than the one you're actually displaying, so you can create the overlap effect I mentioned above.