How many bits are in a file, really?

[Soapy Sam]

Looking at some image file data, (in Faststone Image Viewer), I see file size descriptions like this-
" 20.5 Megapixels / 18056 kiloBytes"

Assuming this means 8-bit bytes, that's 144,448 kilobits or 147,914,752 bits (1024 bits in a kilobit).
147914752 / 20498880 is about 7.2

-which seems to be 7.2 bits per pixel...which makes no sense at all, for several reasons.

The example is an uncompressed raw file, but I get similar numbers with JPGs.

If a jpg is an 8 bit per channel file , it should be a 24 bit / pixel file, at least. It may be more.

So what am I doing wrong?

[xpatUSA]

Looking at some image file data, (in Faststone Image Viewer), I see file size descriptions like this-
" 20.5 Megapixels / 18056 kiloBytes"

Assuming this means 8-bit bytes, that's 144,448 kilobits or 147,914,752 bits (1024 bits in a kilobit).
147914752 / 20498880 is about 7.2

-which seems to be 7.2 bits per pixel...which makes no sense at all, for several reasons.

The example is an uncompressed raw file, but I get similar numbers with JPGs.

If a jpg is an 8 bit per channel file , it should be a 24 bit / pixel file, at least. It may be more.

So what am I doing wrong?

Makes more sense when you know what it is:

Bits per Pixel (bpp) is a useful metric which indicates the amount of compression in a compressed file, typically a JPEG. It is explained here:

https://stackoverflow.com/questions/...bits-per-pixel

... the amount is usually fractional and it has nothing to do with bit depth - a common misunderstanding.

JpegSnoop lists the metric about halfway down the page in their app:

https://jpegsnoop.en.softonic.com/

Well worth down-loading, tells you much more than ExifGUI . . .

[Manfred M]

A file contains more than pure image information. It will have additional information including header information that contains image metadata. The bit-depth of a file will also impact file size; I commonly use 16-bit data in my files.

Another issue is the definition of a kilobyte. Is it 1024 bytes (2^10) or is it 1000 bytes? Hard drive manufacturers often use the second approach, which makes the drives sound higher capacity than they really are.

A third issue is compression; we generally don't worry about compression if a lossless algorithm is used versus a "lossy" one. We won't necessarily know when the software manufacturer uses lossless compression.

[Soapy Sam]

A file contains more than pure image information.

Indeed. So I would expect the result of dividing the listed bits by the listed pixel count to be less than the bit depth and quite possibly a fraction, but this much? Assuming the actual bit depth figure is 24 (at minimum), is the non-pixel overhead big enough to reduce 24 to 7.2? (Or 1.9 as I get in one file). That suggests the non-pixel data is far larger than the pixel data, which would seem unlikely.

Another issue is the definition of a kilobyte. Is it 1024 bytes (2^10) or is it 1000 bytes? Hard drive manufacturers often use the second approach, which makes the drives sound higher capacity than they really are.

Indeed they do. I assume 1024 though.

A third issue is compression; we generally don't worry about compression if a lossless algorithm is used versus a "lossy" one. We won't necessarily know when the software manufacturer uses lossless compression.

Here you are getting close to my reason for asking. I'm an Olympus user. I'm curious about whether ORF files are losslessly compressed or not.

[Soapy Sam]

Makes more sense when you know what it is:

Bits per Pixel (bpp) is a useful metric which indicates the amount of compression in a compressed file, typically a JPEG. It is explained here:

https://stackoverflow.com/questions/...bits-per-pixel

... the amount is usually fractional and it has nothing to do with bit depth - a common misunderstanding.

If the file contained only pixel data and was uncompressed, the two figures should be the same , or so it seems to me.

JpegSnoop lists the metric about halfway down the page in their app:

https://jpegsnoop.en.softonic.com/

Well worth down-loading, tells you much more than ExifGUI . . .

That is interesting, though as I said above, it's really raw files I'm interested in.

[Manfred M]

Here you are getting close to my reason for asking. I'm an Olympus user. I'm curious about whether ORF files are losslessly compressed or not.

I don't know about Olympus, but as a Nikon user I get to set whether the raw data is compressed or not. In fact I have six settings; no compression (12-bit or 14-bit), lossless compression (12-bit or 14-bit), lossy compression (12-bit or 14-bit).

If you are looking at 8-bit JPEG, 100% guarantee that you are getting lossy compression as this is part of the JPEG standard. For JPEG on Nikon I can choose three different levels of JPEG compression (basic (maximum compression), medium quality and high quality).

[xpatUSA]

Assuming the actual bit depth figure is 24 (at minimum)

I wish people wouldn't do that. The said data is 8-bit not 24. Photographic loose terminology strikes again. Manfred's "16-bit" descriptor is correct - 48-bit is not.

The data for a raw image is arranged as an array - four columns of 8-bit values (or 12-bit or 14-bit or even 16-bit). The data for an RGB image is also arranged as an array - often three columns of 8-bit values. That data is not arranged as an array of 24-bit values somehow stuffed into 32-bit double-words ...

Foveon is guilty of similar double-speak: their 4.7MP images are touted as "14MP" ... we all know why, so please don't educate me in that regard ... "most of us" don't care anyway.

[xpatUSA]

If the file contained only pixel data and was uncompressed, the two figures should be the same , or so it seems to me.

True but, unfortunately, such a file is rare enough to be non-existent and should be discounted from your thinking, I reckon.

BTW, I just looked at a BMP file and it scored 22.868 bpp ...

[Soapy Sam]

I wish people wouldn't do that. The said data is 8-bit not 24. Photographic loose terminology strikes again. Manfred's "16-bit" descriptor is correct - 48-bit is not.

I agree terminology is varied. I would say "8 bits per channel", rather than "an 8 bit image", but as Manfred says, the hard drive makers are just as bad.

[dje]

Looking at some image file data, (in Faststone Image Viewer), I see file size descriptions like this-
" 20.5 Megapixels / 18056 kiloBytes"

Assuming this means 8-bit bytes, that's 144,448 kilobits or 147,914,752 bits (1024 bits in a kilobit).
147914752 / 20498880 is about 7.2

-which seems to be 7.2 bits per pixel...which makes no sense at all, for several reasons.

The example is an uncompressed raw file, but I get similar numbers with JPGs.

If a jpg is an 8 bit per channel file , it should be a 24 bit / pixel file, at least. It may be more.

So what am I doing wrong?

RAW files are usually 12 or 14 bits per pixel. So it appears that the RAW file you are looking at is compressed. Irrespective of whether the compression is lossy or lossless, you will get a reduction in file size. The reduction is likely to be greater for lossy compression.

Dave

[tclune]

I am a Nikon shooter, so that is the kind of camera that I know. Nikon's NEF files can be lossy compressed. Indeed, 3xxx and 5xxx Nikon cameras ONLY support lossy-compressed NEF files. Bill Claff is an excellent source of info on this. His most recent (a couple years old) data can be found here. Notice that the 3xxx NEF formats, which are nominally 12-bit data, contain only 769 distinct values after decimation. The 5xxx files, nominally 14-bit, contain 3073 distinct values after decimation. The way the decimation works is by combining different values into one entry. The darker values are not combined -- Claff's tables indicate the darkest value that gets combined with its nearest neighbor. As the data gets brighter, the lumping together gets increasingly more draconian.
One consequence of this that I have not been able to think through is that ETTR on such a camera is shifting the image into the maximally-decimated part of the spectrum. My suspicion is that this may make ETTR counterproductive on these cameras, but I am unable to say that with confidence.
It should be noted that all Nikon cameras offer decimated raw data, so you may have your camera set to one of those options even if you have a higher level Nikon camera.

[xpatUSA]

I am a Nikon shooter, so that is the kind of camera that I know. Nikon's NEF files can be lossy compressed. Indeed, 3xxx and 5xxx Nikon cameras ONLY support lossy-compressed NEF files. Bill Claff is an excellent source of info on this. His most recent (a couple years old) data can be found here. Notice that the 3xxx NEF formats, which are nominally 12-bit data, contain only 769 distinct values after decimation.

Indeed, I remember that 683 values applied to my D50, long ago ... from a 2006 document by the very same Bill Claff.

[Soapy Sam]

RAW files are usually 12 or 14 bits per pixel. So it appears that the RAW file you are looking at is compressed. Irrespective of whether the compression is lossy or lossless, you will get a reduction in file size. The reduction is likely to be greater for lossy compression.

Dave

Yes. It seems ORFs use lossless compression. They also contain an embedded 3200x2400 jpg preview as well as a 640x480 thumbnail , all wrapped in a TIFF-style container.
One complication I realised yesterday is that in Faststone Image Viewer Settings panel, I had chosen (or perhaps it is the default) the fast opening method, which basically opens the embedded JPG, but shows it as a 3200x2400 ORF. Using the "Full " setting, it shows a 5400x3900 appreox image.

The same 3200x2400 jpg is embedded in the 80MP sensor shift high res files.

All very interesting.

[Soapy Sam]

Indeed, I remember that 683 values applied to my D50, long ago ... from a 2006 document by the very same Bill Claff.

I think it's usually easier to find information about Nikon / Canon tech, simply because they dominate the users market. Getting the same info about smaller manufacturers can be harder. Forums like this are generally a good place to start.

[Manfred M]

Step 1: Multiply total number of pixels by the bit depth of the detector (16 bit, 14 bit etc.) to get the total number of bits of data. Step 2: Dividing the total number of bits by 8 equals the file size in bytes.
Step 3: Divide the number of bytes by 1024 to get the file size in kilobytes.

That is not neccessary correct.

The data could be compressed, either lossless or lossy (I always use lossless compression) and ignores header data.

[xpatUSA]

Originally Posted by lillyann Step 1: Multiply total number of pixels by the bit depth of the detector (16 bit, 14 bit etc.) to get the total number of bits of data. Step 2: Dividing the total number of bits by 8 equals the file size in bytes.
Step 3: Divide the number of bytes by 1024 to get the file size in kilobytes.

That is not neccessary correct.

The data could be compressed, either lossless or lossy (I always use lossless compression) and ignores header data.

Agreed. Apologies to Lilly-Ann but it is incorrect most of the time. Might be close-ish for a file of type BMP but we don't see many of those any more.

Plus, as mentioned earlier, my raw files have a full-size embedded JPEG and lots of camera-specific meta-data, not just EXIF.

Files of type DNG can be much worse if they legitimately contain both the DNG image data plus the original raw data plus the JPEG plus anything else the creating software has thrown in ...

... and then there are animated GIFs.

[Soapy Sam]

Step 1: Multiply total number of pixels by the bit depth of the detector (16 bit, 14 bit etc.) to get the total number of bits of data. Step 2: Dividing the total number of bits by 8 equals the file size in bytes.
Step 3: Divide the number of bytes by 1024 to get the file size in kilobytes.

Lilyann, It was doing a similar calculation, in the opposite direction, which returned an answer like 6.3 bits per pixel, which led me to start this thread. As others have pointed out, there are complications.