Ah - the many wonderful battles one may have with Google's implementation of bitmap handling in Android.
I would tend to do some memory profiling anytime I hit the roof with memory - very often (although not always) it is because one is doing something wrong (i.e., unexpectedly memory intensive). Just browsing the code, I am a little bit puzzled by the need to force the code through three streams, just to end up with a bitmap again. I feel as if I'm missing some information for me to make sense of this, but I'd definitely take a look at just how much memory you're allocating in each of those steps if I were you (heap dump -> hprof-conv -> memory analyzer is your friend).
However, I suspect that what you may be looking for is BitmapRegionDecoder. I actually only recently discovered this myself, but I think it does pretty much exactly what you are after - allows you to decode a region from a bitmap (inputstream) without loading the entire bitmap into memory (you can also get the width/height). Only downside is that it is Android 2.3.3+ only, but these days that >90% of the market so that should not be a huge problem. I've done some pretty neat work with this (smooth pan and zoom of 6000x4000 image) - it is definitely memory effective if used right.
I recently open-source my own dumb implementation using BitmapRegionDecoder which handles pan, fling, and pinch-zoom of a very large bitmap. You can find the code (ASL2.0) at https://github.com/micabyte/android_game
The class you want to look at is BitmapSurfaceRenderer. So far I've tested it with up to 8000x4000 images, and it seems to work very well. When I get the time, I'll put up a simple example app that demonstrates how it is used as well.