I think you need to step back a bit! Yes, Paul is pretty sharp about most photography stuff. And, yes, he helps a lot of people. Almost always with a BIG dose of snark. What makes him think that this particular UHH'r knows or has seen this subject here before? Or a lot of other subjects covered or not here on UHH. Accusing him of being grouchy is not simply an accusation, it's simply fact!
Some people (me) don't have the head for this stuff and struggle along trying to make some headway. Snark, from you or Paul does NOT help! The best response to a question here would be no response at all, unless the snark can be held to a minimum!!

Yes, but the explanation is IS NOT simple.

CHG_CANON is correct when he says that there is no direct correlation between file size and image size, with the caveat of saving files using compression, lossy or lossless. JPEG is a lossy compression file format.

Now a bit of a technical discussion

The very basic process for saving a JPEG is:

1) Original image is broken into image blocks (8x8 blocks)

2) Via the Discrete Cosine Transform, transform the image from the spacial domain to the frequency domain and quantize the DCT coefficients. The level of quantization determines the amount of compression.

3) Strip the high frequency content (luminance and hue) from the image. The content removed is, generally, not noticeable by most viewers.

4) data compression (Huffman encoding)


So the image loses information and is highly compressed in the frequency domain resulting in much smaller files for a given image size. Both, the frequency content and the amount of compression (user selectable) determines the file size (not image size). For example, if you were to save a pure white image with the same image dimensions and same compression factor as your flower image was stored as, the white image would be smaller because there is no high frequency content in it.

When the image is viewed, the software decodes the remaining info in the jpeg file and displays the lossy image. In most cases, the information lost is not perceptible to the viewer.

So, why work in the frequency domain? Representing an image in the frequency domain requires MUCH less data than in the spacial domain. If you have a technical background, you’ll know that time series such as a sine wave can be described with much less data in the frequency domain (via the FFT) than in the time domain. JPEG’s use this same advantage.

This is why JPEG file size and image size DO NOT correlate!

Now back to the practical discussion.

There is 110MB of image data compressed into your 1.6MB JPEG file.

When you load your JPEG into Photoshop, Photoshop decodes the compressed image and stores it internally as 24-bit pixels, uncompressed (8 bits of R, 8 bits of G and 8 bits of B). In your case, your 1.6MB file is expanded to an uncompressed 110MB file internally. That allows PS to manipulate each individual pixel in the image. So here is a basic calculation on what the image size in bytes should be.

(7379 x 5021pxl) x (24 bits/pxl) / (8 bits/byte) = 111MB

Which corresponds to PS’s doc size.

AND, if you save your file as an uncompressed TIFF file, the resulting file size is 111 MB.

If you convert your image bit depth from 8-bit to 16-bit, the resulting TIFF is 222MB.

Hope this helps,
Mike

PS: Feel free to PM me if you have any specific questions about my response.

My apologies. In providing a reasonable thorough answer to the OP, I needed to define how such a large amount of data in compressed into such a small file without just saying “it’s compressed”. Nor did I want to get into any of the data processing behind the process.

The implication of 2) is that the RGB data representing the image is rearranged into something much more efficient for processing. The DCT is just the vehicle used for that purpose.

Steps 2, 3 and 4 are just methods of data reduction and compression.

How many times?

How many times do we have to explain the single most important aspect of a pixel-based digital image is the pixel resolution?

How many times?

How many times do we have to explain the file size in bytes (MB - megabytes) has nothing to do with the print / display sizes of a pixel-based digital image?

How many times?

Your attachment is 7379x5021 pixels wide & tall - this is the 'pixel resolution'. Yep, it will fill your screen. The fact you can attach and store the file to an UHH post tells you next to nothing, other than the file size is at (or less) than roughly 20MB. A quick detach and we see the filesize, on disk, 1.53MB.

What we can't see is all these immense file sizes you're quoting. Given you're referencing email attachments, we're left thinking your quoted PS observation are erroneous, as they're unrealistic. You should double-check and reconsider these PS observations.

The likely issue is that PS is 'reading' the hard-coded nonsensical 300 dpi value embedded into the JPEG. How many times? How many times do we have to say: there are no dots in a pixel based image? None.

CHG_CANON does an incredible job helping folks with their various problems, especially those who have made an honest effort to solve them themselves. Computers and their programs/tools can be tricky at times, but being determined to do one's homework before asking others to do it for you goes a long way to getting help when it really is needed.

You haven't done your homework...LR easily solves your 'getting the file size down' issue if you just follow the Export dialog. UHH has plenty of self-help topics, as CHG_CANON has so kindly pointed out, that address a good many 'how to' tools for using UHH.

We should be grateful for CHG_CANONs help when needed, not accuse him of being grouchy, especially when someone hasn't done their homework. His response to your inquiry is valid and true.