Filesize (I know, I know......)

[Fritz_H]

Hi,

As far as I know, a RAW-File contains "all" colors, all details etc. since its (perhaps compressed but) lossless.
My mind refuses to understand why a RAW-File is significantly smaller than a photo file.

example: same picture: 1x RAW and 1x Photo (no editing whatsoever done, just developed and saved): almost 20x bigger!

I know, some of you will try to explain to me, that a 32Bit ROMM-File needs more space because of... (...this and that...).
True - but this makes me wonder even more: what kind of Voodoo is Canon using, to squeeze all this (similar amount) information into a much smaller RAW-File?

Sometimes the Forum answers that Affinity adds some "speed-optimization"-Data to the file.
If that is true: please add a "compress"-option to the "save as"-dialog to remove this "extra-data" and perhaps even add some additional lossless compression? (perhaps using HW-acceleration :-) )
I do not care if opening a file takes one second longer - but it helps to speed up data-transfer and backup.

Thanks!

[Ron P.]

Affinity Photo is not alone on bloating file sizes. In my screenshot it shows a comparison of Affinity Photo (aphoto), Corel PhotoPaint (cpt), and Corel PaintShop Pro (pspimage).

However it does appear, Affinity's files are somewhat larger.

[Alfred]

1 hour ago, Fritz_H said:

Sometimes the Forum answers that Affinity adds some "speed-optimization"-Data to the file.
If that is true: please add a "compress"-option to the "save as"-dialog to remove this "extra-data" and perhaps even add some additional lossless compression? (perhaps using HW-acceleration :-) )

‘Save’ will retain extra data until you reach a certain threshold but ‘Save As...’ should (as far as I’m aware) discard the extra data immediately.

[walt.farrell]

2 hours ago, Fritz_H said:

I know, some of you will try to explain to me, that a 32Bit ROMM-File needs more space because of... (...this and that...).
True - but this makes me wonder even more: what kind of Voodoo is Canon using, to squeeze all this (similar amount) information into a much smaller RAW-File?

A RAW file typically contains 10 or 12 bits per pixel.

A developed file, in RGBA/8, would contain 8 bits per pixel for the R channel, 8 more for the G channel, 8 more for the B channel, and 8 more for the A channel. Per pixel. So that's 32 bits per pixel, or approximately 3x as much data as the RAW file requires.

If you go to RGBA/16 (typical for developing a RAW file in Photo), you get 16 bits per channel per pixel, or 64 bits per pixel, approximately 6x the space the RAW file requires.

There's a Spotlight article that may help: https://affinityspotlight.com/article/raw-actually/

[John Rostron]

33 minutes ago, walt.farrell said:

A RAW file typically contains 10 or 12 bits per pixel.

I always understood that was bits per pixel per channel.

John

[v_kyr]

3 hours ago, Fritz_H said:

but this makes me wonder even more: what kind of Voodoo is Canon using, to squeeze all this (similar amount) information into a much smaller RAW-File?

Voodoo? - Na by no means, read and try to understand what a RAW file format is, what it is made of and how it is processed, then you know why!

[Fritz_H]

5 hours ago, Alfred said:

‘Save’ will retain extra data until you reach a certain threshold but ‘Save As...’ should (as far as I’m aware) discard the extra data immediately.

With a completely new file (fresh after RAW-Development) every "save" is a "Save as".

[Fritz_H]

3 hours ago, v_kyr said:

Voodoo? - Na by no means, read and try to understand what a RAW file format is, what it is made of and how it is processed, then you know why!

"read an try to understand.."  ?   Not my job.
Just look at the Screenshot provided by "Ron P":  Serif is wasting space. 
Obviously it IS possible to put ALL Color-Info + ALL Details into a SMALL File (RAW).
Why not use the same "Voodoo"-method used in RAW for the Image-Info of the Photo-File?

[walt.farrell]

23 minutes ago, Fritz_H said:

Why not use the same "Voodoo"-method used in RAW for the Image-Info of the Photo-File?

Because then you don't have an actual image. You just have RAW data.

24 minutes ago, Fritz_H said:

"read an try to understand.."  ?   Not my job.

Sorry, but if you want to object to the file size then it is your job to understand what a RAW file really is, and then you'll know why the other file formats are larger. Or you can just trust all of us when we tell you there's a reason, and that what you're suggesting won't work.

[walt.farrell]

4 hours ago, John Rostron said:

I always understood that was bits per pixel per channel.

No. RAW files don't have channels, per se.

[John Rostron]

2 hours ago, walt.farrell said:

No. RAW files don't have channels, per se.

No, but they have four sensors per pixel (RGGB).

John

[Pšenda]

2 hours ago, John Rostron said:

No, but they have four sensors per pixel (RGGB).

Wow, try to calculate out how many pixels you have of the camera sensor, and how many pixels it will make into an image.

When develop RAW (sensor) data, the pixels data of the sensor is recalculated so that completely new (imaginary) four pixels with RGB(A) values are calculated from the mentioned RGGB matrix (Bayer mask).

It's a bit of a customer scam :-)

P. S. As you write, it only worked with Sigma's Foveon chips.

Edited April 2, 2021 by Pšenda

[walt.farrell]

2 hours ago, John Rostron said:

No, but they have four sensors per pixel (RGGB).

No, they have a matrix of sensors and each pixel receives a contribution from 4 sensors. I think there's still a total of 10-12 bits (sometimes a few more, depending on the camera) per pixel (not per sensor).

The "RAW, actually" article I mentioned above covers all that, as I recall. (But I haven't read it for awhile.)

[Pšenda]

13 hours ago, Fritz_H said:

Why not use the same "Voodoo"-method used in RAW for the Image-Info of the Photo-File?

Because the Affinity file format is not optimized for the smallest possible size, but as has been repeatedly stated here on the forum, for the most efficient and fastest data processing, including the possibility of sharing one format by all applications. Unfortunately, this way of storing data is significantly more capacity-intensive.

In contrast, RAW file formats were designed for maximum efficiency in terms of size, as they needed to store as many images as possible in until recently very small data cards.

[fde101]

On 4/2/2021 at 7:34 PM, walt.farrell said:

No, they have a matrix of sensors and each pixel receives a contribution from 4 sensors.

It's a bit more complicated than that, and it can vary depending on the type of sensor.

Most image sensors are inherently monochrome.  Left to itself, you would get a monochrome image at the full resolution of the sensor.

To support color imaging, a color filter array (CFA) is placed in front of the sensor that is a set of tiny color filters, blocking the "wrong" colors from reaching each photo site (sensor element / pixel), such that each one only sees one color (usually red, green, or blue, though there have been experiments with including a few white pixels or other colors on the sensors in various configurations).  The most typical pattern is the "bayer pattern", which in a 2 x 2 grid of pixels includes one red, two green and one blue pixel - but other arrays have been used (Fuji in particular has experimented with a number of them, including non-rectangular configurations).

In order to demosaic the RAW image into RGB data at each pixel, the color that pixel holds (due to the filter) can be used directly, while the information for the other two colors needs to be interpolated from surrounding pixels.  The specific interpolation and various other aspects of the algorithms involved can produce slightly different results, and is one of the key reasons that different RAW processors can produce different results when processing the same RAW image: some do better than others and it can vary depending on the nature of the image.

Another type of sensor is a so-called "direct color" sensor, such as the Foveon sensors that Sigma uses on many of their cameras.  These sensors work on a different principle and actually do capture multiple channels at each photo site, though the captured channels are not actually RGB, but rather require a special transformation to become RGB data.  As a result, these sensors still have a RAW format, but each photo site is represented by multiple channels as it would be with a developed RGB image - a transformation is then used to turn it into RGB when it is being developed.

Sigma likes to confuse matters by making bogus claims about their resolution in order to capitalize on this difference.  If they had 4 million photo sites (a 4 "megapixel" camera) they would call it a 12 megapixel camera as they are capturing 3 data points for each photo site.  The developed resolution of the image would still be that of a 4 megapixel camera, and the resolved resolution, while certainly higher than that of a 4 megapixel CFA-based camera, would not be three times as high (unless the RAW data from the CFA-based camera was VERY badly developed - a bayer pattern sensor can theoretically achieve a resolved resolution of about 70% of its physical megapixel count, while a direct color sensor such as a Foveon can in theory achieve 100%).

Some cameras (particularly in the video/broadcast world) have also used multiple sensors to support multiple colors, though this has become considerably more rare by now.  These are typically marketed as "3CCD" or "3MOS" sensors; they use a prism to split the light three ways, sending each to a sensor with a single color filter in front of it, so that one sensor captures all of red, another all of blue, and another all of green.  This configuration produces RGB data directly, so the output is already "developed" and the camera has no true "RAW" format in the way we tend to think of it today (or you could argue that the raw format of such a camera is in fact the already-developed image, minus any exposure/white balance corrections and the like).