The answer is, it's complicated. It depends a lot on what you want to do with the pixels and such, and what you're doing with your graphics. I'd take a stab and guess that you can probably just use g2d.drawImage(), but the simplest thing is to start with that and see if things run to slow for your tastes. If they do, then profile and see where the problem is, it might be somewhere other than drawing.
But for a bit of background, basically images can be in tons of different formats, and the image classes hide a lot of that complication from you. If the format of your image doesn't match the format of your graphics device, then every time you draw the image the code under the covers does a lot of work converting each pixel in your image to the graphic device format. On the other hand this code is usually written pretty well and they can take advantage of lots of other stuff like caching images inside the graphics card, etc. Conceivably (a little bit of a guess here, as I don't muck around that deep in this kind of code) a call to drawImage() might be converted into a call across to the memory card, and use hardware to blit an image from one part of the graphic card memory into another part of the graphic card memory, very very quickly.
On the OTHER hand, if you know exactly what format your image or images are in and you know exactly what format you want to write it to, you can get at the underlying data structures (i.e. DataBuffers) and just munge the numbers yourself. Unfortunately once you ask Java to get at that data, all that magical code the sun guys wrote way back when can't rely on you not pulling the rug out from under them, i.e. they mark that image as "do not cache on the graphics card, ever", because they have no way of knowing if you wrote to that underlying big honking array of pixels. So now while you can do a lot of manipulations on the pixels a lot quicker, you can't take advantage of whatever hardware acceleration might be going on, or whatever other goodness the sun guys wrote under the covers.
Make sense? The real answer is that it greatly depends on what you're doing. Mind you there are a lot of things you can do to make things faster without mucking around with the pixels and messing up acceleration.
Among other things make sure that you create the BufferedImage that you're drawing too by calling createCompatibleImage on GraphicsConfiguration. This will hopefully avoid a having to convert all the pixels of the image you're drawing to the screen from one format to another, each and every time you draw.
Overall I suggest you start with that, and if things are too slow ABOVE ALL PROFILE your code because the slow part may very well not be in drawing to the screen. If you find it is the drawing that slows things down then do more research on the web.
Finally I leave you with the three Rules Of Optimization
1) Don't do it
2) Don't do it yet