Jump to content

Recommended Posts

I'm just moving over from Photoshop Elements, so I've got Culture Shock, but I'm enjoying the process.

I convert photographs to PNGs - a historic hangover from when I had trouble with support for CR2s. I notice that the PNGs produced by Affinity are noticeably darker than the PSE output, and darker than the CR2 originals, though I realise I can adjust everything.

More importantly, the files are about 4 times the size - 95MB as opposed to 23MB. (These are created from a 26MB CR2 file.)

I can see the case for storing the files uncompressed, to speed up processing, so is that what's happening, or have I missed something?

I'm running Affinity Photo 1.7.1 on a MacBook Pro, reading CR2 files created by a Canon EOS 700D.

Edited by JohnoFon

Share this post


Link to post
Share on other sites
5 hours ago, Fixx said:

but AP defaults to 16-bit.

To be clear: I think you mean that the default output of the Develop process is RGB 16-bit. As @JohnoFon is developing raw files your idea seems like a good one.

The standard Affinity Photo default for new RGB files is 8-bit, but the Develop Assistant gives a different default for files developed from raw image files.


-- Walt

Windows 10 Home, version 1909 (183623.476),
   Desktop: 16GB memory, Intel Core i7-6700K @ 4.00GHz, GeForce GTX 970
   Laptop:  8GB memory, Intel Core i7-3625QM @ 2.30GHz, Intel HD Graphics 4000 or NVIDIA GeForce GT 630M
Affinity Photo 1.8.3.641 and 1.8.4.650 Beta   / Affinity Designer 1.8.3.641 and 1.8.4.650 Beta  / Affinity Publisher 1.8.3.641 and 1.8.4.651 Beta.

Share this post


Link to post
Share on other sites

I obviously have a huge amount to learn!

I find it surprising that moving from 8-bit to 16-bit would quadruple the file size; doubling seems more logical.

I've been using PNGs as a raw storage medium that's easier to access than CR2s, but if the file volumes are quadrupling - or even doubling - it changes the balance.

Share this post


Link to post
Share on other sites
5 hours ago, JohnoFon said:

(1) I find it surprising that moving from 8-bit to 16-bit would quadruple the file size; doubling seems more logical. 

(2) I've been using PNGs as a raw storage medium that's easier to access than CR2s, but if the file volumes are quadrupling - or even doubling - it changes the balance.

(1) On a quick test I just did, a 16-bit RGB file took was only about 40% larger in PNG form than the equivalent 8-bit RGB file. So the 8- vs 16-bit difference may not be the full explanation for your file size difference.

(2) PNGs don't support compression natively, but TIFF does (and it's lossless, unlike JPG compression) so you might consider TIFF as an alternative. But it would be good to know why the PNG files are so much bigger.

By the way, you mentioned earlier that the Affinity files are darker. If you're on Windows, or using the Serif Labs Raw engine for your RAW development, its approach is to show you the actual raw data and let you adjust it as you want. Many other raw developers apply some default adjustments, rather than showing you the camera data directly.

If using the Serif Labs RAW engine, you can instruct the Develop Assistant to apply a Tone Curve, which should lighten things. But manual adjustment may give you better results.


-- Walt

Windows 10 Home, version 1909 (183623.476),
   Desktop: 16GB memory, Intel Core i7-6700K @ 4.00GHz, GeForce GTX 970
   Laptop:  8GB memory, Intel Core i7-3625QM @ 2.30GHz, Intel HD Graphics 4000 or NVIDIA GeForce GT 630M
Affinity Photo 1.8.3.641 and 1.8.4.650 Beta   / Affinity Designer 1.8.3.641 and 1.8.4.650 Beta  / Affinity Publisher 1.8.3.641 and 1.8.4.651 Beta.

Share this post


Link to post
Share on other sites
15 hours ago, JohnoFon said:

95MB as opposed to 23MB. (These are created from a 26MB CR2 file.

13 hours ago, Fixx said:

Probably you used to do 8-bit images in PSE, but AP defaults to 16-bit.

If the CR2 has 26 MB and 12-14 bit per channel, then a file with 16 bit per channel can't increase by its bit depth to 95 MB.

 

1 hour ago, walt.farrell said:

PNGs don't support compression natively,

Hm? – look: https://rawpedia.rawtherapee.com/Image_file_formats_and_compression

50 minutes ago, walt.farrell said:

But it would be good to know why the PNG files are so much bigger. 

This just repeats the initial question. – How about: Affinity doesn't compress natively its PNG exports.
 

15 hours ago, JohnoFon said:

I convert photographs to PNGs - a historic hangover from when I had trouble with support for CR2s.

Just in case you don't like TIF, mentioned by Walt already: Meanwhile Hasselblad, Leica and even some smartphones support DNG as RAW format, so it might be worth to consider DNG as an archive format to replace CR2. Unfortunately, Affinity doesn't natively support DNG, too. But its HDR appears to result in file sizes between your CR2 and the PNG.


macOS 10.14.6, Macbook Pro Retina 15" + Eizo 24"

Share this post


Link to post
Share on other sites
3 hours ago, thomaso said:

If the CR2 has 26 MB and 12-14 bit per channel, then a file with 16 bit per channel can't increase by its bit depth to 95 MB.

I was comparing PSE 23 MB and AP 95 MB. I did a test save with iPhone 12,3 MB DNG, exported as PNG: 8-bit is 20,1 MB and 16-bit is 64,9 MB. Quite in line.

Share this post


Link to post
Share on other sites
6 hours ago, thomaso said:

Thanks. I missed that. Simple lack of compression by Affinity would then be relevant, and a possible explanation.

 

6 hours ago, thomaso said:

Meanwhile Hasselblad, Leica and even some smartphones support DNG as RAW format, so it might be worth to consider DNG as an archive format to replace CR2. Unfortunately, Affinity doesn't natively support DNG, too.

?
DNG is on the list of supported RAW camera formats for Affinity Photo, though I have seen bug reports and fixes related to DNG files produced by some applications.


-- Walt

Windows 10 Home, version 1909 (183623.476),
   Desktop: 16GB memory, Intel Core i7-6700K @ 4.00GHz, GeForce GTX 970
   Laptop:  8GB memory, Intel Core i7-3625QM @ 2.30GHz, Intel HD Graphics 4000 or NVIDIA GeForce GT 630M
Affinity Photo 1.8.3.641 and 1.8.4.650 Beta   / Affinity Designer 1.8.3.641 and 1.8.4.650 Beta  / Affinity Publisher 1.8.3.641 and 1.8.4.651 Beta.

Share this post


Link to post
Share on other sites
5 hours ago, Fixx said:

I did a test save with iPhone 12,3 MB DNG, exported as PNG: 8-bit is 20,1 MB and 16-bit is 64,9 MB.

Doesn't it make it even more obvious that the PNG file size compared to RAW is not a matter of bit depth?

 

2 hours ago, walt.farrell said:

?
DNG is on the list of supported RAW camera formats for Affinity Photo

For export, too? – I don't have AfPhoto installed and looked in the AfPub export formats . Which makes me wonder now – in case DNG is in AfPhoto exports – why it isn't in AfPub, where even HDR and EXR are available.


macOS 10.14.6, Macbook Pro Retina 15" + Eizo 24"

Share this post


Link to post
Share on other sites
4 hours ago, thomaso said:

For export, too? – I don't have AfPhoto installed and looked in the AfPub export formats . Which makes me wonder now – in case DNG is in AfPhoto exports – why it isn't in AfPub, where even HDR and EXR are available.

Ah, sorry. I wasn't thinking that you meant creating them in Photo. They are supported for Opening.


-- Walt

Windows 10 Home, version 1909 (183623.476),
   Desktop: 16GB memory, Intel Core i7-6700K @ 4.00GHz, GeForce GTX 970
   Laptop:  8GB memory, Intel Core i7-3625QM @ 2.30GHz, Intel HD Graphics 4000 or NVIDIA GeForce GT 630M
Affinity Photo 1.8.3.641 and 1.8.4.650 Beta   / Affinity Designer 1.8.3.641 and 1.8.4.650 Beta  / Affinity Publisher 1.8.3.641 and 1.8.4.651 Beta.

Share this post


Link to post
Share on other sites
22 hours ago, thomaso said:

If the CR2 has 26 MB and 12-14 bit per channel, then a file with 16 bit per channel can't increase by its bit depth to 95 MB.

I am not sure I understand what you mean by this, but note that Canon's CR2 file format employs lossless compression of the raw sensor data (which is not in RGB format to begin with) to reduce file size, so it is entirely possible that the byte size can increase several times over after decompression & 'development' into a viewable RGB image. In fact, it would be unusual if it did not.

Also, the Affinity developers have mentioned that the native Affinity file format also includes some form of lossless image compression to reduce file sizes (LZW maybe?), so the CR2 > develop > export process is considerably more complicated than it might seem.


Affinity Photo 1.8.3, Affinity Designer 1.8.3, Affinity Publisher 1.8.3; macOS Mojave 10.14.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 
1.8.3.180 & Affinity Designer 1.8.3.2 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 13.3.1

Share this post


Link to post
Share on other sites
8 minutes ago, R C-R said:

compression of the raw sensor data

This appears to be the answer again: compression.
– My post was related to a note that the difference between the 95 MB and the 26 MB might result from different bit depth. Pure bit depth does not result in variable file size, it is clear defined by an amount of pixels and channels. From this point of view, your hints confirm my view that compression is crucial here in this topics question.

(... which, by the way, was not at all about the CR2 development process, but about the increase in the developed, exported PNG file size compared to the undeveloped CR2. The content of the output PNG won't contain more relevant data then its input, the CR2.)

I don't understand why you compare that with native Affinity documents file size. Of cause such can be much more complex and heavier then one single resource, no question, and I am far away from criticizing Affinities native file size. But since you talk about I wonder why a 26 MB CR2, opened and saved in AfDesigner as native .afdesign, increases to 126 MB, just by saving, no development or any work on it. Interesting: also the 95 MB PNG, opened and saved in AfDesigner, creates an .afpub with same 126 MB. However, it does not disturb me, since I don't plan to use Affinity as a storage container for images. It just makes me curious to understand what's going on inside. – Whereas the apparently uncompressed PNG does disturb me.


macOS 10.14.6, Macbook Pro Retina 15" + Eizo 24"

Share this post


Link to post
Share on other sites

@thomaso, you said this was not about the CR2 development process, but that must be a part of it for any comparison of the size of a CR2 file to any developed file size, whether that is in the native Affinity, PNG, or any other file format. That is because CR2 files do not include full resolution pixel images in any color space, just the raw sensor data from which RGB pixel images can be built during the development decoding process.

As the article I linked to put it, the CR2 file does NOT contain direct RGB data for each pixel. Even if the sensor data was not compressed, that still would be true. The sensor data would still need to be interpolated to get a RGB picture.


Affinity Photo 1.8.3, Affinity Designer 1.8.3, Affinity Publisher 1.8.3; macOS Mojave 10.14.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 
1.8.3.180 & Affinity Designer 1.8.3.2 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 13.3.1

Share this post


Link to post
Share on other sites
On 7/4/2019 at 10:39 AM, R C-R said:

That is because CR2 files do not include full resolution pixel images in any color space, (...)
(...) The sensor data would still need to be interpolated to get a RGB picture. 

@R C-R, this is indeed interesting, thank you! – I haven't been aware about this economy in saving a CR2 in the camera. It explains indeed the massive file size increase between CR2 and PNG.

Do you know whether still nowadays Canon and/or most brands (RAW file formats) use such a interpolation of 2 colors (R, G and B) and therefore lack of image output sharpness for every single pixel?

1505121664_CR2interpolationinr-g-b.jpg.14c7e9eb301eb71f06aff7ccd29a5ca2.jpg

 

It reminds me to SIGMA, about 15 years ago, avoiding that need to interpolate because of using a different sensor type, which saved all color information in every sensor pixel:
[and resulted in larger RAW file size, f.i. 53 MB (.FX3) towards 26 MB (.CR2)]

1000-sigma-dp2-quattro-foveon-sensor-vs-bayer_1405071577.jpg.f0e50d11721b529277c625edb8e5dc31.jpg


Experiment: http://www.centralds.net/cam/?p=8561
The color filter layer on a Bayer sensor (as in Canon) was mechanically removed. The result was monochrome (= grayscale) images, but with a clear improvement in sharpness:

rs11.jpg.a3b868d142fa5ff6aae1e194183d743e.jpg

 

Back to the topic: this CR2 saving economy means that 1.) a CR2 does not contain optimal information, just by limitations of its sensor and 2.) it is not economic to to archive such a RAW type with a developed / converted (= interpolated) file format like PSD, TIF, PNG, JPG.

Since DNG results in smaller files than CR2 I assume it at least does not contain interpolated pixels, and, from this point of view, is a better format for archives.
Whereas i don't know yet what makes a DNG smaller than a CR2, I never have read about loss of image quality by DNG. – Did you?
 


macOS 10.14.6, Macbook Pro Retina 15" + Eizo 24"

Share this post


Link to post
Share on other sites
27 minutes ago, thomaso said:

Do you know whether still nowadays Canon and/or most brands (RAW file formats) use such a interpolation of 2 colors (R, G and B) and therefore lack of image output sharpness for every single pixel?

AFAIK, for every camera that uses a color filter array ("CFA"), the development process must include the interpolation step to create the color image, if that is what you are asking.

Remember, in the raw format there is no image as such (other than low resolution previews or the like), just the raw sensor data. So in that context a "pixel" is just a cell in the sensor array, covered with a filter that blocks (most of) the light of other colors that strikes it.

In high end DSLR cameras, the cell's output is captured as a 12-14 bit precision number that is proportional to (but not necessarily linearly proportional to) the brightness of the filtered light striking it. The minimally processed cell data is stored in a greyscale mosaic format in the RAW file created by the camera, so the development software app must perform both demosaicing & interpolation steps as part of the the development process.

There are several good online sources of info about RAW development in general. IMO, one of the better ones is the Affinity Spotlight "RAW, Actually" article by @James Ritson. There are also quite a few Cambridge in Colour tutorial articles that cover various aspects of the RAW format in more detail, & like this one, include links to other related articles that together provide fairly complete & a bit more technical discussion of the subject.

Regarding the size of DNG format files, they are usually smaller than any of the (hundreds of!) proprietary RAW formats camera makers use, primarily because Adobe uses more efficient lossless compression than most of them. But it is still a RAW format so the above applies to it as well -- there is no direct correlation between cell 'pixels' & the pixels in an image developed from that data.


Affinity Photo 1.8.3, Affinity Designer 1.8.3, Affinity Publisher 1.8.3; macOS Mojave 10.14.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 
1.8.3.180 & Affinity Designer 1.8.3.2 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 13.3.1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Please note the Annual Company Closure section in the Terms of Use. These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.