nstroustrup / lifespan

lifespan/ns_image_server/movement_analysis/ns_time_path_image_analyzer.cpp

Line 7089 in b117bc4

    
           p->analyzer->load_images_for_group(p->group_id, p->number_of_images_to_load, *p->sql, p->load_images_after_last_valid_sample, p->load_flow_images, *p->image_cache);

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!

failing to load all frames in storyboard