Is this fixed on rc2?
How about on your install, does this happen?
Socialpreneur-
I saw your screenshots in trac. Please tell me if I understand what you’re trying to do.
Based on those screenshots, it appears you are trying to crop an avatar and make it a non-square size. Is that true?
If so, avatars (as used in the WordPress world and many other places) have a square dimension. That is why the extra black bar got added to your crop. The Image processing code for changing your avatar is set to output a square-dimensioned image.
But the original image is quite large, I mean it’s a website screen shot. If cropping works fine, then I should be able to create a full avatar from wherever the area of my picture. But as you see on the trac, there’s something wrong…
Okay, I looked at the screenshots again. It does indeed seem like you selected a square image.
On more thought, I guess it would not be possible to select anything but a square image using this feature. So, you select a square area of your image but it chops off a part of the selected area.
I assume this happens with any image you try. Have you tried using a different browser?
IE, firefox…chrome not yet…
But if firefox isn’t working, then it’s dead…u know what I’m saying 
I do know what you mean!
I’ve tried recreating your problem. I develop on a Mac and cannot replicate this issue in either Safari of Firefox (tried multiple versions of both). I’m running WPMU 2.7 and BP r1286.
Are you developing locally? Or are you on a remote server?
Has this always been an issue? Or could you properly crop before but not since a recent BuddyPress update?
I also assume that you cleared your browser’s cache and cookies, relaunched your browser and tried again. In years past, some people had issues with avatar cropping in IE. That trick seemed to usually work. However, since you’re also seeing this behavior in Firefox, that’s probably not what’s happening here.
Finally, which version of PHP are you running? Can you also check which version of the GD library is installed?
I\’ve imagemagick 6.4.2.1 installed, with PHP 5.2.6. I\’m using WestHost VPS.
GD Support enabled
GD Version bundled (2.0.34 compatible)
FreeType Support enabled
FreeType Linkage with freetype
FreeType Version 2.3.5
T1Lib Support enabled
GIF Read Support enabled
GIF Create Support enabled
JPG Support enabled
PNG Support enabled
WBMP Support enabled
XBM Support enabled
The function that takes care of avatar cropping is a jQuery function. I’m not sure, but I think it relies upon PHP’s GD library. Perhaps this could be your issue.
I’m all out of ideas on this one. Andy or someone with more inside BP knowledge will have to take it from here.
updated…
GD Support enabled
GD Version bundled (2.0.34 compatible)
FreeType Support enabled
FreeType Linkage with freetype
FreeType Version 2.3.5
T1Lib Support enabled
GIF Read Support enabled
GIF Create Support enabled
JPG Support enabled
PNG Support enabled
WBMP Support enabled
XBM Support enabled
Well, okay then. You have the same GD library that I’m using.
Have you always had this problem or did it start happening after you updated BuddyPress?
It’s only a few days ago since I started to debug changing avatars… 
btw, I found this code within bp-xprofile-cssjs.php
//wp_enqueue_script(‘jquery’);
//wp_enqueue_script(‘prototype’);
wp_enqueue_script(‘scriptaculous-root’);
wp_enqueue_script(‘cropper’);
add_action( ‘wp_head’, ‘bp_core_add_cropper_js’ );
You say it’s jquery function, but above code comments out jquery and prototype as default. Perhaps this is the reason why?
I think I found the cause of all the errors.
If the original image is smaller than 150×150, then it produces the black areas within the result avatars.
solution:
a) we need a warning message the original is too small to generate avatar.
or
b) even if it’s smaller, the script should calculate and create a zoomed avatar, so the black areas are not generated.
Yes, that does make sense.
If you look at bp-core-avatars.php, it sets the small avatar version at 50 by 50 and the large at 150 by 150. So, if your source image is smaller than 150 on at least one of its dimensions, you could have issues with the large avatar creation.
Do you see the black bar only on the large avatar version?
I think so, but if I used an image smaller than 50×50…then it might also happen for small avatars. But I wouldn’t think people is going to do that.
If you have not yet done so, you should update your trac record with your findings.
Also, it does appear that in a future version of this component file, the avatar size limits will be configurable by the admin. In bp-core-avatars.php, see the TODO comment:
/* Define settings for avatars. [TODO] This will eventually end up as admin configurable settings */
define( 'CORE_AVATAR_V1_W', apply_filters( 'bp_core_avatar_v1_w', 50 ) );
define( 'CORE_AVATAR_V1_H', apply_filters( 'bp_core_avatar_v1_h', 50 ) );
define( 'CORE_AVATAR_V2_W', apply_filters( 'bp_core_avatar_v2_w', 150 ) );
define( 'CORE_AVATAR_V2_H', apply_filters( 'bp_core_avatar_v2_h', 150 ) );
You say it\’s jquery function, but above code comments out jquery and prototype as default. Perhaps this is the reason why?
I never answered your question about jQuery being used for avatar cropping. If you look for the bp_core_add_cropper_js function, you\’ll see it exists in the file bp-core-cssjs.php. That function relies upon jQuery to do the avatar cropping.
