Anyone like to try and explain this one? (All file sizes are nominal, and vary by a few kb, but I'll use constant numbers below to avoid confusion.)

I use Photobucket extensively, so am used to it. I have a general rule that pics hosted there are manually edited and manually uploaded - with Photobucket internal options and presets disabled - and are always 640 x 480 and 65 kb in size.

I don't check every file uploaded, but it's only a file transfer, and all those seen match what I send - except for three recent uploads.

A while ago, I uploaded three files without checking they were 65 kb. I only noticed then when I happened to look at the file info for another reason, and they were all 98 kb. When I checked the original megabyte image files, and reprocessed them, they came down to 98 kb, confirming I had merely forgotten the last step of reducing the the file size to 65 kb.

I did this, then deleted the 98 kb files from Photobucket, checked they were gone (to prevent the file name being altered to avoid a duplicate file name conflict or overwrite), and carried on to upload the new 65 kb versions of the files, which were otherwise identical to the deleted items, and forgot about it.

Until...

I happened to be looking at the pic info again, a few days later, and they were all 98 kb!!!

I thought I'd made a mistake, though I couldn't figure out what, but carried on and repeated the whole edit/delete/upload routine again, expecting the saved file to be 65 kb because I was looking at it in the folder I was uploading from, and I had just created it!

Lo and behold, when I checked what was in Photobucket - yep - it was still delivering the 98 kb file.

To make things stranger still, if I replace the 98 kb pic with another of the same name, then it changes to reflect the new pic.

But...

If I replace the 98 kb pic with the 65 kb pic, even if I change the file name, it still stays at 98 kb.

It's as if Photobucket was looking at the file content, and deciding that it's the same pic, and refusing to accept it for a second time.

I don't believe Photobucket is that clever, but on the other hand, I can't make the 65 kb file replace the 98 kb file, even if I try and delete the 98 kb file before I upload the 65 kb version.

I'm more than a little puzzled, and am either doing something fundamentally stupid or just plain wrong, or their code is real smart.

I'm going to give it one more try to get rid of the 98 kb pics and replace them with the 65 kb version today, and will post the success/failure or reduction to dribbling idiot that follows

Hmmm, strange.

Using anything other than the 'old uploader' to upload may well result in compression. The 'bulk uploader' function appears to be the main culprit.

I look forward to seeing your test results.

I have just set up a Flickr account but do use PB for most of my images.

As noted, the method of upload made no difference, I interchange between the ordinary file "upload from computer" on the PB page, but generally use the Windows uploader directly. My tiny 64 kb and 640 x 480 files wouldn't result in compression being triggered, but I have this disabled every time anyway, and also by default option (my setting is 1 MB before any actions are triggered).

I tried to think of something different to try this time, since I've done this whole process three times on all the images concerned after noting the first odd file size, and had echoes of a colleagues's pet phrase beginning to haunt me: Doing the same thing over and over and expecting a different result is the definition of insanity.

Because the images needed quite a bit of manipulation, I had processed them all using Photoshop, and used it to force a 64 kb file size. Standard procedure, and the file size was indeed 64 kb when checked prior to upload. using new file names and edits, the uploaded file size was once again 98 kb.

By way of breaking the insanity loop, I created new files using my usual IrfanView. Although unedited, these were still resized down to 640 x 480 and 64 kb. In Windows, these showed the same 64 kb file size as the Photoshopped versions, but when uploaded, the IrfanView remained at 64 kb - a clue at last!

Although it seemed daft, I took my Photoshopped 64 kb files, opened them in IrfanView, and saved them using IrfanView. No editing or other change were made, other than to force IrfanView to save the file at 64 kb. This must be specified as merely opening and resaving a jpg will result in a different file size depending on the compression level.

These files, created in Photoshop, but resaved by IrfanView were uploaded to PB.

I checked the freshly uploaded file size in PB...

It was...

64 kb!

So, that's the symptom revealed, if not the reason.

64 kb files saved by IrfanView are still 64 kb when uploaded to PB.

The same 64 kb files when saved by Photoshop become 98 kb files when uploaded to PB.

I've no idea why, and because I can't really tell which files I created earlier in Photoshop 7 or IrfanView (there are just too many), as opposed to the current version 8 which has recently arrived, I can't tell if it was happening before, or is down to some change in version 8.

Is PS perhaps embedding a colour profile or something?

It could indeed be some sort of subtle information that lesser packages might not include, although if PS was including more data, it would still increase the file size as reported by Windows and DOS.

Don't forget, both the PS and IV files I start with are reporting 64 kb in Windows before I do the transfer to PB.

I have jpg strippers that removed encoded and hidden information in the original file (I do this for anonymity sometimes) and when they remove the additional data, the Windows file size falls noticeably - although the routine just strips the data sections, and doesn't report what it has removed, but looking at  exif, iptc, etc shows these have all disappeared afterwards.

However, I am not dismissing or ignoring anything, and although I do have all the additional info turned off in the both IV and PS save defaults, next time I fire them up I will go in to the prefs and see what is set.

Now that you've flagged this up, I'll dig a little deeper and look at the compression method used too. It's not something I generally tamper with - there's little point - but if the tow packages use different routines, then it may be that the method used by PS unravels a little when one of its saved files is processed during an upload to PB.

Thanks for the hint - I probably would not have woken up to this one without it.

I think I've run out of ideas - and come up empty

I've made all the jpg configuration options I can see in PS , and none made any difference, the image file always grew after transfer to PB.

The following were options were selectively activated or de-activated to see their effect. While they did as expected and changed the saved file size, none appeared to have any effect on the observed increase in the file size after it was transferred to PB.

Colour profile active and inactive

Camera profile exifs aren't used and are permanently disabled, so weren't played with

Progressive jpg and standard jog

Optimised and standard jpg

Unless there are any more even more basic setting buried away smewhere, I can't see any more options on offer

I'll probably not bother chasing this further, since IrfanView does all I need for most web pics, and I only use PS for "difficult" fixes, and can port through IV when needed.

I had a quick web hunt, but couldn't get a form of words that returned anything more than the usual cries for help from folk that can't even work a PB account, so not worth the effort.

Still odd though.

I couldn't face any more repeated uploads and file size checks last night, but had a couple of cross-checks I wanted to try, just to see if the phenomenon was restricted to PB or had a wider influence.

First was straight FTP of all the test files I'd made into plain old web space online - no great surprises here, and all the files transferred and maintained their pre-transfer file sizes.

Next was an upload to my Flickr account - this isn't quite so straightforward to be completely sure about, since Flickr is kiddyware for the simple masses and only reports the pixel dimensions of the uploaded files (and automatically makes a number of irritating alternate size versions for download, plus the original size) but it doesn't report the actual file size in kb.

The only thing I could think of was to download the uploaded "original size" file (assuming Flickr would not downsize the original if if it had upsized it during upload) and see what size that was - the file sizes were the same before and after this exercise.

So, it would seem the growth of Photoshop jpg files only happens after a Photobucket upload, while those jpgs produced by other packages are unaffected.

OR...

I am having selective amnesia and suffering blindness when saving for the web in Photoshop, saving  two file sizes, and uploading the larger one when transferring to Photobucket. I must also be suffering the same affliction when moving these files around locally on my hard drive, and shuffling both version around, but only perceiving one  

I think PB is a very strange site anyway.   I have literally thousands of pics on Picassaweb and still have space in my free allocation and this despite not using the most economical picture size but just a couple of hundred on PB seem to have swallowed a massive chunk of my storage space and they take ages to upload.  Admittedly I don't compress them first but then I don't for Picassaweb either.

Photobucket isn't strange and doesn't actually take ages to upload - if you read the T&C.

Photobucket limits free account image sizes, so when you attempt to upload huge original image files straight from the camera, these are detected and and compressed before being saved. This is in line with its use as a web image hosting service, as opposed to an online photo album

It takes the code time to analyse the uploaded file, determine if it is within the allowed limits of a free account, check the owner's preferences for oversized image handling, and then run the compression routine to reduce the file size.

As compression is unpredictable - because the amount of file reduction a given compression level achieves varies depending on the image content - this is a recursive operation that needs to run a number of times in order to reach a desired file size. This operation means that images which exceed the specified limits will take considerably longer to upload load than those which are preprocessed and can be transferred directly into the target account without being manipulated en route.

Resize and reduce image file sizes before uploading, and Photobucket uploading runs at the same speed as any other, including Picasa, which you could fill with a few big pics.

A free Photobucket account only has half the capacity of a Picasa Web account.

Picasa allows a single image of up to 20 MB before it gets upset, while Photobucket's resizing will kick in at either 1 MB or when images exceed 1024x768 .

Although I said I wouldn't, I did try and find some article about Photoshop and file sizes... and as I suspected it was a waste of time.

I don't think I've come across such examples of snobbery and misinformation as I found here. It's like another subculture of the "Windows is evil" and "Google is evil" camp.

For example, there appeared to some interesting comments regarding bloat in Photoshop's jpg saves, and the writers began to waffle about issues relating to sampling.

But...

As I read on, I discovered that the mouthiest experts did not even own Photoshop, so couldn't have been using it, so their opinions were just that - opinions.

I then followed another who began by describing the "broken" parts of the Photoshop jpg saving operation.

But...

Reading on, found that he was all but kicked out of the group when he stated he didn't have Photoshop and would use it for million dollars, that every image that passed through it was degraded, and that everyone should use the better alternatives that had overtaken it years ago.

However, when challenged to reveal what he was using and what these better alternatives were, his reply was just to point to a web-based list of all the photo-editors available (would you believe it was actually just the Wikipedia list page! ).

I stopped reading at that point.

I had started merely because the items I had begun with made sense at their start, even though the subject was Photoshop's own file format and other more advance file types than jpg, but I thought they might have led so some related issues or clues.

While they didn't, I still have a suspicion that Photoshop is using a different engine to create its jpgs when compared to IrfanView, and this is somehow affecting how Photobucket handles it - I just don't seem to be able to dig deep enough into the guts to prove it.

Maybe the anti-Photoshop brigade are right, and it is using a clunky old compression routine that upsets the bucket - I'll have to see if I can dig up a jpeg analyser, and see what happening in the normally hidden guts of the various files.

On a slightly different tangent re Photoshop, I had a chap venomously complain that I had linked an image from my account on another forum that took him back the PB site.

He was very angry that his grand-daughter had access to such filth.

Even when I pointed out PBs rules and guidelines he refused to see sense.

The 'filth'............ he happened to come across a picture of Colin and Justin on Photobucket!!