JPEG economy: resize or lower quality?

[Britical_Hit (Steve Downing)]

Can you please tell me whether it’s better to reduce image size or reduce quality when rendering to JPEG (i.e. for animations)? Obviously the goal of both is to reduce storage demand for the output image.

You’re no doubt familiar with the two options for JPEG renders, but here’s a visual reminder all the same

Concierge Render, my go-to cloud renderer only (seems to) allow the option to reduce image size, as shown in the image below. Switching between the resolution options produces a change in the quoted image size in pixels in the two number boxes.

I assume they more or less know what they’re doing, so is it right to assume re-sizing JPEG’s is the smart Blenderist’s option for skimping on file size?

Thanks!

[Hunkadoodle]

I don’t want to assume anything, but I’ve read about the XY Problem, and I’d like to get some more info before trying to answer your question. You are asking for the best (or better of two ways) to reduce file size for JPEG renders for an animation, but there are so many variables and questions that would go into getting to the place where we know enough to help you, the best I have right now is “it depends.”

But instead of talking about the differences between those two possible courses of action, why don’t you let us know what your requirements are, your constrains are, your approach is, and your expectations are.

Maybe that will explain why you’ve landed where you are and the two possible ways ahead you’ve given yourself.

[Britical_Hit (Steve Downing)]

Thanks for your reply, Hunkadoodle.

Because weighing up file size management vs. perceived quality of image is going to be largely subjective, I suspect there’ll be a limit to how XY we can be about this particular issue. But I’ll at least try to meet you half way

Here’s an image (old project) I just rendered twice:

I did so at 1920x1080 (default) resolution each time. However, the first quality settings I used (JPEG, obviously) were 100%. Resulting file size: 1.43MB. For the second render I used the default 90% quality settings. Resulting file size: 477kB.

That’s a massive saving and I’m happy with the result at 90% quality.

Thus, I ask myself, why are the default settings geared to reducing image quality (as opposed to size) in Blender, whereas the only option for file size management in Concierge (for example) is to reduce image size?

I’ll ping Concierge a query about this, too. IIRC, they have an online chat facility on the website. I’ll post any reply I get from them on this thread.

[Hunkadoodle]

Thanks for the reply, @Britical_Hit. I think I see where you are coming from. It sounds like this is a general question of why Blender and Concierge do things a certain way rather than what is the best approach to the same thing (reducing file size).

My response (and this is just Josh’s take), would be that processing power/time is more expensive than storage space. Ergo, Blender and Concierge assume you budget with processing power/time in mind before you budget for storage space - especially if you are spending the processing power/time to render into an initially lossless format (internal image system vs. lossy JPEG compression). Both rendering a file with smaller dimensions and saving to a lossy format will achieve smaller file sizes, but you are paying for render time, not file size.

Both approaches will achieve the same end state - a smaller file size at a lower quality, but you will pay more for the higher higher resolution render (regardless of output file format) because the quality of the JPEG lossy compression has no bearing on price - everything else being equal, only resolution affects price.

That’s what I meant by the XY Problem. You are asking about smaller file sizes, but you stated “JPEG, obviously” as if that is assumed to be the best choice when you haven’t stated why you are using JPEG in the first place.

I understand that there are limits on money, time, storage space, output quality, etc. What you are trying to achieve at the end drives the requirements for what you start with in the beginning. Without knowing the end goal, it is difficult to say why you would go one way rather than the other. Know what I mean? You are asking about saving on file size when that is probably the cheapest, least important factor in most rendering projects. You can get hard drives to store data as low as 1.4¢ per GB.

Edit:
I do want to caveat my above response with the acknowledgement that the differences between an 8-bit per channel (bpc) 1.4MB JPEG file and a 32 bpc 30MB Multilayer EXR file are more than just storage space. The ability to edit a file or sequence is hindered, the time it would take to render that out as a final animation would be longer, application support for different file types is not the same, etc. But this is where knowing the background would help.

Lastly, to maybe answer your original question, some online render farms don’t offer some settings in their UI because they read them from the file. I can’t speak for Concierge, but you might not have the option post-upload because it reads the setting you chose and saved into your file prior to uploading.

[CarlG]

The simple economics of using jpg for rendering, especially animations: NEVER USE IT

[sundialsvc4]

My frank recommendation is that you should use OpenEXR for your “final print” and MutiLayer OpenEXR for all of your intermediate files throughout your pipeline.

This particular file format was designed – by Industrial Light and Magic, no less – as a data-file format. Its purpose is to capture the numbers. Exactly. No loss. No encoding. No [lossy] compression. One file per frame. (And, for “MultiLayer,” each named “layer” of data stored separately in the same file.)

(External hard drives and SSDs are very big and very cheap now … splurge.)

Take your project all the way to the end in this format … saving every single intermediate [MultiLayer OpenEXR] file along the way and keeping very careful notes. "Now, you have the precious data." Lots of big files of floating-point numbers.

Only then, start thinking about your various “deliverables” using that data, and the hardware targets for which they are suited. You can easily create several blend-files which will manufacture appropriate files from the same pristine, OpenEXR source. Only then do you think about “physical issues” such as file-format, compression, or color-mapping. And you can make as many such decisions as you need to, each one independent of all the others because each one draws from the same data source.

[Bullit]

Like other have said, do not use jpg. At least use .png

[Britical_Hit (Steve Downing)]

This has been most illuminating, thanks. I don’t think I’m at a stage where I can take any one reply and confidently slam the Solution button on it, but you’ve got me at least considering what file format I should progress onto, given that the consensus is unambiguous vs. jpg (i.e. don’t!) I’ll wander over to YouTube and do my homework on the various file types.

I had my fingers burned a while back buying an external hard drive that was the embodiment of buy-cheap-buy-twice (it died) so it’s been some time since my thoughts have drifted in that direction. However, I can summon enough open-mindedness - and probably the pennies - to reconsider on that front too.

I can see how this discussion has suffered from XY syndrome, but it’s been useful to me and hopefully at least interesting to others, too.

EDIT: It’s also got me to reconsider my approach to using Concierge. If/when I migrate to anything else than .jpg, then the compression question automatically becomes moot - I think?

[sundialsvc4]

These days, you can buy multi-terabyte SSD drives “for a song” at any office-supply store. (Like: two or three terabytes for around $150…)

Do your project start-to-finish in ML-OpenEXR, then make your deliverables in whatever format(s) are called for: one at a time, and always from the same source … never from another deliverable.

You’ll also very quickly come to appreciate “one file per frame,” because this means that you can re-start a render job at any point. It’s also a good idea to “request more [cheap …] layers than you think you’ll need,” because if they’re just sitting there in memory after a time-consuming render cycle, you may as well go ahead and write them out. (Note that some layer-types require extra work, so these should be requested only if you really do need them.) But these things are free and often very useful down the line: Shadow, Z-depth, object-ID …