General Handling of exceptions and callbacks to end GUI

[cfculhane]

Wasn't quite sure how/where to articulate this, but during my implementation of unit testing and logging I've come across the following issue, which I think I have resolved, its just a bit of a tangle.

It was previously mentioned that there was a non-zero exit code, which was then resolved by adding sys.exit(0).

It appears this was due to the way it was exiting when running out of frames, which was done via Importer.route_frame() raising an error, which was then handled further up with a broad except clause.

I have resolved this by calling the Importer.release() method when there are no remaining frames, as below:

        _, image = self.capture.read()
        if image is not None:
            image = cv2.cvtColor(image, cv2.COLOR_BGR2GRAY)
            self.proceed(image)
        else:
            logger.info("No more frames to process, exiting.")
            self.release()

Now that there is logging implemented, this approach is going to be cleaner rather than having exceptions bubbling up for things that aren't really exceptions - running out of frames appears to be an intended call to end processing. This method also allows later on a config variable to be passed in to optionally disable this behaviour if needed. @simonarvin Let me know if this approach works for you :)

[cfculhane]

I also have minor uncomfortable-ness about the dynamic mapping of the various methods to Importer.route_frame(), but I understand (I think) why this was done, it makes keeping track of what method needs to be called further up the stack way easier, it just plays havoc with debugging when you're not quite sure what a method is doing, or what it's arguments are. For better visibility I've added

self.route_frame: Optional[Callable] = None  # Dynamically assigned at runtime depending on input type

To the definition of cv.Importer() , this later then gets assigned to either route_cam(), route_sequence_sing(), or route_sequence_flat()

A more elegant solution going forward would be to have route_frame() be a method that chose which of the three above methods to call, based on some state variable. This way you would have consistent arguments and return types.