Capping the Filesize of Image Conversions

I often have to upload images to a website that has a restriction on file size of 400k.

I have to guess what type of reduction in quality or resizing i need to do to get it under the maximum size. I have to do this file by file.

It would be really helpful if there was a checkbox that said "limit size to:" and let you type in a size.

Then I could do this on a batch of images and let DOPUS keep the quality or size as high as it could and still be under the required limit.

I've highlighted the area where a new checkbox would be really helpful. I hope you will consider it.

I think that could be done using scripting without needing any new functionality.

I have no idea where to look. Can you point me in the right direction?

The "Opus Manual" menu at the top right of the forum has a link to the main three scripting sections, if that's what you need.

The script could run the image conversion command at X quality, keeping the original file unchanged, then check the size of the result and re-run it at a lower quality (and/or resolution), until the size is under the required limit.

Using a loop seems like it would be awkward in batch environment of multiple photos and could be time consuming. Also you wouldn't want to "step down" the size when using a lossy format or by the time you got to your desired size the picture would have lost a ton of details and would be pixelated. So you would have to keep track of the results and keep trying off a master.

I would think that mathematically it would be possible to ascertain a size estimate given the dimensions, compression settings and dpi. I have no idea how to pull that off however...

Is there a way to ascertain the projected size before converting it? Perhaps with a function?

There's no other way you can do it. You cannot predict how large a JPEG will be without making it. JPEG compression is really fast so it would not take long either.

Re-read what I suggested. You keep the original and always use that as the source image.

Not that I know of, at least. Compression isn't predictable like that.

Is it possible for the conversion function to perform the conversion without actually writing it to disk and instead just count up the bytes it would have written and return it to the script?

This would cut disk i/o down to just reads and avoid having to deal with the files.

I realize it's a "feature change" request here. I just don't know if I'm going to be able to code something like this myself.

The disk I/O when converting a JPEG is going to be next to nothing. No reason to worry about that.