Consider commits from CameraTraps/pull/349

[agentmorris]

@bobbycephy created microsoft/CameraTraps/pull/349 ("Improvements and extensions of run_detector.py and visualization_utils.py"), considering those changes for this repo.

These changes primarily extend run_detector.py, to the point that may exceed the spirit of run_detector.py (almost exclusively used as a simple test script), into functionality that is better supported by run_detector_batch.py. This PR would improve support for some non-camera-trap-related scenarios, at the cost of some complexity for core camera trap scenarios. Specific changes include:

• Allowing multiple images to be passed to run_detector.py using nargs="*"... directories are already supported, and I'd like to avoid breaking existing examples by introducing nargs="*" (which would break existing examples that put a required argument after --image_file)
• Passing missing arguments to crop_image... this is a bug fix, I'll cherry-pick this commit.
• Adding a separate option for relative box expansion (in addition to pixel-size box expansion)... this hasn't come up before and adds some near-redundant options to a core function, so I'd rather put this burden on the caller in the niche scenario where it's necessary.
• Using jpegtran-cffi for JPEG cropping... this adds new dependencies that would require some cross-platform testing, and this scenario hasn't come up before, so I'm inclined to skip this one.
• Copying EXIF data from input images to cropped/visualized images... this is a good idea, but load_image is a core function and I'm hesitant to add a second (mostly unused) return value, which would break existing calls to this function (fixable, but would require a lot of testing). EXIF copying is currently supported by separate_detections_into_folders, which is a more common path for this kind of operation for camera trap images. So I'm inclined to skip this one.

[agentmorris]

Cherry-picked the commit about missing arguments to crop_image, not pulling in the others for now. Thanks for your contribution!

[BobbyCephy]

@agentmorris Thank you for creating an issue considering my pull request! My changes to run_detector.py should only provide some useful optional features without affecting the current functionality as shown in the examples. I can't think of a better place for these features than run_detector.py, since they are only meant to generate improved output images from a few input images. In contrast, run_detector_batch.py only outputs detection results as a json file. Or in which way output images are intended to be generated based on those results? My changes should improve support for camera trap scenarios as well with negligible increase in complexity. They were just inspired by manual photography.

• Which example would not work with Allowing multiple images to be passed to run_detector.py? After --image_file and a whitespace separated list of files could follow an argument starting with --.
• [Adding a separate relative box expansion option] (https://github.com/microsoft/CameraTraps/pull/349/commits/a50bb6dbe4b7f81959520441750ce59d267e1779) would be really make sense, because a stationary camera trap could also simultaneously capture nearby large or distant small animals with magnitudes of different bounding box sizes, with proportionally large parts that might be cut off incorrectly.
• Using jpegtran-cffi for lossless JPEG cropping would not only improve quality but also speed and could not be a mandatory dependency, but be installed optional for using an argument like --lossless.
• Copying EXIF data from input images to cropped/visualized images load_image does not return a second value in the second commit with the same name, that should be amended to the first one: https://github.com/microsoft/CameraTraps/pull/349/commits/7608dd761df1695ef33f1265523d6c6745f28f5a

[agentmorris]

I think these are all just a little out of scope for our core scenario... generating new images (cropped or otherwise) is already a very rare scenario for camera trap data, and in the only case where it's necessary to copy metadata for that scenario, it's already handled. And without a compelling scenario, I'm really hesitant to rock the boat on functions like load_image() that are called hundreds of millions of times per year. I'm not deleting this issue, I'm just not going to pull any of these changes in right now; if any of these come up for camera trap scenarios, I will refer back to this issue.

And re: the --image_file changes... while your suggestion is very reasonable, we also try not to rock the boat on command-line syntax, since the substantial majority of our users have no experience in Python. And since "python run_detector.py --image_file image.jpg model_file.pt" is perfectly legal right now, it becomes hard to communicate about the behavior of the command line if --image_file can be followed by multiple arguments. I honestly had to look up what happens in this scenario. :) So for clarity, I would prefer to avoid nargs="*" here. run_detector_batch.py is the preferred method for bulk inference, and run_detector_batch.py can take a list of files as input.

But thanks again for your contribution (especially the bug fix)! It sounds like you may be working on a project related to wildlife photography more broadly, and it would be great to hear that MegaDetector may have applications there as well. I would call to your attention some of the limitations of training on camera trap data which could be problematic for non-camera-trap scenarios (particularly unexpected failures on cold-blooded animals), but if it works, it works!