Multiresolution image sequence support

[subdavis]

fixes #55

WARNING

For multi-resolution image sequences already in the system, this will cause all detentions to become mis-aligned.

I haven't tested this extensively yet.

[BryonLewis]

I believe that the scrubbing issue needs to be fixed at least to eliminate the errors that occur with 0 pixels width/height. I have some stashed code that I used that fixed that I can show you if you want. I didn't go through and update everything but got it so there was no more image flashes as well as no more wrong resolutions when scrubbing.

I know you can do this for your own large dataset but figured I would include for ease of testing. I just used some NOAA images, one standard one, one cropped at a tall aspect ratio and then a sea lion overhead image and then ran the following to generate (warning it could be a few GBs):

for i in {1..300}; do cp one.png "$i-one.png"; cp two.png "$i-two.png"; cp three.png "$i-three.png";  done

[BryonLewis]

My fault, I probably left in the async seek() during initial testing. I'm wondering if we really want to wait for the image to load for each seek. During testing using a large number of different sized images scrubbing using seek would stutter. This is different than waiting for the last image to load, it would get to the final position then load the last 3-4 images quickly and then the final image. I believecacheImages() has a thing in it to make sure it loaded the current frame before attempting to cache anything else (call to loadFrame). Then if the user seeked before that first frame was loaded it would invalidate the loading.

I have an idea where it may work better if within seek we only draw the frame if the image is already loaded (checking this.imgs[this.frame].cached or .complete). Then in the onload for images we check to see if the currently completed this.frame is equal the onload frame and if it is we attempt to do the resize and drawing. I think this should improve some of the seeking a bit as well as handle the different image sizes. I realize that it may warrant some more discussion.

Below is a brief clip of the PR's behavior. Note there are errors in the console as well because when seeking the current img may not be fully loaded causing it to try to reset using 0 width and height causing an error in geoViewer.bounds function.

[BryonLewis]

I had an assumption that resizing the viewing area may be a bit taxing. Timing this out this function typically takes 1-2ms long to occur. I think we should filter either inside of this.resetMapDimensions(width, height) or elsewhere to make it so it only occurs when the width/height change for the image. I don't think we want this introducing lag on uniform image-sequences. I did testing over the EHU dataset running at 60FPS, it will lower the playback speed if trying to resetMapDimensions is called on every frame by an average of 1.5 or so ms over the full length of EHU.

[subdavis]

• All 90 image datasets checked.
• Made a note of only 1 corrupted dataset that will need to be manually fixed. Low priority, little activity from user.
• Checked datasets where data is not corrupted but annotations render wrong, will re-check again after this deploys.
• Made requested changes.

Please review again, @BryonLewis

[BryonLewis]

Works well for seeking on large images with differing sizes. Very minor things that I noticed that don't impact much.