Slide 2: Underline both that in consensus figure, the trends are comparable and we overall are close enough but still are differences that particularly in biology limit quantitative measures. Solutions exist (eg normalization to water) but are not perfect -> have to find causes for these differences -> if not from physical differences, maybe coming from treatment -> to unify treatment we need to unify format
Slide 4: HDF5_BLS proposes to use a HDF5 file format to store all BLS-related data, and then offers 2 modules other than process data to PSD and PSD to results. It’s important to talk about the HDF5 file format because (1) it’s in the name of the package, (2) it was the option envisioned in the Consensus paper and (3) it will allow people not working with images to feel included in the project (and many people do not exclusively do imagery with BLS - me for example)
Slide 8: add non-images in title
Slide 9: It’s better to use the aims of the HDF5_BLS package I gave in the documentation and use in my poster (Simplicity: Make it easy to store and retrieve data from a single file. Universality: Allow all modalities to be stored in a single file, while unifying the metadata associated to the data. Unification: Allow and develop unified data processing tools to be used on BLS data.) Also, be careful, the .brimX extension does not exist, the default extension of HDF5_BLS is .h5. For the features:

Store any BLS dataset and BLS-related dataset in a hierarchical file format with a (proposed) unified set of attributes
Allow to extract PSD from raw data and perform fit from PSD with two independent sub-modules (HDF5_BLS_analyse and HDF5_BLS_treat) that are modular by construction to not restrict the using of custom algorithms, while preparing the ground for unified solutions (which will come as algorithms built with the classes of these modules).
Allows the storage of algorithms as both standalone files or attributes to be stored in the HDF5 file. These standalone files/attributes can be opened, shared, edited, re-run and presented comprehensively.
HDF5_BLS - The GUI: A graphical interface that interfaces the package allowing users to create, edit and (soon) treat (one or multiple times with one or multiple algorithms) their data without a single line of code.
GPL3 license (note: the package is under GPL v3, the format is not)
Ability to export to brim

Still slide 9: instead of linking to the Quickstart, just link to the main page of readthedocs, it’ll become the main source of documentation in v1.0.3 (I’ll release it after the congress).
Slide 10: HDF5_BLS - The GUI: the cross-platform desktop GUI to interface HDF5_BLS -> for now only buildable from source. Also we see a bit of desktop behind the image, I’m joining a replacement image with the new file icons and no desktop in the background
Slide 15: you’re a bit hard on yourself, on my computer Brimview from EMBL loads in under 1s, same goes for the samples, it’s rapid enough. For Pyodide option, the main drawback is that it doesn’t work on all browsers. Same goes for executables, with Mac you need a developer token to create executables, without it you can create it but you can’t open it (believe me I’ve tried to bypass that but for now Apple has patched every hack I had found to do it WITHOUT having to pay 99$ per year for a token). Haven’t tried local version.
Slide 19: This means you send data to the server to be computed on the server. This is true I believe only with the EMBL-hosted option (which is the best option I think as long as your protocols to communicate with EMBL servers are secure), with Pyodide it’s not and with local versions it’s not (your computer acts as the server). Also, you can ask ChatGPT or Gemini to generate an image to not have to put the reference to a (nice) Medium page.