[digiKam-users] JPEG grows bigger. Why?

[Dmitri Popov]

Hi Christian,

Thank you for the detailed and technical explanation. Very interesting and useful stuff.

Kind regards,
Dmitri
---
Tōkyō Made - https://tokyoma.de/

August 8, 2021 2:51 PM, "CD.Graesser" <cd.graesser at gmail.com> wrote:

> Some additions to the good explanation from Andrew.
> 
> Jpeg makes a frequency analys of the image and then it cuts away high image content frequencies
> where just a little change is in luminance or color. Example: The details (=high frequencies) of
> small branches of a tree infront of a grey sky are well maintained in Jpeg75% compression, but the
> detailes of allmost same green leaves of a bush are smeared out in Jpeg 75%, while they are almost
> perfect at compression above 90%. I use 95% compression in jpeg after editing in Digikam.
> 
> The coefficients for the frequency analyis may differ from jpeg vendor. Thus recompression gives a
> different representation of the image.
> 
> Jpeg works on blocks of 8x8 pix.
> 
> Besides the smearing of details, 8x8 pixel blocks appear to be visible with a different luminance
> or color than the adjacent 8x8 block.
> 
> The default of jpeg compression 75% in digikam is way too low and thus it makes especially to
> detailrich complex images visible quality issues.
> 
> I use 95% when storing in jpeg in DK which is in my opinion similar to superfine setting of the
> cameras.
> 
> One reason for me to use sometimes RAW are the jpeg compression and noise reduction artefacts from
> the camera. Both reduce the content of details and thus result in smaller filesize.
> I shoot most times in the camera Jpeg superfine with low noise reduction, then I do in DK
> whitebalance tool some brightness, gamma, color saturation and whitebalance correction and store it
> again in jpeg 95% in DK.
> 
> Happy dk-ing!
> 
> Christian Graesser
> 
> Andrew Goodbody <ajg02 at elfringham.co.uk> schrieb am Sa., 7. Aug. 2021, 23:31:
> 
>> On 07/08/2021 20:33, Dmitri Popov wrote:
>>> Hi Andrew,
>>> 
>>> Thank you very much for your detailed reply.
>>> 
>>>> But I suspect the most likely answer is that the original was saved at less than 100% quality.
>>> 
>>> Just out of curiosity, how is that possible? I mean, if the original (let's call it IMAGE A) was
>> saved with less than 100% quality, then some information would be inevitably discarded. Logically,
>> saving IMAGE A at 100% shouldn't result in IMAGE B that is larger than IMAGE A. Because you can't
>> have something more out of nothing. Am I making any sense?
>> 
>> But yes, you do get something more out of nothing. Except that it is not
>> out of nothing, it is the result of expanding information saved in a
>> lossy compression into a representation of the original image. Not
>> everything in that original image was accurately described so the
>> expanded image is a reconstruction that is close but not identical to
>> the original image. But it has the same dimensions as the original.
>> 
>> Image A saved at 75% quality (some information lost, but still basically
>> looks OK) but then expanded to be worked on gives you a working image
>> that is the same dimensions as the original but the missing information
>> is filled in with a best guess. This is how lossy compression works.
>> Some information is lost but is replaced with a best guess based on the
>> surrounding information (this is over simplified but good enough for here).
>> You now save that as image B at 100%, this will now include a
>> representation of the whole image including the parts that were filled
>> in by best guess. So the added size is describing information that was
>> not in image A. But when you reopen image B it will be a more exact
>> representation of the image when saved.
>> 
>> You cannot edit jpeg data directly. You can only edit the expanded
>> image. So when the expanded image is saved it is compressed again. You
>> are not saving an edited version of the original compressed data, you
>> are saving a compressed version of the edited image. Saving at a higher
>> quality will take more data.
>> 
>> Andrew