| Author | Thread |
|
|
04/12/2011 04:28:01 PM · #1 |
Something unusual happened recently... I saved my image for DPC from CS5, just as I usually do... save for Web & Devices. I specified that the file should be optimized to 300 Kb. When I came to upload the image to the site it was rejected because it was 301 Kb. Bear said he had the same problem at least once recently. Of course one can work around this by specifying a file of 295 KB... but I wondered if anyone else had experienced this and also if anyone had any insights into why it would start happening all of a sudden..
Thanks.. |
|
|
|
04/12/2011 04:36:30 PM · #2 |
Someone else may be able to provide a technical reason behind this, but I have experienced it before. I'd bet it depends on each image, but again, I can't explain any specific, technical reason as to why it happens.
I, like you, just set it to 295k and moved on.
ETA: I know there are different ways to read how big a file is. For example if a file is 300k in one program (eg: CS5), it may actually be 303,454,011 bytes on disk. Then DPC may be reading the 303,xxx,xxx and saying it's too big. Make CS5 say 295k and the actual size is 299,024,353 bytes and DPC approves. Make sense? I hope so because that's as technical as I'm getting today!
Message edited by author 2011-04-12 16:40:55. |
|
|
|
04/12/2011 04:57:23 PM · #3 |
| I don't know the gory details, but what I suspect happens is that Ps optimizes for 300kB worth of image data. it may not be properly accounting for the additional file space required for the file header and metadata. Best practice has always been to target a slightly smaller size. As I recall I was using 297 and not having a problem with it. Haven't worried about it in a while though. :-P |
|
|
|
04/12/2011 05:02:24 PM · #4 |
| this happens to me in lightroom on occasion where i set the filesize to 300kb max and it will make it like 310 or something. |
|
|
|
04/12/2011 05:09:59 PM · #5 |
Originally posted by kirbic:
I don't know the gory details, but what I suspect happens is that Ps optimizes for 300kB worth of image data. it may not be properly accounting for the additional file space required for the file header and metadata. Best practice has always been to target a slightly smaller size. As I recall I was using 297 and not having a problem with it. Haven't worried about it in a while though. :-P |
The way it was explained to me, one of the reasons for using "save for Web & Devices" rather than "save as" jpg, was that the former stripped the metatdata out of the file, leaving the full 300 Kb for the image and resulting in less image compression. But I don't know that for sure. I just get curious when something works fine for years and then no longer works all of a sudden...:-) . The only thing I can think of that I have changed around the time this happeneed is that I started using NIK tools (HDR and SEP). And if it is that that causing it, it's a small price to pay for such a great set of tools! |
|
|
|
04/12/2011 05:26:29 PM · #6 |
| When you "Save for Web and Devices" you can choose to strip metadata, or not. In recent versions, there may be additional flexibility. I choose to leave my metadata in place, because the small change in file size is not a big worry, and I would like folks to see the settings if they are interested. Now, because of the darn GIF overlays here, that's become pretty much a moot point... |
|
|
|
04/12/2011 05:27:58 PM · #7 |
With JPEG a variable compression algorithm, it is impossible to estimate the final file size down to the byte before the file is actually processed. Remember that "300KB" is a "rounded" number, just as a "kilobyte" is 1024 bytes, not a thousand. If your file goes to "300,001" bytes you'll go over the limit.
The optimize for file size feature is probably only accurate to ±3KB or so.
On the rules page, it will tell you the exact number of bytes you're allowed; use File > Properties (PC) or File > Info (Mac) to see exactly how big your file is in bytes and compare. |
|
|
|
04/12/2011 09:15:13 PM · #8 |
Thanks for the ideas about what is going on. I'm pretty computer savvy. Back in the 60's I wrote code for some specialized applications in machine level language, so I'm probably expecting a level of precision in this task that I shouldn't be. Basically I'm just amused that it could work so well for over 2 years, with me using the exact limit DPC was specifying without having the file exceed that size, only to have it start happening all of a sudden. But it's no big deal in the overall scheme of things!!
|
|
|
|
04/13/2011 02:18:52 AM · #9 |
Originally posted by kirbic:
When you "Save for Web and Devices" you can choose to strip metadata, or not. In recent versions, there may be additional flexibility. I choose to leave my metadata in place, because the small change in file size is not a big worry, and I would like folks to see the settings if they are interested. Now, because of the darn GIF overlays here, that's become pretty much a moot point... |
Not really. The gif file is really easy to defeat. Just use an ad-blocker and name the gif as the blocked file.
Of course I've not tried this in a while and Langdon may have gotten a little more devious. I any event this is why
I don't pay for membership any more. I used to take a look and always appreciated it when photogs left their meta-data in
so I could get a feel for what they were doing technically. Now I don't even bother looking any more. |
|
Home -
Challenges -
Community -
League -
Photos -
Cameras -
Lenses -
Learn -
Help -
Terms of Use -
Privacy -
Top ^
DPChallenge, and website content and design, Copyright © 2001-2025 Challenging Technologies, LLC.
All digital photo copyrights belong to the photographers and may not be used without permission.
Current Server Time: 11/06/2025 08:01:55 AM EST.
