Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The context
I've been working on some cool features that will IMO improve the depth and with of instamatic. However, I realized that with a month worth of work my planned PR will be very unfocused and overwhelming, so I decided to split it into a few chunks.
Bug 1
I have recently found three bugs, two of which were introduced in my PR #111. There, I suggested wrapping
get_media
(new generalizedget_image
andget_movie
) incamera.block()
andcamera.unblock()
statements which avoids collecting several "0-second" preview frames. I did not think though that unblocking once cancels both blocks:This is an issue because every data-collection frame using
block
/unblock
will now be interrupted by some previews when collecting images, as evidenced by adding a log statement and running aRED
frame. Given most instamatic frames useget_image
to collect movies, this is a big issue as it introduces unnecessary delays between frames:I addressed this bug by replacing
block
/unblock
pairs with a newblocked
context. If you wrap some code inwith cam.blocked():
now, the cam will block at start of the wrapped code and restore to the previous state, whether blocked or not, at the end. As an added value, if blocking camera for a short time, you can use a niceblocked
context as a "re-entrant" event:BUT:
Bug 2
PR #111 introduced
int_nm
andfloat_deg
to a newinstamatic.typing
. This typically works OK but in some specific cases statements likefrom typing import Callable
may try to findCallable
ininstamatic,typing
. I don't fully understand the mechanism behind it, I managed to get it in a very unique conditions, but to avoid any potential issues I just suggest movinginstamatic.typing
toinstamatic.typing_
.Bug 3
While investigating an old-but-reliable RED frame I realized that some of the logging statements present there were either misleading or wrong, so I fixed a few of them; see change log for details.
Bugfixes
MediaGrabber
: fix bug:get_media
clearedcontinuousCollectionEvent
, allowing premature collection of preview images;instamatic.typing
: move toinstamatic.typing_
to avoid rare but potential name clash with built-in module;Experiment
,acquire_data_RED
: fix broken and improve misleading log statements.Effect on the codebase
This PR fixes issues introduced in #112 and fixes minor logging issues in RED frame. No functionalities change, but a new
with cam.blocked()
statement is now available to block camera for short periods of time.