imagemagick is extremely horrible to get right, and MT only require()s it as needed, so I'd assume that an installation glitch is likely and work at this one from both ends. First test your imagemagick installation from the command line:

$ convert ./my.jpg my.png
[download]

and then from a minimal script. If this works, for example, you can say with confidence that MT is broken:

use Image::Magick;

my $infile = '/some/image/or/other.jpg';
my $outfile = '/some/image/or/other_thumb.jpg';

my $image = Image::Magick->new;
my $check = $image->Read( filename => "$infile" );
die $check if $check;
$check = $image->Resize( geometry => "50x50" );
die $check if $check;
$check = $image->Write( filename => "$outfile" );
die $check if $check;
undef @$image;
print "ok\n";
[download]

Meanwhile, and assuming that nothing useful comes out of all that, you need to isolate the thumbnail-shrinking part of MT (which is in ./lib/MT/Image.pm) and, as tachyon suggests, fill it with warn statements and watch the logs. Note the odd way that IM returns errors above, for example, and drop that code into the right bit of MT along with lots of statements that tell you what filename it's trying to open and why it thinks that's a good idea.

You may even find that MT has a verbose toggle somewhere that will do this for you.

 

update: I tried to investigate properly but it just works here, which is annoying :).

I did learn two things, though. FIrstly that MT has some weird stuff going on with paths and it's worth double-checking all that, and secondly that MT consistently signals failure by returning an error object. The quick and dirty way to see what's going on would be to add this to MT::ErrorHandler after line 14:

    warn $msg;
[download]

or for the maximum debug-fountain:

# at the top
use Carp qw/cluck/;

# in sub error again:
cluck $msg;
[download]

good luck.