<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#ffffff">
<p><font face="Book Antiqua">Carol:</font></p>
<p><font face="Book Antiqua">I sense you are chasing a mirage.</font></p>
<p><font face="Book Antiqua">Comparing photos on a computer display
might reveal differences that are pronounced, but the low ppi of
typical displays mushes the pixels together. If you use a
high-resolution display, e.g. more than 500 ppi, your display
might display some of the two "identical" photos' pixels
differently, but would your eye see anything?</font></p>
<p><font face="Book Antiqua">And look at the actual ppi in the two
axes of your two photos. One is 4000 x 6000; the other is 6000
x 4000. In other words, all the pixels are there in the
respective axes. The disappearance of 2 MB is a quirk. So far
it is harmless, except that it is getting on your nerves.</font></p>
<p><font face="Book Antiqua">Your image file sizes are only 15 MB.
Keep them both.<br>
</font></p>
<p><font face="Book Antiqua">Bob DiGrazia<br>
</font></p>
<div class="moz-cite-prefix">On 6/8/2025 1:24 PM, Carol C.
Kankelborg wrote:<br>
</div>
<blockquote type="cite"
cite="mid:53C09465-C380-4EBC-BEEE-FDC586A30017@kankelborg.net">
<pre class="moz-quote-pre" wrap="">Thanks for your answers. See below.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On Jun 7, 2025, at 23:53, Remco Viëtor <a class="moz-txt-link-rfc2396E" href="mailto:remco.vietor@wanadoo.fr"><remco.vietor@wanadoo.fr></a> wrote:
On dimanche 8 juin 2025 06:45:18 heure d’été d’Europe centrale Carol C.
Kankelborg wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Steve,
Most of that makes sense. I noticed the height/width dimension switch. The
smaller file appears to have been rotated by DigiKam 8.1.0. That is the one
I put in the vacation album, so if it needed rotating, it makes sense I
would have done that.
I am presently using 8.6.0. Is 8.6.0 smart enough to note rotation when
displaying the image but 8.1.0 was not? The larger image has the same
orientation when I look at it in DigiKam (Similarity tab).
For software that rotates images (in this case I assume it was DigiKam
8.1.0), is the quality (and size) of the rotated image diminished because
it had to be uncompressed, rotated, then re-compressed? If so, is it a
serious degradation or should I not worry about it for JPG photos of
vacations? If not, why would one be smaller than the other? Is it just the
way the JPG compression works that portrait images are larger than
landscape?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">It all depends...
It is possible to rotate a jpeg image by 90° without extra loss, even without
decompressing it. Iirc, that's what digikam does when rotating in the album
view. That operation shouldn't change the file size (or not by much: there may
be some changes in the metadata).
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Do you happen to know if this was the case in DigiKam 8.1.0?
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
If you use the image editor, the situation is different: the image is decoded
*when you start the image editor* and any operation is done on the decoded
image. The edited image is then re-encoded, possibly with different settings,
when you save the image. This can change the image size, possibly by quite a
lot. *Repeated* decoding and re-encoding can also degrade the image quality.
The batch queue uses the image editor, afaik (and you don't need it when just
rotating a batch of images in the album view).
I didn't notice you mentioning how you rotated the images.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
I appreciate knowing that just starting the image editor decodes the image. I will have to look into what my settings are.
I didn’t say because it was a few years ago that I would have done it, so I don’t remember. Given that the images are 99% similar and they look identical (to my eye, looking at the screen and switching between them rapidly), I would guess that I didn’t make any other changes. If so, I doubt I would have opened the editor for each photo that needed to be rotated, when DigiKam offered a quick option from the album view.
The rotated files are about 2 MiB smaller according to the Properties tab. This difference seems significant to me. Is there metadata or are there tests I can conduct to see if one is more degraded compared with the other due to multiple decodings/re-encodings?
Does this refer to the image or the whole file with metadata included? Is there a way to tell how much space the metadata takes up vs. the image itself?
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
Related to that is the auto-detection of rotation: there is a metadata tag to
indicate image orientation. It's what the camera uses to record landscape or
portrait. A program *can* mimic an image rotation over 90° by adjusting this
tag. A viewing program may or may not use this tag.
Otoh, if you edit an image, that tag may be cleared and the image adjusted.
But there is no way for a program to deduce a rotation only from the image, it
needs to read the metadata to detect an intended rotation.
(simple, isn't it?)
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Do you happen to know if DigiKam 8.1.0 did not use that metadata tag but 8.6.0 does?
The smaller, moved to an album from its import location and rotated, image was imported in late 2023. The larger, still in the import album, was imported in August 2024, probably because it was still on the camera SD card and I wasn’t paying attention to make sure I didn’t import images I’d already imported.
Carol
</pre>
</blockquote>
</body>
</html>