Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorporate EXIF functionality (and some refactors) #169

Closed
wants to merge 15 commits into from

Conversation

rexagod
Copy link
Member

@rexagod rexagod commented Mar 14, 2019

Follow-up on #156. Based off #161. Refer this.

@rexagod rexagod changed the title Extract exif Move EXIF to /tools Mar 14, 2019
@jywarren
Copy link
Member

jywarren commented Mar 17, 2019 via email

Copy link
Member

@jywarren jywarren left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, this looks good to go, once we remove the alert(). We could also add a confirm() instead of alert() so that people are prompted "Geolocate this image and move it to the location found?" with Ok and Cancel options. But we don't have to; we could just move it immediately.

Thanks a lot for this one, it's going to be great!

dist/leaflet.distortableimage.js Outdated Show resolved Hide resolved
test/karma.conf.js Outdated Show resolved Hide resolved
@rexagod rexagod requested a review from jywarren April 25, 2019 14:08
@rexagod
Copy link
Member Author

rexagod commented Apr 25, 2019

exif

@rexagod rexagod changed the title Move EXIF to /tools Incorporate EXIF functionality (and some refactors) Apr 25, 2019
@rexagod
Copy link
Member Author

rexagod commented Apr 30, 2019

Pinging @jywarren.

@rexagod
Copy link
Member Author

rexagod commented May 3, 2019

Just mentioning here that his PR was referenced on se18023's question that "Can geotagged aerial images be automatically placed in the right location on the map according to their coordinates?"

Copy link
Member

@sashadev-sky sashadev-sky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rexagod @jywarren Reviewing this now!

This is really cool. A few things to address:

  1. For some reason it isn't working with select.html, but I guess the 1st step would be to rebase this and then look into that. If it's complicated to fix I think that would be ok to address in a new PR if preferred.
  2. It is still printing to the console. @jywarren @rexagod did we still want to add a returned value instead? I think that would be good to fix here, and removing all the console.logs because I have noticed those upstreamed in mapknitter already!
  3. Minor separate suggestions below (sorry I know you probably were planning on refactoring this after @jywarren confirmed implementation but just in case)
    • potentially move dependency restructuring to new PR?

And last thing: is this still meant to be addressing the refactoring of the src/edit/DistortableImage.EditToolbar.js file? Is the idea now to move all of the toolbar tool action code being executed into separate files in /tools? So for example, all the toggle___ methods?

src/edit/tools/L.tools.EXIF.js Outdated Show resolved Hide resolved
src/edit/tools/L.tools.EXIF.js Outdated Show resolved Hide resolved
src/edit/tools/L.tools.EXIF.js Outdated Show resolved Hide resolved
src/edit/tools/L.tools.EXIF.js Outdated Show resolved Hide resolved
@rexagod
Copy link
Member Author

rexagod commented Jul 12, 2019

@sashadev-sky I'm seeing asynchronous bugs for the getEXIFdata method after updating this branch today. This seems strange since the code related to that is untouched (check commits above), which leads me to believe that there might have been some changes to the package (exif-js) while I was away? I even tried wrapping this in a Promise but no luck. What do you think?

PS. To summarize, this branch has been rebased and @sashadev-sky's suggestions have been implemented, and everything looks good except the EXIF bug, which is at the core of this PR. 😕

@rexagod
Copy link
Member Author

rexagod commented Jul 12, 2019

Update: Just verified. The package (exif-js) is still at the same version In this PR and the main branch, so that shouldn't be the source of this bug. Can't figure out what exactly is causing this?

@jywarren
Copy link
Member

And last thing: is this still meant to be addressing the refactoring of the src/edit/DistortableImage.EditToolbar.js file? Is the idea now to move all of the toolbar tool action code being executed into separate files in /tools? So for example, all the toggle___ methods?

It'd be nice but we have too many inter-dependent PRs so let's try to solve things one at a time. That may mean #225 can be merged if we don't need to solve these all at once.

@rexagod can you elaborate on the exact timing issue? If we need to pin the exif-js ref to a specific commit from when it was working before, we can do that for now to unblock this. Like, whatever commit from back in time. But it was last published 2 years ago so seems unlikely? https://www.npmjs.com/package/exif-js

@jywarren
Copy link
Member

Hey all, i wondered if you're ever needing cross-reviews or troubleshooting maybe it would be good to connect @Rishabh570 with you all here (see recent work here: publiclab/community-toolbox#236). You're all doing complex JS architecture so i wanted to make the connection in case it's helpful, for example with the timing bug here! 🙌

@Rishabh570
Copy link

I would love to contribute to this in any way possible for me, seems like there's some unresolved bit here which has put this to halt.

I'm seeing asynchronous bugs for the getEXIFdata method after updating this branch

So getEXIFdata is throwing errors as of now? Do we have the option of going back to the commit where it was working fine (like approx 14 days ago)?

@@ -13,11 +13,14 @@

<!-- for full-res export -->
<script src="../node_modules/jquery/dist/jquery.js"></script>
<script defer src="../node_modules/webgl-distort/dist/webgl-distort.js"></script>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rexagod Do you feel its better not to have the defer? I put it there to speed up initial page load

@@ -160,6 +161,7 @@ module.exports = function(grunt) {
'concat:dist'
]);

// disable for now?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rexagod why did you want this one disabled? is this still the case?

var image = this._overlay.getElement();
addHooks: function () {
var overlay = this._overlay;
var image = overlay._image;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
var image = overlay._image;
var image = overlay.getElement();

L.tools = L.tools || {};

L.tools.EXIF = function getEXIFdata(ref, overlay) {
var GPS = ref.exifdata,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we would want to update this part to use 3 vars as per new code standardization rules

typeof GPS.GPSLatitude !== "undefined" &&
typeof GPS.GPSLongitude !== "undefined"
) {
// sadly, encoded in [degrees,minutes,seconds]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you didn't copy over this code comment I just wanted to confirm if its irrelavent now or could still be useful


var panTo = L.latLng(lat, lng);

var x_diff = overlay.getCorner(0).lng - overlay.getCorner(1).lng; // width
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lets update this and below to deltaX and deltaY to abide to JS camelcase convention?

@sashadev-sky
Copy link
Member

@rexagod I have a different implementation in mind to make exif work, I opened the PR in #421 . Basically overlay.getElement() typically won't have any EXIF data because its a compressed version of the original element, which has stripped EXIF metadata. So I am writing an implementation where the fullResolutionSrc option will be used as a way to provide a fullRes download and a src with metadata (if it is passed, we will check for metadata from it not the image element currently in the DOM)

So I was thinking we could close this PR and work from #421 instead. What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants