Modify ↓
#13668 closed enhancement (fixed)
[Patch] Simplify ImageEntry#extractExif?
Reported by: | simon04 | Owned by: | holgermappt |
---|---|---|---|
Priority: | normal | Milestone: | 16.10 |
Component: | Core image mapping | Version: | |
Keywords: | Cc: |
Description
While looking into #13376, I stumbled over a possible simplification at ImageEntry#extractExif
(relating to #12255):
-
src/org/openstreetmap/josm/gui/layer/geoimage/ImageEntry.java
diff --git a/src/org/openstreetmap/josm/gui/layer/geoimage/ImageEntry.java b/src/org/openstreetmap/josm/gui/layer/geoimage/ImageEntry.java index 1c3a4d3..5acb2c1 100644
a b public void extractExif() { 523 523 Main.debug(ex); 524 524 } 525 525 526 // Time and date. We can have these cases: 527 // 1) GPS_TIME_STAMP not set -> date/time will be null 528 // 2) GPS_DATE_STAMP not set -> use EXIF date or set to default 529 // 3) GPS_TIME_STAMP and GPS_DATE_STAMP are set 530 int[] timeStampComps = dirGps.getIntArray(GpsDirectory.TAG_TIME_STAMP); 531 if (timeStampComps != null) { 532 int gpsHour = timeStampComps[0]; 533 int gpsMin = timeStampComps[1]; 534 int gpsSec = timeStampComps[2]; 535 Calendar cal = new GregorianCalendar(TimeZone.getTimeZone("UTC")); 536 537 // We have the time. Next step is to check if the GPS date stamp is set. 538 // dirGps.getString() always succeeds, but the return value might be null. 539 String dateStampStr = dirGps.getString(GpsDirectory.TAG_DATE_STAMP); 540 if (dateStampStr != null && dateStampStr.matches("^\\d+:\\d+:\\d+$")) { 541 String[] dateStampComps = dateStampStr.split(":"); 542 cal.set(Calendar.YEAR, Integer.parseInt(dateStampComps[0])); 543 cal.set(Calendar.MONTH, Integer.parseInt(dateStampComps[1]) - 1); 544 cal.set(Calendar.DAY_OF_MONTH, Integer.parseInt(dateStampComps[2])); 545 } else { 546 // No GPS date stamp in EXIF data. Copy it from EXIF time. 547 // Date is not set if EXIF time is not available. 548 if (hasExifTime()) { 549 // Time not set yet, so we can copy everything, not just date. 550 cal.setTime(getExifTime()); 551 } 552 } 553 554 cal.set(Calendar.HOUR_OF_DAY, gpsHour); 555 cal.set(Calendar.MINUTE, gpsMin); 556 cal.set(Calendar.SECOND, gpsSec); 557 558 setExifGpsTime(cal.getTime()); 559 } 526 setExifGpsTime(dirGps.getGpsDate()); 560 527 } 561 528 }
Are there some aspects against this simplification?
Attachments (0)
Note: See
TracTickets for help on using
tickets.
One difference is that no GPS time is extracted if
GPS_TIME_STAMP
is set butGPS_DATE_STAMP
is not. I think the photo_geotagging plugin used to look at theexifGpsTime
to decide what photo to update. It now useshasNewGpsData()
instead, so it is not that important anymore to have an EXIF GPS time. I don't know if there are photos that have that combination. The current code will set a wrong GPS date ifGPS_DATE_STAMP
is not set,exifTime
is one second before midnight andGPS_TIME_STAMP
is one second after midnight. But at the time the code was written is was more important to have anexifGpsTime
than to have it right.The other difference is that the current code does not change
exifGpsTime
if it is not set in the EXIF data. That should be changed in the patch to align it with the other code inextractExif
, i.e. callsetExifGpsTime()
only ifdirGps.getGpsDate()
is notnull
. There might be a case whereexifGpsTime
is set during GPX correlation and thenextractExif()
is called (e.g. in the photoadjust plugin property editor). In that case theexifGpsTime
should not be set tonull
.For me the simplification is fine with the mentioned modification (set only if not null).