https://bugs.kde.org/show_bug.cgi?id=470566
caulier.gil...@gmail.com changed:
What|Removed |Added
Version Fixed In||8.2.0
--
You are receiving this
https://bugs.kde.org/show_bug.cgi?id=470566
maison changed:
What|Removed |Added
Status|REPORTED|RESOLVED
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #50 from caulier.gil...@gmail.com ---
@maison,
What the status of this entry ?
Best regards
Gilles Caulier
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #49 from maison ---
Also as I said, I don’t think I encountered the metadata not refreshing in
digikam 7, so it might be something new in v. 8.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #48 from maison ---
(In reply to Maik Qualmann from comment #47)
> Your log doesn't show any errors. However, it seems that you have not
> activated the metadata option "Rescan file when files are modified". This is
> important in your
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #47 from Maik Qualmann ---
Your log doesn't show any errors. However, it seems that you have not activated
the metadata option "Rescan file when files are modified". This is important in
your case, however, so that a changed file is
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #46 from maison ---
Sorry, I forgot to set the option in the main profile (too much profile
fiddling). I sent you the new full debug log privately. I hope this finally
helps.
--
You are receiving this mail because:
You are watching all
https://bugs.kde.org/show_bug.cgi?id=470566
maison changed:
What|Removed |Added
Attachment #159498|0 |1
is obsolete||
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #45 from Maik Qualmann ---
The Qt debug variable is probably not set, or internal debugging is not
activated in the settings. The log does not show any digiKam debug messages. If
the metadata is re-read, the date found is output, none of it
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #44 from maison ---
Created attachment 159498
--> https://bugs.kde.org/attachment.cgi?id=159498=edit
Log for comment 43
Here is the log for the last updated files. I opened the main digiKam profile
which automatically updates files at
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #43 from maison ---
This bug is not only about geo‐location.
I’ve just discovered a few files that happened to have no CreateDate field
(which forced digiKam to use the DateTimeCreated field). I updated them through
the -csv=csv file option
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #42 from caulier.gil...@gmail.com ---
Hum, question must be posted on MXE github issue...
Gilles
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #41 from Maik Qualmann ---
This is also interesting with small patches for MXE:
https://octave.discourse.group/t/windows-utf-8-and-ucrt-yet-another-variant-of-octave-on-windows/1821
Maik
--
You are receiving this mail because:
You are
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #40 from Maik Qualmann ---
It is probably possible to compile MinGW with UCRT:
https://stackoverflow.com/questions/57528555/how-do-i-build-against-the-ucrt-with-mingw-w64
Maik
--
You are receiving this mail because:
You are watching all
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #39 from caulier.gil...@gmail.com ---
Git commit 37c680073ffa9ac53e056c71dd8fbc0b7178c455 by Gilles Caulier.
Committed on 06/06/2023 at 08:37.
Pushed by cgilles into branch 'master'.
under Windows, we needs to use 0.27-maintenance branch
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #38 from maison ---
(In reply to Maik Qualmann from comment #26)
> So, after various tests on Windows, I can't reproduce the problem. There is
> one more thing, since the last versions of Exiv2 (also 0.27.5) the Unicode
> support in Windows
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #37 from Maik Qualmann ---
I suspect that the problem here has nothing to do with the unicode problem
either, but without a real log and the corresponding image, it's just poking
around in the dark.
Maik
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #36 from caulier.gil...@gmail.com ---
UPSTREAM comment posted :
https://github.com/Exiv2/exiv2/issues/2637#issuecomment-1577969708
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #35 from Maik Qualmann ---
Ok, got the last answer from: https://github.com/Exiv2/exiv2/issues/2637
So Windows7 is out (obsolete anyway) and probably only works with an MSVC
build?
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #34 from caulier.gil...@gmail.com ---
I want mean this UPSTREAM bug from Exiv2 :
https://github.com/Exiv2/exiv2/issues/2637
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #33 from caulier.gil...@gmail.com ---
yes probably compilation option was not passed to the MSVC build to support
UNICODE.
I will switch Windows build to the 0.27-maintenance branch until this situation
is fixed to Exiv2 main branch.
so,
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #32 from Maik Qualmann ---
It was removed with this commit because of supposedly "dead" code...well,
"dead" code was extremely important to Windows.
https://github.com/Exiv2/exiv2/commit/7933ff401ddb9768502c36b1febea06b854e176a
The MSVC
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #31 from caulier.gil...@gmail.com ---
In Exiv2 main/branch, BasicIO is only based on std::string. So the Unicode
support under Windows is completely broken in Exiv2 0.28 as far i understand...
Gilles
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #30 from caulier.gil...@gmail.com ---
>From Exiv2 git/main branch (0.28 and later), the Exiv2::Image API provides :
std::string support :
https://github.com/Exiv2/exiv2/blob/main/src/image.cpp#L794
--> do not work with wide string char
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #29 from caulier.gil...@gmail.com ---
The explanations given in this thread, even if they are a little bit old,
explain well the mess under Windows about string encoding:
https://stackoverflow.com/questions/402283/stdwstring-vs-stdstring
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #28 from caulier.gil...@gmail.com ---
Maik,
I double check and the Exiv2 0.27-maintenance branch still have the
EXV_UNICODE_PATH support. This problem must only touch Exiv2 0.28
Gilles
--
You are receiving this mail because:
You are
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #27 from caulier.gil...@gmail.com ---
Hi Maik,
This means that if we go back to the Exiv2 0.27-maintenance branch under
Windows, will this problem also remain ?
Gilles
--
You are receiving this mail because:
You are watching all bug
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #26 from Maik Qualmann ---
So, after various tests on Windows, I can't reproduce the problem. There is one
more thing, since the last versions of Exiv2 (also 0.27.5) the Unicode support
in Windows is broken. If your image path contains
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #25 from maison ---
No, I don’t use extra metadata files. Most of the photographs are JPEG,
therefore there is no need for xmp files since metadata can stay in the very
file.
--
You are receiving this mail because:
You are watching all
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #24 from Maik Qualmann ---
Are sidecars possibly involved? Do you have sidecar reading enabled? Note that
GPS coordinates from XMP in digiKam take precedence over EXIF metadata.
Maik
--
You are receiving this mail because:
You are
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #23 from maison ---
Yes we are coming back to the same report: remember I used many ways to force
digiKam to update its data (probably all the possible imaginable ways).
Remember also that it did read the metadata after the external update
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #22 from Maik Qualmann ---
Reread the metadata in the item menu still doesn't show a geolocation icon? If
not, please create a log with this reread metadata action.
Note that the metadata option "Rescan file when files are modified" should
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #21 from maison ---
(In reply to Maik Qualmann from comment #14)
> When adding GPS information to an image, it is important to set all of the
> following tags: GPSLatitude, GPSLatitudeRef, GPSLongitude, GPSLongitudeRef,
> and GPSAltitude
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #20 from maison ---
Created attachment 159454
--> https://bugs.kde.org/attachment.cgi?id=159454=edit
Screen capture with a new digikam profile, therefore every file is new,
therefore file updates haven’t been performed, therefore the same
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #19 from maison ---
Created attachment 159452
--> https://bugs.kde.org/attachment.cgi?id=159452=edit
Screen capture with main software profile, a file that digiKam doesn’t update
because it’s been updated externally
--
You are receiving
https://bugs.kde.org/show_bug.cgi?id=470566
maison changed:
What|Removed |Added
Attachment #159451|0 |1
is obsolete||
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #18 from maison ---
Created attachment 159451
--> https://bugs.kde.org/attachment.cgi?id=159451=edit
Screen capture with main software profile, a file that digiKam doesn’t update
because it’s been updated externally
--
You are receiving
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #17 from maison ---
Created attachment 159450
--> https://bugs.kde.org/attachment.cgi?id=159450=edit
Screen capture with main software profile, a file that has been accepted
--
You are receiving this mail because:
You are watching all
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #16 from maison ---
(In reply to Maik Qualmann from comment #15)
> Why no GPS icon is displayed in your first screenshot because it contains
> Ref values cannot be judged without the sample image.
>
> Maik
Thanks for checking. Again, the
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #15 from Maik Qualmann ---
Why no GPS icon is displayed in your first screenshot because it contains Ref
values cannot be judged without the sample image.
Maik
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #14 from Maik Qualmann ---
Read this text in the ExifTool Doc:
https://exiftool.org/TagNames/GPS.html
---
When adding GPS information to an image, it is important to set all of the
following tags: GPSLatitude,
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #13 from Maik Qualmann ---
When I add coordinates with this ExifTool command there are no problems:
exiftool Minuartia\ viscosa\ 5.JPG -gpslatitude=53.86 -gpslongitude=11.19
-gpslatituderef=N -gpslongituderef=E
I assume you don't define
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #12 from maison ---
(In reply to Maik Qualmann from comment #9)
> I suspect you uploaded the wrong image, in your log and screenshot the image
> has the addition "Copie". By the way, the log shows no problems. One more
> note about
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #11 from maison ---
Maybe the log shows no problem, but the screen shots each show the same
problem, including the original one with altitude.
The last test was a quick test with dummy GPS data, but the original screen
capture is as
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #10 from maison ---
No, as I said, I modified the copy myself, so if you want to retest the new
metadata you have to work from the original again.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #9 from Maik Qualmann ---
I suspect you uploaded the wrong image, in your log and screenshot the image
has the addition "Copie". By the way, the log shows no problems. One more note
about screenshot, until before digiKam-8.0.0 digiKam would
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #8 from maison ---
That’s what I said I’ve done. Feel free to add GPS data with exiftool and
rescan it.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #7 from Maik Qualmann ---
Your sample image definitely has no GPS information, just a GPSVersionID. Exiv2
and ExifTool agree on that.
Maik
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #6 from maison ---
Created attachment 159441
--> https://bugs.kde.org/attachment.cgi?id=159441=edit
relevant screen capture
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #5 from maison ---
Created attachment 159440
--> https://bugs.kde.org/attachment.cgi?id=159440=edit
Sample image not geo‐located
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #4 from maison ---
Created attachment 159439
--> https://bugs.kde.org/attachment.cgi?id=159439=edit
Debug log
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=470566
--- Comment #3 from maison ---
So, I started a new digikam profile and a test folder with one geo‐located (see
the globe for that one) and one not. I worked on a copy of the latter, added
geo‐location externally with exiftool, then rescanned the
https://bugs.kde.org/show_bug.cgi?id=470566
Maik Qualmann changed:
What|Removed |Added
CC||metzping...@gmail.com
--- Comment #2 from Maik
https://bugs.kde.org/show_bug.cgi?id=470566
caulier.gil...@gmail.com changed:
What|Removed |Added
CC||caulier.gil...@gmail.com
54 matches
Mail list logo
