Am I correct in this? That the big version URL can be derived from
that in profile_image_url by dropping the _normal from the name? Is
this part of the API spec? Safe to use?
> Am I correct in this? That the big version URL can be derived from > that in profile_image_url by dropping the _normal from the name? Is > this part of the API spec? Safe to use?
They should - I believe there was an issue at one point where profile
images weren't being scaled down properly. It's fixed now, but old
(broken) avatars remain broken. That user needs to re-upload their
profile image.
On Mar 1, 7:51 pm, Dave Briccetti <da...@davebsoft.com> wrote:
> They should - I believe there was an issue at one point whereprofile
> images weren't being scaled down properly. It's fixed now, but old
> (broken) avatars remain broken. That user needs to re-upload theirprofileimage.
> On Mar 1, 7:51 pm, Dave Briccetti <da...@davebsoft.com> wrote:
> > This is odd. For some reason, this “thumbnail” is huge. Shouldn’t they
> > all be small?
> On Mar 1, 9:08 pm, atebits <loren.brich...@gmail.com> wrote: >> They should - I believe there was an issue at one point whereprofile >> images weren't being scaled down properly. It's fixed now, but old >> (broken) avatars remain broken. That user needs to re-upload theirprofileimage.
>> On Mar 1, 7:51 pm, Dave Briccetti <da...@davebsoft.com> wrote:
>> > This is odd. For some reason, this “thumbnail” is huge. Shouldn’t they >> > all be small?
> > On Mar 1, 9:08 pm, atebits <loren.brich...@gmail.com> wrote:
> >> They should - I believe there was an issue at one point whereprofile
> >> images weren't being scaled down properly. It's fixed now, but old
> >> (broken) avatars remain broken. That user needs to re-upload theirprofileimage.
> >> On Mar 1, 7:51 pm, Dave Briccetti <da...@davebsoft.com> wrote:
> >> > This is odd. For some reason, this “thumbnail” is huge. Shouldn’t they
> >> > all be small?
> > > On Mar 1, 9:08 pm, atebits <loren.brich...@gmail.com> wrote:
> > >> They should - I believe there was an issue at one point whereprofile
> > >> images weren't being scaled down properly. It's fixed now, but old
> > >> (broken) avatars remain broken. That user needs to re-upload theirprofileimage.
> > >> On Mar 1, 7:51 pm, Dave Briccetti <da...@davebsoft.com> wrote:
> > >> > This is odd. For some reason, this “thumbnail” is huge. Shouldn’t they
> > >> > all be small?
>> > > On Mar 1, 9:08 pm, atebits <loren.brich...@gmail.com> wrote: >> > >> They should - I believe there was an issue at one point whereprofile >> > >> images weren't being scaled down properly. It's fixed now, but old >> > >> (broken) avatars remain broken. That user needs to re-upload theirprofileimage.
>> > >> On Mar 1, 7:51 pm, Dave Briccetti <da...@davebsoft.com> wrote:
>> > >> > This is odd. For some reason, this “thumbnail” is huge. Shouldn’t they >> > >> > all be small?
On Mon, Mar 23, 2009 at 2:39 PM, Alex Payne <a...@twitter.com> wrote:
> Checking with our UX team about that.
Good... it's bugging me, too, because I display them on blog pages to show who has cited URLs. In the meantime, I suppose it wouldn't be too much of a browser performance hit to resize those in the image tag. Normal small icons seem to be 48x48 pixels.
> Am I correct in this? That the big version URL can be derived from
> that in profile_image_url by dropping the _normal from the name? Is
> this part of the API spec? Safe to use?
> On Feb 25, 12:15 am, Dave Briccetti <da...@davebsoft.com> wrote:
> > Hi. I’ve searched around for 1/2 hour or so, and haven’t found an
> > authoritative explanation of the sizes of pictures, and how to
> > retrieve them.
> > Am I correct in this? That the big version URL can be derived from
> > that in profile_image_url by dropping the _normal from the name? Is
> > this part of the API spec? Safe to use?
> Any progress on working with the UX team to resize these? TwitterBerry > is expecting a 48x48-pixel image.
> Cheers, > Jason > TwitterBerry
> On Mar 24, 7:49 am, Shannon Whitley <shannon.whit...@gmail.com> wrote: >> Don't forget the _mini. :)
>> This is my list:
>> (original) >> _mini >> _normal >> _bigger
>> On Feb 25, 12:15 am, Dave Briccetti <da...@davebsoft.com> wrote:
>> > Hi. I’ve searched around for 1/2 hour or so, and haven’t found an >> > authoritative explanation of the sizes of pictures, and how to >> > retrieve them.
>> > Am I correct in this? That the big version URL can be derived from >> > that in profile_image_url by dropping the _normal from the name? Is >> > this part of the API spec? Safe to use?
> Any progress on working with the UX team to resize these? TwitterBerry
> is expecting a 48x48-pixel image.
> Cheers,
> Jason
> TwitterBerry
> On Mar 24, 7:49 am, Shannon Whitley <shannon.whit...@gmail.com> wrote:
> > Don't forget the _mini. :)
> > This is my list:
> > (original)
> > _mini
> > _normal
> > _bigger
> > On Feb 25, 12:15 am, Dave Briccetti <da...@davebsoft.com> wrote:
> > > Hi. I’ve searched around for 1/2 hour or so, and haven’t found an
> > > authoritative explanation of the sizes of pictures, and how to
> > > retrieve them.
> > > Am I correct in this? That the big version URL can be derived from
> > > that in profile_image_url by dropping the _normal from the name? Is
> > > this part of the API spec? Safe to use?
On Sun, Mar 29, 2009 at 23:05, Andrew Maizels <andrew.maiz...@gmail.com> wrote:
> We'd really like to see a fix for this too. Having a few hundred > unexpectedly large images floating around is playing havoc with our > memory usage.
>> > On Feb 25, 12:15 am, Dave Briccetti <da...@davebsoft.com> wrote:
>> > > Hi. I’ve searched around for 1/2 hour or so, and haven’t found an >> > > authoritative explanation of the sizes of pictures, and how to >> > > retrieve them.
>> > > Am I correct in this? That the big version URL can be derived from >> > > that in profile_image_url by dropping the _normal from the name? Is >> > > this part of the API spec? Safe to use?
Thanks Alex for making sure this gets taken care of. It's been driving me nuts here chasing ghosts why my IO appears to be blocked when its actually trying to just pull a massive image.
Basically I'm having all the same issue other are having... My IO library doesn't make it easy to cancel a transfer that is partially complete for our client (doable but increases the complexity a lot), one big image can invalidate several older images in my cache engine because of memory constraints and I don't want to write resizing code before I put it in the cache, and it creates a bottleneck because our client runs where bandwidth is usually small quiet often, etc, etc. You know the deal :-)
On Mon, Mar 30, 2009 at 12:23 PM, Alex Payne <a...@twitter.com> wrote:
> It's one of our top issues right now.
> On Sun, Mar 29, 2009 at 23:05, Andrew Maizels <andrew.maiz...@gmail.com> wrote:
>> We'd really like to see a fix for this too. Having a few hundred >> unexpectedly large images floating around is playing havoc with our >> memory usage.
>>> > On Feb 25, 12:15 am, Dave Briccetti <da...@davebsoft.com> wrote:
>>> > > Hi. I’ve searched around for 1/2 hour or so, and haven’t found an >>> > > authoritative explanation of the sizes of pictures, and how to >>> > > retrieve them.
>>> > > Am I correct in this? That the big version URL can be derived from >>> > > that in profile_image_url by dropping the _normal from the name? Is >>> > > this part of the API spec? Safe to use?
On Wed, Apr 1, 2009 at 11:47 AM, Zac Bowling <zbowl...@gmail.com> wrote: > Thanks Alex for making sure this gets taken care of. It's been driving > me nuts here chasing ghosts why my IO appears to be blocked when its > actually trying to just pull a massive image.
> Basically I'm having all the same issue other are having... My IO > library doesn't make it easy to cancel a transfer that is partially > complete for our client (doable but increases the complexity a lot), > one big image can invalidate several older images in my cache engine > because of memory constraints and I don't want to write resizing code > before I put it in the cache, and it creates a bottleneck because our > client runs where bandwidth is usually small quiet often, etc, etc. > You know the deal :-)
> Zac Bowling
> On Mon, Mar 30, 2009 at 12:23 PM, Alex Payne <a...@twitter.com> wrote:
>> It's one of our top issues right now.
>> On Sun, Mar 29, 2009 at 23:05, Andrew Maizels <andrew.maiz...@gmail.com> wrote:
>>> We'd really like to see a fix for this too. Having a few hundred >>> unexpectedly large images floating around is playing havoc with our >>> memory usage.
>>>> > On Feb 25, 12:15 am, Dave Briccetti <da...@davebsoft.com> wrote:
>>>> > > Hi. I’ve searched around for 1/2 hour or so, and haven’t found an >>>> > > authoritative explanation of the sizes of pictures, and how to >>>> > > retrieve them.
>>>> > > Am I correct in this? That the big version URL can be derived from >>>> > > that in profile_image_url by dropping the _normal from the name? Is >>>> > > this part of the API spec? Safe to use?
> I'm still getting caught up on huge profile images (like this userhttp://twitter.com/TheDivawho's profile image is 1024x768 and 324 KB)
> Really hurting on the mobile side.
> Zac Bowling
> On Wed, Apr 1, 2009 at 11:47 AM, Zac Bowling <zbowl...@gmail.com> wrote:
> > Thanks Alex for making sure this gets taken care of. It's been driving
> > me nuts here chasing ghosts why my IO appears to be blocked when its
> > actually trying to just pull a massive image.
> > Basically I'm having all the same issue other are having... My IO
> > library doesn't make it easy to cancel a transfer that is partially
> > complete for our client (doable but increases the complexity a lot),
> > one big image can invalidate several older images in my cache engine
> > because of memory constraints and I don't want to write resizing code
> > before I put it in the cache, and it creates a bottleneck because our
> > client runs where bandwidth is usually small quiet often, etc, etc.
> > You know the deal :-)
> > Zac Bowling
> > On Mon, Mar 30, 2009 at 12:23 PM, Alex Payne <a...@twitter.com> wrote:
> >> It's one of our top issues right now.
> >> On Sun, Mar 29, 2009 at 23:05, Andrew Maizels <andrew.maiz...@gmail.com> wrote:
> >>> We'd really like to see a fix for this too. Having a few hundred
> >>> unexpectedly large images floating around is playing havoc with our
> >>> memory usage.
> >>>> > On Feb 25, 12:15 am, Dave Briccetti <da...@davebsoft.com> wrote:
> >>>> > > Hi. I’ve searched around for 1/2 hour or so, and haven’t found an
> >>>> > > authoritative explanation of the sizes of pictures, and how to
> >>>> > > retrieve them.
> >>>> > > Am I correct in this? That the big version URL can be derived from
> >>>> > > that in profile_image_url by dropping the _normal from the name? Is
> >>>> > > this part of the API spec? Safe to use?
I just pinged the developer who was supposed to be working on this and as he has had his hand on other fires this week. Thanks for the patience, we realize it is a pain.
> On Apr 4, 6:01 pm, Zac Bowling <zbowl...@gmail.com> wrote: > > Any news?
> > I'm still getting caught up on huge profile images (like this userhttp:// > twitter.com/TheDivawho's <http://twitter.com/TheDivawho%27s> profile image > is 1024x768 and 324 KB)
> > Really hurting on the mobile side.
> > Zac Bowling
> > On Wed, Apr 1, 2009 at 11:47 AM, Zac Bowling <zbowl...@gmail.com> wrote: > > > Thanks Alex for making sure this gets taken care of. It's been driving > > > me nuts here chasing ghosts why my IO appears to be blocked when its > > > actually trying to just pull a massive image.
> > > Basically I'm having all the same issue other are having... My IO > > > library doesn't make it easy to cancel a transfer that is partially > > > complete for our client (doable but increases the complexity a lot), > > > one big image can invalidate several older images in my cache engine > > > because of memory constraints and I don't want to write resizing code > > > before I put it in the cache, and it creates a bottleneck because our > > > client runs where bandwidth is usually small quiet often, etc, etc. > > > You know the deal :-)
> > > Zac Bowling
> > > On Mon, Mar 30, 2009 at 12:23 PM, Alex Payne <a...@twitter.com> wrote:
> > >> It's one of our top issues right now.
> > >> On Sun, Mar 29, 2009 at 23:05, Andrew Maizels < > andrew.maiz...@gmail.com> wrote:
> > >>> We'd really like to see a fix for this too. Having a few hundred > > >>> unexpectedly large images floating around is playing havoc with our > > >>> memory usage.
> > >>>> > On Feb 25, 12:15 am, Dave Briccetti <da...@davebsoft.com> wrote:
> > >>>> > > Hi. I’ve searched around for 1/2 hour or so, and haven’t found > an > > >>>> > > authoritative explanation of the sizes of pictures, and how to > > >>>> > > retrieve them.
> > >>>> > > It seems that profile_image_url leads to a tiny picture:
> > >>>> > > Am I correct in this? That the big version URL can be derived > from > > >>>> > > that in profile_image_url by dropping the _normal from the name? > Is > > >>>> > > this part of the API spec? Safe to use?
I've updated issue 497's status [1]. The avatar upload functionality sits within the core Twitter.com application. The results of this feature (avatars and images) are made available by the API. The image upload logic is currently being rewritten by a member of the core team. Unfortunately we do not have a definite time when this fix will ship.
|
