failing to load all frames in storyboard
kolt-mcb opened this issue · comments
Hi Nick,
I manually changed p->number_of_images_to_load on line 7089 to 12 (arbitrary) as this number was the last frame that I was able to view, past frame 10 and now fail loading frame 13, can you tell me if this number is used as a type of pagination or is it the total number of frames for an object/animal?
Good question. For context: when an individual worm is selected for inspection, the worm browser starts to load the required image from disk asynchronously. So in this case, p->number_of_images_to_load is the total number of images requested by the main thread for asynchonous loading. The request originates here:
https://github.com/nstroustrup/lifespan/blob/flow/ns_worm_browser/ns_death_time_solo_posture_annotater.h#L1071 [https://github.com/nstroustrup/lifespan/blob/flow/ns_worm_browser/ns_death_time_solo_posture_annotater.h#L1071]
Ultimately, the value in p->number_of_images is specified in the main thread using the value in "number_of_valid_elements". This is intended to be a request for an asynchronous loading of images associated with that worm. "number_of_valid_elements" calculated by finding the first excluded image and considering that the final image associated with the worm.
On reflection, this seems like a bad approach for calculating the number of images to load. It only works if no valid images exist after the first excluded image--which is a common situation but is not guaranteed in all cases. The better approach would be to load all images up to and including the final non-excluded image. Additionally, the worm browser should make sure to request sufficient images so that the first image being displayed is loaded--specified by the current_timepoint_id value used here:
https://github.com/nstroustrup/lifespan/blob/flow/ns_worm_browser/ns_death_time_solo_posture_annotater.h#L1116 [https://github.com/nstroustrup/lifespan/blob/flow/ns_worm_browser/ns_death_time_solo_posture_annotater.h#L1116]
I have put a draft patch for these issues here:
03c14c7 [03c14c7]
However, looks like there could additionally be a race condition here between asynchronous and synchronous image loading requests. I will investigate ASAP and patch as needed.
Nick
On 3/3/2020 9:44:13 PM, koltafrickenfer <notifications@github.com> wrote:
https://github.com/nstroustrup/lifespan/blob/b117bc4d93df2038b9e8999c331c2549f705448d/ns_image_server/movement_analysis/ns_time_path_image_analyzer.cpp#L7089 [https://github.com/nstroustrup/lifespan/blob/b117bc4d93df2038b9e8999c331c2549f705448d/ns_image_server/movement_analysis/ns_time_path_image_analyzer.cpp#L7089]
Hi Nick,
I manually changed p->number_of_images_to_load on line 7089 to 12 (arbitrary) as this number was the last frame that I was able to view, past frame 10 and now fail loading frame 13, can you tell me if this number is used as a type of pagination or is it the total number of frames for an object/animal?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub [#5?email_source=notifications&email_token=AAUR45UUZJD5C5XHQKPRADDRFVTZ3A5CNFSM4LASU3B2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4ISEXVLQ], or unsubscribe [https://github.com/notifications/unsubscribe-auth/AAUR45VL626BRRRJKTYZ7WTRFVTZ3ANCNFSM4LASU3BQ].
OK--that opened up a can of worms...
...but several issues in the asynchronous image loading process should be fixed by the patch
56b70f4
Please test on your system.
N
Nick,
My first impression is that everything seems to be working, let me annotate this experiment and see if I run into any issues! Great work!