Image compression appears to be more accurately a "resize" rather than a compression. The default compression value is 300dpi (in LO 7.0), and for an image with a smaller DPI already, it will expand the image to 300dpi, increasing the filesize for no apparent benefit.  I can't really think of a reason why anyone would want to force a reverse compression, so probably it should just do nothing in this case. This will especially be important when <hopefully> there will be option to compress all images in the document.

When used interactively, it could be argued that the user has all the information they need to determine whether or not to compress. True enough for a knowledgable user, but there can probably be some improvements here. One possibility would be to set the default to min(currentViewsizeDPI, 300) [an interesting easyhack?]. The other option would be to add a (by default enabled) checkbox to only compress. 

Using attachment 131240 [details] from bug 83734#c6, the first picture is at an effective 96dpi at it's current view size. Compressing that image (using the default DPI of 300) increases the filesize of the image and of the entire document.

I think this has always been true, but recently the default changed from 96 to 300. 300 seems like a good default in general, but it will expose this anti-compression problem more easily.

svx/source/dialog/compressgraphicdialog.cxx would be the place to start looking at this. Getting the currentViewsizeDPI could be a bit tricky, so lots of different image types and situations should be tested.