I am amazed by the size of the images after development; they weigh 3 times less than the images made by the camera body.
The compression quality chosen by DxO is 90, which is not much.
Does this compression justify the division by 3?
Umm, I’ve always considered anything less than 95 to be quite severe, so I’m not surprised by the big reduction in file size.
Personally, I never export to JPEG. I prefer to retain as much detail as possible, so I export as 16 bit TIFF. I’ll then downsize that ‘master export’ as required.
1 Like
With big sensors, I can’t see differences.
Mine 62 Mpix…
I found this online.
But in the end all that matters is whether you are happy with the results. JPEG works on perception. I regularly export my images at 90 for publication and they always look fantastic.
1 Like
That’s an interesting diagram. I like that. But the content of the image does influence the size of the jpg too. None of my jpg’s have the same size. It can have a difference of 40%, a quick look.
George
Oh, for sure. RAW files are the same. My largest RAW file has most of the frame covered by the fine mesh of a bird enclosure.
I think the graph is intended to show the ‘typical’ curve an image will follow. Obviously the input has a bearing on the absolute numbers, but I suspect the shape of the curve would be similar for most inputs. The key take away from it is where that ‘elbow’ is, right around the 90 mark.
Indeed! I’ve discovered that my carefully processed RAW files that end up as >150 MB TIFFs look good when reduced to a mere 256 KB using RIOT (https://riot-optimizer.com/) 
1 Like
I’m a bit irritated. I use a JPEG compression of “80”. I decided to do so after many tests and thorough examination of these JPEGs vs. the RAW file image of my 24MP Alpha-7 Mk.I. I did not see any improvement when using 85 or 90 compression factor but the increased file size. And I’m talking of examination with 100% zoom on a 24" Display.
Did I look at the wrong places? What are the most critical situations for the JPEG compression algorithm? I examined high contrast fine structures most of the times…
Regards - Matthias
Compression is usually most evident is smooth gradations of tone or loss of detail in shadow areas.
4 Likes
@kestrel401 My findings were similar to yours.
A few years ago I did a series of jpg exports (from raw files, and I was using Lr at the time) of the same images at 100/95/90/85/80%
At 85% I could define zero difference to the 100% exports, and yet the file size was multiples smaller.
By the time I went to 80% I could start to see degradation in very fine detail and shadow areas.
I should probably repeat this test again using PL to check I can continue using 85% for my exports.
My exports go online and are then downloaded by clients for their use in print publications, blogs, web content, Twitter, Instagram etc. Therefore I send them full Res JPGs saved at 85% compression. The client resizes the image pixel dimensions for their own requirements.
The smaller size files have saved me a lot in upload time and gallery storage costs over the years.
My test has also meant I’ve never felt the need to pay for JpegMini as I found that the files created by that app were about the same in size as 85% compression.
Edit: Do you own tests, with your own images and edits, and come to your own conclusions folks. The tests I did above were done a long while ago now and software advances consistently. I need to re-do my tests using the newest releases of all software (ie PL and JpegMini).
1 Like
No, that’s not accurate. I also thought “why paying another app”, but JPEGMini is able to reduce files size massively, Will deliver some samples tonight.
1 Like
Nice, thanks @JoJu .
As mentioned, my test was done a long while ago and times do move on.
My past findings could certainly be out of date now.
I definitely need to redo my tests, in fact I’ve just added this to my To-Do list!
Ocassionally JPEGMini saved between 30 and 50 % of file sizes in my gallery. And since not everybody has big data transfer rates for download, I made the “Second JPG” step part of my workflow in DxO and C1. I repeatedly tried to find differences between the large JPGs and the smaller ones and could not find any.
1 Like
I’d never heard of this app until now. However, having used RIOT from any years now, which I linked to above and is free, I’m not likely to ever use it.
@CHPhoto here’s my comparison:
| DxO PL 5.4.0 | C1 22 (15.3.1.15) | |
|---|---|---|
| number of RAW (DNG) | 23 | 23 |
| time to process | 9’30“ | 1’27“ |
| smallest JPG | 8 MB | 7.9 MB |
| biggest JPG | 32.7 MB | 34.5 MB |
| Total MB | 435.67 MB | 497.74 MB |
| JPEGMIni time to process | 0’20“ | 0’12“ |
| smallest JPG | 5.2 MB | 5.4 MB |
| biggest JPG | 26 MB | 22.9 MB |
| saved MB | 128.94 MB | 215.30 MB |
| Total MB to upload | 306.73 MB | 282.43 MB |
The RAWs were 60.2 MP DNGs out of a Sigma fp-L which apparently is a challenge for PL, less so for C1.
But adding 20" or 12" to reprocess the JPGs in JPEGMini 2 (3 is already available) and getting the MB down from nearly 500 to not even 300 is worth the extra time - which I let do C1 automatically.
1 Like
It is also more evident in red coloured areas, then yellow. Blue and green are far more forgiving.
1 Like