 So welcome everyone. Those who don't know it, the Bias Academy was set up last year in around April. And so far we have basically unraveled like a bit more than 22 webinars. And this has encountered a certain success. So we have like more than 40,000 views on YouTube. And in general, so everything is recorded and it takes about one, two weeks to actually be stored and uploaded on YouTube for posterior viewing, okay? So to start 2021, we have decided together with Romain, Marion, Sebastian and the Bias Academy team to set up something a bit special like a series of five webinars that ideally would be viewed in order, so in sequence. So basically you're here in the first one and just to mention the registration is open for the second and the third one. And the number four and five will very soon come open for registration. And then we will try to set all the answers to the questions you will ask today on the image.sc forum. This will take hopefully two weeks. And the webinar is kindly hosted by the Crick Institute. So Rocco D'Antono is here, basically managing with the subscription of the Institute. So I hand into Kota who will introduce today's webinar and these speakers. Kota? Okay, so sorry, I delayed. So I'm Kota and so I would like to welcome these three great guys, Tobias, Nicholas and Tishi. And so the talk will be done in three consecutive, three different sessions but they are all connected because it's historically, it's developed initially, Tobias developed this big data viewer and then there's a kind of extension or additional functions or more features with this big data viewer playground. And then there'll be even more with this big data processor, which is now we have more features additional. So it's a kind of an ecosystem surrounding big data viewer. So the first speaker is Tobias Pitch. And then, so I know him from his great talks. It's mostly always very impressive with this, I'd say very mathematical. So I asked him today if he's doing a similar talk but today he's going to be no mathematical, more computational scientist side. And then he's in Dresden always been and then he's one of this very major contributor to this Fiji. So the second speaker is Nicholas Chiarutini. He's an EPFL, his background is biophysicist and then he has been working a lot on this membrane physics, how they pinch off and then modeling. So he's not only image analysts but also has a deep knowledge in how to model those things. And then the third speaker is Christian Tishi and then he's been long time in EMBOL and then has been started as a biophysicist and then became more specified into this image analysis studies. So I would like to with this very short introduction thanks for these guys to give very nice presentations that I expect. First of all, the first speaker is Tobias and then please welcome. And thank you very much. Okay, so let me share my screen for the presentation. Yep. And then Okay. Can somebody confirm that they see slides? Yes, we see your slides, yes. Yes. I see it. And not the preview, but the slides. Okay, cool. Okay, so then let me start. So this is the first time in a series of webinars on big image data. And as already said in the introduction, basically it's split into three parts and I will start it off by showing a bunch of slides and talking about the concepts and challenges of handling big image data in general and mostly focusing on visualization and of course, big data viewer. And after that, still in the first part I will do a short demo of big data viewer and after that, Nico and Christian take over with the BTV Playground and big data processor, two parts. Okay, so let me start by telling you how I got involved with this big image data topic. So the need to develop big data viewer was Lightsheet Microscopy Data and I was working in Parvot Manchuk's lab at the time and the lab is interested in embryogenesis. So it's like the stuff that you see happening here and we were early adopters of Lightsheet technology and live imaging of embryogenesis of various species. So we had an early prototype of the size Lightsheet Microscope and also custom build setups in-house and so we became very early on familiar with the specifics of the data and it came off the Microscope. So higher resolution, both spatially and temporarily you can make very long time lapses or days you can have multiple angles or tiles or genits or combinations thereof in a single data set and the data sets become very large up to several terabytes. And so of course, we noticed that you it's very difficult to do anything meaningful with this data. So basically the data viewer was then developed as a way to at least look at this data interactively. So big data viewer is a feature plugin for interactively browsing such large image data sets and it has been used for data sets that are larger than a hundred terabytes. So the typical Lightsheet data sets can be handled quite comfortably. So big data viewer provides interactive free-slicing and browsing of, for example, Lightsheet data sets supports time points, channels, angles, tiles and so on and everything, all these different aspects are registered into a common global coordinate system and then you can look at the individual tiles and channels one by one or jointly combining them into a single image. Big data viewer also has its own file format to store such data sets, but it also supports many other file formats and backends. Maybe most importantly, it was from the start intended not as a standalone software but as a library of reusable components. So it's meant to be used by our feature plugins. So it's a toolkit, a library of reusable components that is intended to be easy to embed and adapt to various tasks. On this slide, there's a lot of detail, but just on the highest level, basically there's just two components, a backend and the front end and the backend is responsible for loading and caching large data sets. It's adaptable to different data and file formats. So for example, as you can see in the bottom here is the five and five Mars cutmate and so on are supported data formats and then it does caching of that and presents it as sources. And on the other side, we have a visualization front end that takes sources of image data and just basically reslices them and displays them on the screen and supports extension points for UI hooks and overlays that you can put on top of the data. So both these components backend and front end are meant to be reused either individually or in combination. They are both built on ImageLib 2 which I will say a very little bit about later and that makes it easy to reuse them in our feature plugins or in general in anything else that is using ImageLib 2 APIs. This model of being reusable components has been very successful. So you have a few tools that reuse big data fuel. You will see many of them as like two of them later today in the webinar but also in the whole webinar series you will see several of these tools. And just to give you a minimal first look at what this reuse can look like, here's a movie of interactively browsing cell tracks in Mastodon and that reuses both the data backend and visualization front end. And here we just have added some custom actions and overlays of the cell tracks on top of the big data fuel rendering. Okay, so now let's get more technical and look at the concepts behind interactively visualizing big data sets. In fact, the trick is mostly in how the data is stored because obviously you cannot load the whole thing into memory at once. So the data has to be stored such that you can access the relevant pieces efficiently. And there are two main ideas. And the first idea is multi-resolution pyramids. So if you assume that the red region that you see here represents the content that you currently want to put on the screen, then as you zoom out the region gets bigger and bigger because you show a larger, basically a larger part of the data set. So if you do it naively then the bigger the region gets the more data you need to load. And actually as you zoom out a lot of the data that you would have to load is any way irrelevant detail that is not visible in the first place. So the first idea is to store this as an image pyramid in multiple resolutions. And then as you zoom out you switch to ports or resolution levels. So and if you do this, then this will keep the amount of data that you will need to load to rent a few roughly constant independently of how large the region is that you want to show. So the second idea is tiling. So on the one hand, as we just said we only want to load the data that is currently visible. But on the other hand for high IO performance when loading the data it's best if you read data that is laid out contiguously on disks. And tiling provides a nice trade off between these goals. So you do not store each level of the image pyramid as a large area let's say but you tile it and store the tiles individually and compress them individually. And then basically instead of loading just the pixels that you need, you need all the tiles that contain pixels that you need. So this is a kind of a nice trade of you load data contiguously. So you have fast IO and you do not have to load much more data than you actually want to show. Tiling also facilitates caching. So we can cache recently loaded image blocks in memory assuming that they are likely to be needed again for the next images if the user moves a bit further. So for example, like if you have the green blocks here already in memory and then the region that we want to show changes slightly you can reuse a lot of them. Just need to reload like the blue blocks. So need to load one here and for the next one we need to load two more blocks. And then blocks that we haven't seen for a while we just forget so that memory doesn't run full. The final idea to make this work interactively is to use lazy loading or to have an idea how you deal with missing data. So for interactive rendering basically sometimes you cannot load the data fast enough. For example, you might not even have the data locally it might be on some server in the cloud. And you have latencies to that you have that for connection, et cetera. So it might happen with the situation. I basically just load for you just wait for a long time until the data arrives. So it's good if you have a plan for dealing with the situation. And for example, the way big data viewer does it is that we reuse data from multiple levels of the resolution pyramid. So we ordered the pyramid levels. So depending on how good they fit the current screen resolution so we have the best resolution and the second best and third best and so on. And of course we try to load everything for the best resolution but then if you cannot get the data fast enough we just use data from other pyramid levels that we already have to at least show something on the screen. And if there's nothing in any pyramid level then basically we at least show black and do not block until we have data for that. So that browsing remains interactive. So as I said earlier, at least want to briefly mention the underlying technology that facilitates these concepts in big data viewer and that is image2. That's a generic image processing library that we developed together with Stefan Breibisch, Stefan Seilfeld and that makes these concepts possible in big data viewer and not only possible but in a possible generic way so that you can plug in your own new data sources, your own like image modalities, backends and so on it will all work seamlessly without changing anything in the big data viewer code. So, okay. The reason why this works nicely is because image2 builds on a few abstractions that are basically that are interface levels in how we think about images. So we have like abstract concepts of accessibility that are complete images then accessors that basically move through the images and collect values from the images and then also an abstract concept of the type which is the pixel value and the operations that a pixel value provides. And as I said, these are all implemented as interfaces. So these are kind of natural extension points where you can plug your own code. And we use for example, the accessor that this is an interface means that for example, if you want to access a pixel we can abstract from how that pixel is stored and look for example, do we already have the tile loaded where that pixel is? And if it's not loaded, we can load it and so on and only then return the pixel and so on. And the same like on the pixel level if you want to access a pixel value then we can return a pixel value which knows whether it's already valid in memory or not. And then we can do operations on top of that. Okay, so that's the background on Big Data Fuel. I will give you a demo shortly. I just want to mention that there are of course like these ideas are not unique and they're kind of obvious actually and many commercial and open source tools use very similarities. We have the commercial tools like Morris and Grievous. We have web-based tools such as Catmade or NeuroClancer and then we have Python tools such as Napari which implements most of these ideas, let's say. Okay, so this was an overview of the concepts and I want to spend a few remaining minutes on talking about the challenges. So one big challenge of course is file formats. So you have a lot of data and you need to store it somewhere. And based on what I said before, of course I would recommend that you choose formats that support image permits and accessing the data in tiles. And then of course you have to live with the reality of the software landscape and different tools support different file formats. And so if you will implement an actual workflow. Unfortunately, this often requires that you resave your intermediate results multiple times. Resaving in practice always loses some metadata. So it's a good practice to just also keep the original files that you got from the microscope so that you have all the original metadata. Okay, just some recommendations of which file formats you can use. So HDF5 is a container file format. So it's often called file system in the file. And that supports n-dimensional data arrays which can be tied and then arbitrary metadata and the BDB default format is built on this. And for example, also the IMS format by Amaris is also built on HDF5. So basically HDF5 is like a family of languages and there are various dialects. HDF5 is great for reading the data but it has its shortcomings for writing data. So it's difficult to write data in parallel. And you can, if you basically if your computer crashes while you write an HDF5 file or is at least a chance that you end up with a corrupt file that is unusable. So to deal with these challenges, there are some alternatives. So one example is N5 out of the Salfive Lab and it's basically N5 originally meant not HDF5. And instead of being a file system in a file, we could say it's a file system in a file system. It supports also in dimensional areas and metadata just like HDF5. And actually it's an API and it's not so much a file format. So it's basically a software interface to accessing various backends. Like there's implementation for storing on the local file system on Google Cloud S3, even the backend for HDF5 and also backend for SAR and SAR is the other format that I want to mention. So this is basically identical or very similar to N5. It has this builds on the same ideas. It comes more from the Python world than from the Java world, but it has the same concept. It's also an API not a file format. Also backend, same backend file system, Google Cloud S3, HDF5 and also N5. So basically they are compatible. So all of these formats that I mentioned, HDF5, N5 and SAR, these are all container formats. So you can store like data arrays into them, but you still need to specify how you organize the data if you have multiple images, how you store it in N5 or SAR container. And there's also no standard yet of which metadata there should be. So for that, OMIR is working on a next generation file format and Christian Tyscher is involved in that. So I would briefly let him speak about this a few sentences maybe. Hi, so I think it's a bit saying too much that I would be involved in it. I would just like to advertise the initiative so I don't do much there. So yeah, I mean, I think we like to complain always to the microscope companies that they all invent their own new file format, right? But I think as an open source community, maybe we should also be careful not to end up with the same situation that every lab now has their own file format. And I think in that sense, this initiative from the OMIR Consortium is super important. So they try to get us all together to see, can't be maybe please agree on something that we don't have to resave our terabytes five times. So yeah, please check it out, OME, NGFF if you Google that and then maybe get in touch and see if that would somehow work for you. That's it, thank you Tobias. Thank you. Okay, so that's basically the first big challenge file formats and then I just like have one slide which summarizes a few of the other challenges that we have. These are related to storage and processing. So if you have like really data sets, several terabytes, then every time you need to copy files from A to B, let alone over a network is a pain because it takes really long like hours or days. And therefore you want to think about using software that allows you to transfer and process the data in chunks so that you can overlap the copying and the processing. So you can like send the first chunk, process the first chunk and while you process the first chunk, you already sent the next one and so on. You also want to think about how you distribute your processing on a cluster example and then of course how you send data around from the cluster to the place where you need the data in the end and then you also want to think about how you visualize the intermediate results. Like if you have several computation steps that happen on the cluster, you maybe do not want to just look at the end result after a few hours, but maybe you want to see like the intermediate steps even incomplete intermediate steps so you need a way to visualize the data. And I have ideas about how to solve that but I have no ready-made solutions. So that's just my thoughts on what I did. So before I show you the data, if you were just like here are my acknowledgements. So this is my long-time collaborator Stefan Zalfitz, Stefan Prybysh, they are involved in both ImageLib and Big Data Viewer and obviously a lot more people are involved like I would say from the general the Fiji ecosystem or Fiji community and a lot of these people help with ImageLib and Big Data Viewer and so on. And finally, my labs at MPI, CBGA, so Harvest Lab where I worked for a long time and now Florian's lab and they both support this development. Okay, so then I would, yeah. Yeah, so. So I don't know, do we want to do a few questions now or should I just continue with the? So maybe just several questions already. So there was, can you give a kind of short answer on what is the general requirements for the hardware to run this Big Data Viewer? Yeah, nothing basically. Okay, good. I mean laptop, an old laptop with two gigabytes of RAM or something like that. So. Okay, okay. It's really not, yeah. Okay, so another question, this is also a kind of general question, but so what art is a format difference between like the ones that is by Arabia's or by E-Marist or, I mean, so the difference between these format, Arabia's, E-Marist, HDF-5, can you make a short comment on this? So E-Marist is HDF-5, like it's a dialect of HDF-5. So basically E-Marist format is just the definition of what you store into an HDF-5 file. What's like, what's the name of the area that stores the data set, which metadata must be present and so on. And in fact, yeah, because these ideas are somehow relatively obvious, the big data fewer HDF-5 format and the E-Marist HDF-5 format are very compatible. So it's very similar. And Arabia's, I don't know exactly what they do. So they have a proprietary file format. Okay, maybe there could be at some point, there could be a table comparing different containers and then what are the essential differences and so on. But I guess, so I have a question. So what is the largest, the biggest data that you visualized by yourself, size of the E-Marist-5? Not by myself, a few terabytes, like 10 maybe. But I know that Stefan Salfert in January, they used it for data sets over 100 terabytes. Okay, very good. So please go on with the demo. Okay, cool. Okay, so then let me quickly show you what the big data fewer interface looks like. So the big data fewer comes with the vanilla Fiji. It's in the plugins menu, big data fewer and then there's a bunch of items in here. And I want to basically just show you the interface first so you can just open the current image, which means that I just open a normal image stack and then view it in big data fewer. So let me do that. So I just open one of the sample images. This one is nice and colorful. So we have a 3D stack here of a Drosophila lava brain. And then you can go here, big data fewer, open the current image. And then it appears on the upper screen, of course. And then we have here big data fewer with that current image open. And this can be useful even if your data is not really big data, like in this case, because big data fewer allows you to resize the data and navigate easily through that. You do this mostly by keyboard shortcuts and to know the keyboard shortcuts, you just can press F1 and then again on the other screen a health window, of course, which gives you like a walkthrough of how you navigate around using the mouse and how you navigate using the keyboard and how you can do bookmarking and similar stuff. And a few things are also up here in the menus. So you can just look through that. So, let me show you the basic navigation. So you can click somewhere and so you can right click somewhere and drag the mouse to move the data around. You can, like in X and Y, you can scroll forward and backward to move around and set. You can left click and drag to resize the data. And now maybe it's a good time to focus your attention up here on this menu map. So this gives you an idea of where you are in the data set. Basically, you have here the bonding box of the data set and how if I resize, you can see how the data sets rotates, the box symbolizes the data set, the gray rectangle here symbolizes the screen, like what you currently see. So if I zoom in or out, you see that now I'm zoomed out. So the data set is much smaller than the screen and now I'm zoomed way in and now the screen is just a small part of the data set. And then you have color coded here. The green part of the cube is in front of the screen and the magenta part is behind the screen. So if I basically move and set, okay. A bit more zoomed out. If I move and set, you can see that basically more of the data set moves into the screen or out of the screen. So all these things like panning around and rotating, you can also do with keyboard shortcuts and which gives you a bit more like precise control, like you can say rotate 10 degrees or the X axis and so on. But I don't want to go through this. I just want to show like one trick, very useful keyboard shortcuts are shift X, shift Y and shift Z, which basically orient you along the respective axis. So if I press shift Z now, I get a front of view of the image. And if I press shift X, now I get a side view of the image. And this always like this rotation into a defined orientation always happens around the position where your mouse pointer is. So for example, if I put the mouse pointer on this red thing here and then I rotate around using shift X, shift Z, shift Y then this red thing stays centered basically under the mouse pointer. So this gives you a nice way to look at stuff on different directions. Like let's go get a screen thing here. Okay. Okay. Okay. Tobias? Yeah. Can you comment on, so how do you put scale bar? That is basically an entry in a preference as filed it to make. I think I would type this in the chat label that takes too long to show it now. So basically it's just a file with some configuration options that you put somewhere. Okay. Thanks. If I forget this, can you, yeah, please revise it. Okay. Okay. So now let's open the bigger and a bit more interesting data set. This is now one which is stored in HDF five already. So I go here again from screen. Okay. So now this is a time series. So this is about 80 gigabits. This is a recording of philosophical analysis. And as you see, I can move through time now. So there's a time slide here that the data set has time points. And if I rotate, you also see, if you look at the map from the top here, you also see that the data set has multiple angles which I can look at individually or together. So I addressed a lot of shortcuts now to basically do this, like switch between the different sources, overlay them and so on. But there's also a nice UI to do this. So if you move your mouse to the side of the window here appears this arrow and then you can click in the appears a side bar. So we forget about this for now. And here you have options to basically configure what you see. Like you can switch the interpolation mode linear interpolation. You can switch between showing single sources or showing sources over late and so on. You have here a list of the sources. Where you can change, for example, which source is the current source. So the current source is the one that is displayed. If you have a secret source mode and if you have fuse mode and all the active sources are viewed and you can also basically activate and deactivate sources here. Below that list of sources, you have this area here where you can set colors and display range for each of the sources and you can select multiple sources if you want to change the display range and so on for each of them, for all of them. So when I have these or I could change basically, for example, I can change the color of just this one. Make this tree in and then maybe make this one a little bit wider and the other one is okay. So this area always acts on all the sources that are visible that are selected. And if you select several sources that have, for example, different display ranges, then this is basically this is illustrated by the background here turning red. So this gives you a hint that, okay, these sources at the moment have different display range. So if I change it, then changes it for all of them or that these sources have different colors now and different display ranges and adjust this all the same display range and all the same colors, okay. Okay, so that's maybe enough for the sources here. I need to look at the time a little bit. The final thing that I want to show you is this grouping here. And for that, I need to load yet enough or more complicated data set. One which has a lot of sources. So a data set with channels and tiles. This one, so here we have a data set if you look at the mini map on top of here which has a few tiles and then also to not see here directly is that each tile has three channels. But basically if I walk through the current sources, you can see, so now we have channel one of all the tiles. Now we have channel two of all the tiles, channel three of all the tiles and so on. Now it's for example, useful to group. Let me clean this up. These groups here can be used to do operations for multiple sources at once. So for example, we could say, okay, we take the first six sources and this is channel one. Okay, and then we take the next six sources and I can basically create new groups just by selecting sources and tracking them down here. So then this is channel two. Last channel, channel three. And then I can switch to group mode here. So we have in our single source mode and then we can switch to single group mode. And now basically you see not all the current source or not only the current source, but the current group. So it's the same concept here. Current group, I can change the current group. I click in here and then we enable all the sources in that group or I can do a fused group mode where I can turn off groups and overlay them. Okay. And below here, you also have, you also have the same like adjustment options as for the sources. And of course, now they act on all the sources in the group. So for example, I could make the first channel, make the first channel green, second channel red, yeah. There's a color truser on my alpha screen. So I'm not pulling it over every time. And the last one I turn through. And if I look at the sources again, now you see that basically all of these have turned green, all of these have turned red, and so on. I turn on fused mode, then I can overlay them. Okay. So this grouping is not exclusive, like a source can be in more than one group. So for example, I might want to take all the sources of the first time, all the channels of the first time and then make a new group of those on Taiwan. You can make type two, oops, okay. Okay, that did not work, sorry. But I mean, okay. I think you get the idea, right? So if I now switch again to a single group, I can now either say show all the tiles of the first channel or I can show all the channels of the first time and so on and I can basically configure configure our convenient groups this way. So of course you do not want to do this every time. So you can save these configurations as another XML file next to the one that contains the data set. If I do this, then if I reopen the file next time, it will be automatically present. I reopen the same file again, then of course on the wrong screen. I still have all these settings that I made again. Okay, and I think that end of my part, now I take some more questions if they're all. Okay, so here is one question that is say, so will there be a web version of Big Data Viewer? That's related to another question which is what would be the plan of your future development? That's another, from another question. Okay, there's a project called NeuroClancer which is kind of a web version of Big Data Viewer. It's not related, but it has similar ideas, but it's browser based. So that's something you could look at and then there's by ITK, there's a JavaScript visualization which I think is not yet suited for Big Data but could be extended to support it. So I don't think that I will make a web version of Big Data Viewer and if I would, then this would be basically a rewrite in JavaScript. So I don't think there's a lot of potential of like using Java to render stuff and then show it through a web browser. And I think that's kind of maybe a quick and dirty solution but I'm not so interested in pursuing that. And okay, and the second question was like future plans. I mean, one thing that's missing here clearly is like volumetric visualization, it's a volume rendering and that is also the current, currently ongoing thing that's like big volume fuel value into volume rendering on the GPU. And that's also included in Xifu, which is like the future standard 3D viewer thing in Fiji. So, and that is not complete. So there's some work that needs to be put there and maybe unify that under the same code base because a lot of stuff is parallel at the moment. And besides that, I think for the visualization side, there's not much more to do. So I think the interesting future work has to happen on the processing side, right? Okay. So we can reuse a lot of the infrastructure that we have built with ImageKit 2 is also very, very well suited for like processing data and distributing the processing and so on. But, yeah, somebody would have to put a few months of serious work into that. And yeah, that is one thing that might happen in the future. But I think like big data viewer itself is good as it is, there's not much work planned to improve it at this moment. Okay. So I think there are many more questions coming up but maybe we wait for this later answering from Tobias directly. We have two more sessions, so let's just continue. So next is Nicholas, which is, he will be talking about this playground of big data viewer, please. Yeah. Thank you, Kota. So, and thanks for the introduction. So I work at EPFL in an imaging facility and I will present you right now the big data viewer playground. So what is big data viewer playground? Basically, it's a set of Fiji plugin which are here in order to facilitate the use of big data viewer. And it does this in three main ways. The first thing it brings is a Bioformats compatibility layer. So it means that you won't need in some cases to rewrite your data in order to open it efficiently. And thanks to big data viewer, it brings lazy loading and multi-resolution support if Bioformats supports it. The second thing it brings is a user-friendly way in order to interact with many sources. So Tobias showed you the way that you have in the panel by default, but sometimes if you have thousands of sources, you may want to go beyond this. The third thing that is very important is that it's able to generate an XML dataset which will be compatible with other big data viewer plugins. So it can definitely be an entry point into the other plugins that Tobias mentioned briefly. And this can be useful for the following big data and Tobias seminar. So in order to get these functionalities, it's not core Fiji, but you just need to enable an update site, whose link is located here. And I also for the record put the link of the GitHub repository, which contains these functionalities. First of all, I would like to mention what means big data for us in an imaging facility because the obvious answer and the origin of a big data viewer was because we have this slide sheet data, but it's not the only sort of microscope which can give you big data. We also have eye content screening microscope which can generate thousands of images of sources. And we also have, and that's a major use case where I work at the buy up. It's some slight scanner data where people scan their slide and they end up with gigantic 2D images. So big data viewer playground can play a role in these three sorts of data set. But for the sake of time in this webinar, I will concentrate on a use case that concerns slide scanner data. And Tishi, in the third part of the webinar, he will present you big data processor which is more dedicated to light sheet microscopy data. Okay, so let's dive in and I will present you the use case which is the following. We have a user and I signed Bianca Silva from UNS Graph Lab at TPFL for providing us this nice data set. And basically she scanned a single mouse brand slice and she has like 88 brand slices scattered within 10 slides. And so it's a huge data set. And to put this in number, this data set represents 10 slides which corresponds to 88 brand mouse brand slices and each mount brand slice has four channels. If you were to uncompress all these data sets, this leads to around 110 gigabytes. Okay, so let's first mention if you want to do somehow this task with a normal image, this will probably look like this. So you have your VSI file and you will drag and drop the VSI file into Fiji. The bio format's importer window shows up. And then you see that you have many, many images that you can open which corresponds to the different acquisition and also to the different resolution levels that you can open. And in image one, you need to choose a resolution level for instance, this one which is only a thousand pixels. And it's fast but then it's pretty annoying because if you zoom in, then you are not seeing a lot of information. And what you need to know is that typically in this slide scanner data, you are perfectly capable in the DAPI channel of visualizing individual cells but here because we use a too low resolution level, we just don't see them. So in summary, if you want to use the normal image research data set, you are limited, I mean, one stack is limited to showing a single resolution level of a single acquisition of a single VSI file. Then you are losing your spatial context. You can see only one tiny part of the data and you can load a complete high resolution image but then it will be pretty slow and not super responsive. However, we need to mention that processing data in this case is pretty easy. So how does this would look like in Big Data Viewer Playground? So I prepared the data set. It's not really complicated but we gain a little bit of time by doing this. So it's this XML file here which I can open with Big Data Viewer Playground. I can also open it with a normal BDV, Big Data Viewer window but here I have a few other features which are loaded like brightness and contrast and color. And to do that, I click open XML BDV data set. Let's remove this one and I put this data set. So it's loading the data and the first thing that you will notice is that we do not get a display of the images directly but we rather have a tree view which here in brackets show the number of sources that are contained within this data set. And if I want to visualize this then I can just right click in here and I can open all these sources containing the data set in Big Data Viewer window. So I just click show sources. And now you see immediately that we have access to the slide scanner data. If I zoom in, well, it's not the most interesting part but if I zoom in then you can see the higher resolution being loaded at the time. So here we have a cellular resolution. Overlayed is at lower resolution, the overview. And we have directly the whole slide open and I even have other slides that are stacked on top of each other. Okay, so it's very easy to investigate and for instance, if I zoom in here I will see some cells, some fibers, axon or dendrites which are very bright into a certain fluorescent channels. And you see that I get all the context. Loading is happening on the fly while I'm zooming in. So it's very responsive and that the power of abstraction of Big Data Viewer. Now maybe you don't want to look at all the sources containing the data set. You want to focus on a certain fluorescent channel. And that's why you have this preview which is very convenient because then you can sort all these sources based on certain properties. And here, for instance, I have this channel node that I can expand and I can see that this data set has five different channels. And I know that the channel one corresponds to the DAPI sources. So I can just click on this node and I can click show in Big Data Viewer. And now I have position in space only the DAPI channel of all the slides. Even more, you can actually drag and drop directly from this preview into the Big Data Viewer window. So here for instance, if I want to see all the fluorescence channel, I can just take this four fluorescent channel because I know zero is a channel for the overview actually. I drag and drop. And now I have all the channels displayed here. Okay, so let me continue with the presentation. And this is for the record you will have in the slide the way in order to process sources, how to right click, navigate, display images and you can filter source can be filtered by channel in the tree view. So this is what I showed you. And it's not the only properties based on which you can filter your sources. For instance, you have the tile which corresponds to the individual acquisition. So if you select zero is the first overview, one will be the label to the right. And then the following numbers corresponds to the individual acquisition within your slide scanner data. So other conclusion for this part, if we compare image to big data with our playground, here you see that you can open and display all acquisition contained in several VSI files. They are positioned nicely in space. So you keep the special context. All acquisitions are open at once and the high resolution, you do not lose it. You just load it when you need it. The processing is a little bit more complicated but we can do stuff. And that's I think the goal also of these webinars. So as a conclusion, yeah, sort of weird conclusion, but image one is not so nice to work with world slide images. Big Data Viewer does a very nice job, but some of you may already know that Big Data Viewer is not the only one for slide scanner data. We have QPass which is doing a tremendous job in order to work with this slide scanner data. But here we are not competitors. We are rather complementary because QPass is more specialized for, let's say a few slices of a slide scanner data and it's super user friendly and absolutely perfect for quantification. But Big Data Viewer, which is somehow more generic is better in order to get the spatial, global spatial context of your slide. And also it brings support. You will see that later in other seminars. It supports non-linear transformation so you can do alignment of big images beyond a fine transform. So there is even an experimental support of QPass within Big Data Viewer. So you can open your QPass project thanks to Big Data Viewer playground if you want to try it, you can. So now let's get back to our use case which is, well, we want to reconstruct, sorry about the bar which is showing up. We want to reconstruct this mouse brand slice from world slide images. And there's a way to do this in Image-1 fully but here I will show you that we can integrate Big Data Viewer with Image-1 pretty conveniently. And so I will do the last part of the job. So stacking all the individual slice in Image-1. And to do this, it's actually fairly easy. And what I want to demo is that, so first I was able to select sources based on the tree view but in Big Data Viewer playground, there is an editor mode that you can activate by pressing the letter E for editor. And now I cannot navigate anymore but I can draw rectangles and select some sources which are of interest. So I can press Shift in order to combine our control in order to remove some slices. So here, let's say I want to remove the beginning and the end of the mouse brain. So I will just select these ones. And now because I've selected these sources, I have access to a contextual menu if I right click. And now I can open for instance in a new browser these sources or here what will interest me is to export from Big Data Viewer into Image-1. And in order to do this, there is this command which is show sources. And if I click it, I need to select which time point I want to export. So here it's like scanner days. I have only one time point. But more importantly, I need to choose the level of details that I want to export. So I need to choose a certain resolution and because it's Image-1, I want to export the highest resolution level. So the highest resolution level is zero but this will take a very long time to load. So here I will put the level five which correspond I think to about 100 pixels, x, y. And if I press OK, I need to wait a little bit and everything will show up as a normal Image-J images. And here we can just apply all the standard procedure from Image-J and here I will do, so I see, yes, I will do image stack tools, concatenate. And I will just concatenate. So by this, I need to be precise in my clicking. Okay. So I concatenate all open windows and if I adjust the contrast of, let's say, this slider, this channel, this channel, then you see that we have reconstructed a broad overview of the full mouse brand slice. Okay. Of course, what's a little bit annoying is that if we zoom in, then we don't have the high resolution as we would hope for. Okay. Just for the slice, I put some explanation of this workflow and also I put the way to access this editor mode and what you can do with it. And we'll see now how to proceed to this, let's say, stacking directly into BDV playground. And in order to do this, we need to stay into BDV playground. So let's keep these images and I will just make sure that the recorder is here because all this command that I show you can be recorded. So here, for instance, if I press E, I will select these single sources and here I'm capable of recent ring. So relocating the source in 3D. So if I press it, I can select the time point I want to relocate and the coordinate on the center XYZ in the global coordinate. So I will just put it at the global origin of our physical space. I press okay. And if I zoom out, let's try to find it. Yes, it's located here. So you see that these slides with the fourth fluorescent channel were relocated at the origin, as you can see here in the coordinate system of big data Vivo playground. Now this was recorded and it's not really complicated but I already made a macro which will allow me to relocate all the tiles from this data set. So here it's a very simple macro. I just run for all the tiles, the common recenter sources and I'm shifting the position in Z depending on the tile index. And this is actually the way to select the slices. So I can just indicate a path within these three view in order to say which one to source I want to operate on. So let's run it. And if I go back into big data viewer, then you will see that I did a mistake. I opened, I think, a 2D viewer. So let's right click show in a new window, okay. And now I can just navigate in Z and you see that I have all the slices stacked together. And now I can do mean and I can see very nicely all the cells within their 3D context. And because big data viewer is not restricted to 2D you can actually rotate this and now you can see the brain being reconstructed and visualize from the side X, Y, Z and of course this view is a bit nicer because this is where the acquisition was taken. So now of course the alignment is not really perfect because that's just a simple stacking. And here I would just like to mention that I'm working on another plugin which should be really soon which will allow you to go beyond this by doing some affine transformation of all individual sources and even going beyond affine transform, spline transform registry to reference brain like the allen brain Atlas and exporting regions identified in QPAS. So we expect this to be coming soon. So it's time to conclude and regarding my conclusion I think the two important point to remember from this part of the webinar is that with big data viewer and big data viewer playground you can interact and position many sources in 3D. Data resaving is not always necessary. So you see here, I directly open VSI file there was no resaving, it was perfectly fine. It's macro recordable and scriptable. And the last thing that I will point out again is that it's very easy with big data viewer playground to generate an XML data set that you can reuse for other plugins. And this I will do more very, very briefly. So I will just type bridge because I know my command is like this. So you need to open like bio formats, BDV bridge, the basic version. Here you can just drag and drop any file. So it can be a combination of any file supported by bio formats. It can even be a HCS high content screening data set. This works. You need to specify the physical units you want to operate on. Then I click okay. And now you see that in the tree view, so there was a former data set. And now there is another one which is not really named because it's not saved. And if I want to save this data set I can go again through the hierarchy, BDV data set, I can save it. And here I will put it to name demo.nobias.live.xml. And now this XML file can be open anywhere and big data viewer window. So like what Tobias showed you, you can use a standard Fiji image and it will just work. And not only in the standard viewer, but it will work also in the other modules of big data viewer that will be presented to you later on. With that, I would like to thank my supervisor Arne Zait who gave me the opportunity to work on this project. All the members of the imaging facility, my colleagues for image analysis, Clare, Olivier and Romain, especially OMA Romain because he's also part of the Noibias Academy organizers and all the panel and you for your attention. And with that, if there are some questions, if I'm not too long, then I think... Okay, thank you. There are several questions that we can, maybe some of them can be done in a forum or somewhere, but one that is asked by Cibra already is that will playground, this BDV playground, open slide scanner data in any format that Bioformats understands? I mean, there seems to be many different slide scanner formats, so I'm not working on these things, so I don't know about that. Yeah, I wasn't working with this until I discovered the biop that they generate a lot of data. So basically everything which is supported by Bioformats can be opened if your lucky and Bioformats supports your file and even multi-resolution, and this is specified in the Bioformats website, then you probably don't need to resave anything. Now I know that there are some libraries that are used in QPass, which I don't remember the name, but if it's not Bioformats, it will not be supported in BDV playground or not directly. Okay, so basically when you have some exotic format, you need to ask Bioformats guys if they can make it. I think now they turn the point when they are asking the company to pay the company so that they are supported by Bioformats, but there is this hope that we have a common file format where a Christian teacher that Christian mentioned before. Okay, next question is, so is it macro-recordable, the playground part? Yeah, so the actions are macro-recordable, in fact everything which appears when you right-click here has its equivalent into plug-in big data of your playground, and here you have a certain number of operations, and this is macro-recordable, and so when I right-click and I execute an action, like here I can flip along X, then this is actually recorded. Very good. So third question is, yeah, it might be a bit general. Do you think it could be useful to integrate big data viewer with data management system like Omero? Yes, that would be absolutely awesome. So as Tobias mentioned, the back-end can be modular, so what we would need is Omero back-end in order to read the data. This is something that is supported in QPASS, and I hope that in a future plan either us or somebody else makes Omero compatible with big data viewer, and since Omero I think supports everything that Bioformats supports, then you would just avoid working with local data sets. So I hope so. So just to conform as a question, but this plugin is available via update site? Yeah, it's available via an update site. It's rather experimental, so it may break some other stuff, and we are working on it in order to make it a bit more stable over the coming months. And then there was also kind of a specific question about this registration, so you did it beer exporting to EMAJ and then doing, but is there any plan of adding this kind of registration algorithm that you said that you were developing? Yeah, so I mean you can perfectly apply any affine transform to these sources, and then you keep something very fast. You can apply spline transformation, so there is big warp. So it's always, yeah, I'm not sure, I think I forgot your question, but there are things ready. Now we need to make things user friendly, I would say. Yeah, I mean I think the question is that when you drag and drop those files in the playground interface, would there be kind of this automatic registration process which actually aligns these things automatically or something? Yeah, so yeah, there are plugins, there are options, and I think the Salfed Lab is working on this. And me for my part, I'm just reusing software components, so for the plugin I'm developing, I'm using Elastix, which is a well-known library. Okay, good. I think we are running time behind already 15 minutes, so maybe if there's a kind of global questioning, everything after all three guys finish, we can come back. So thanks a lot, Nikola. Welcome, thank you. So now it's Tishi. He's saying that he has unstable network, so how is it so far? Okay, so far good. Okay, so please, Tishi. Okay, can you hear me and see my slides? Yeah, yeah. Good, okay, so I will talk about big data processor 2, a free and open source Fitchi plugin for inspection and processing of terabyte-sized image data. And here you can see the author list, so we hope this will be a publication soon. And so this is also my acknowledged slide. Thanks to everybody on there and what you see, there's also a big list of people below, and these are actually mainly people that already used it. So this is already around for a while, and has been used by a couple of people, and they have all provided very valuable feedback. So thanks to all of them. So what was the motivation? So I'm working at EMBL in the light microscopy facility, and at some point, several of you I guess got a light sheet microscope. In our case, it was a Luxendo microscope, and what this microscope outputs, you can see here on the left, it's basically a bunch of HDF5 files, one per channel and time point. So here it's like two times 143 time points, adding up to 240 gigabyte of data. And that was it, and then what do you do with this, right? So we needed something that our users could conveniently go on from there. So just to again reiterate the problem, you can actually open one of them in Fiji with this Fiji file import HDF5, but just loading one of them from an external hard disk already takes nine seconds, then you just have loaded one. So I mean, you can look at it, but it's a bit annoying. So what we wanted is a convenient way for our users to inspect these data sets, to apply a few simple processing steps, and then resave the whole data in a relatively more accessible format than this. So we started working on this 2016, and the first version is now called Big Data Processor 1. So there I made use of good old ImageJ, the virtual stack that some of you might know. But then at some point I got to know Imlib 2, and I realized that all of the things I'm doing here are much easier in ImageLib 2 because it's really made for it. So we decided then in 2018 to re-implement the whole thing, and this is the Big Data Processor 2 plugin. They are both available via the same update site, Big Data Processor, and then you can use 1 and 2. I recommend using 2 because that's the one that's currently further developed. So this is the user interface. You have a menu, and I will now talk shortly about the open process and save menu, and then I will give a short demo. So in terms of opening in a nutshell, we currently support opening everything that's based on TIF or HDF5 image file series, and there we also put a lot of effort on opening these file series fast. But now thanks to Niko's great library, we can also open everything that you can open with Bioformance. In terms of processing, there is this menu. So there's a bunch of options, and I will go through them now through a few. So one thing is you can bin your data set. And the interesting thing is you can do this interactively. So you can try out different binnings and see whether they would still work with your data. You may now think, hmm, binning. This is not so awesome why I'm looking at this webinar, but if you ever try to bin a 240 gigabyte data set, you see the problem. So you don't want to really do this. So the good feature about this plugin is that it does is lazy. That means it does it only on the slides that you currently look at, but you can still browse through the whole data set. So it's fully interactive. Another thing you can do is you can crop your data set, because sometimes you acquire more data than you need. Then you can interactively correct channel shifts. So if you see here on the left, actually the magenta and the green channel are a bit off, and then you can move them around until they fit. Then some systems you acquire both color channels on the same camera chip. So here you can also interactively then choose two regions of interest and overlay them and basically make out of a one color image, a two color image. And again, you can preview all of this before you really apply it to your whatever 200 gigabyte data set. You can really make sure, okay, this is the right settings, because we had often the case that people had noted down wrong regions, and then it's really annoying if you have to redo this for big image data. Then what's also becoming now more and more is the single objective fly cheat microscopes. So then the data that you get is initially skewed. So because it's a non orthogonal acquisition modality, so you can interactively just type in an affine transform to make the whole thing straight. And again, the whole point of this plugin is you visually check that it's correct before you really apply it. And then finally, you can also correct sample drift. And in the easiest case, it's just a two click thing. So you go to the first time point, you click on the reference to the last time point, you click on another reference, and then it will linearly interpolate like a drift correction. And then you can apply this. So these are the main processing options. In terms of saving, what we currently support is again, TIFF and HDF5. For TIFF, it can be stacks or planes. And for HDF5, we support a chunk multi resolution format like something that Tobias was talking about in the beginning. I will talk about it in more detail later. Good. Then I will go to my demo. So here I have Fiji. And then it's plugins, big data processor. And as I said, I use the number two. So I get this menu. And then first of all, again, this is macro recordable. In several languages, I will do macro now. Then let's open a data set. Here's some convenience functions to open things that occur more often. So for us, for example, this Luxendo HDF5 data set. And this is this 240 gigabyte data set, which actually sits next to my laptop right now on an external hard disk. So the connection to the hard disk is not so fast. So that's also interesting to see what happens. So you can load both channels. Okay. And this maybe took now five seconds to open the whole thing, which is actually quite nice. 250 giga? Yeah. So here you can see the size. And I mean, the good thing about why this is kind of good is because this is not saved in anything that's made for being open fast, right? There's no multi resolutions. There's no chunking. This is just like tip stacks more or less, but then HDF5. You can move around. So basically I can go to the last time point and you always see it takes a bit, right? It has to load the data from the disk. That's why it's black for a while. Okay. Let's adjust the brightness and contrast a little bit and the slice where there is something maybe here. All right. Maybe like this. So the first thing when you zoom in here is you realize there's really a lot of noise and a lot of pixels. And the issue was with this microscope, you couldn't adjust the binning on the camera while acquisition. So here I would argue it definitely makes sense to bin this data set because it will both reduce the size and the noise. So I will do this. And as I said, you can now just play around with different options of binning. And for example here, I would say a three by three binning looks nice. Again, you can zoom out or you can check in other time points whether this binning is something that you like for answering your biological question. Then if you are convinced this is a good binning, you say, okay. So now we have binned the data set. And unfortunately now lost the good set plane where I can see we have to live with this now. So there's also a channel shift, right? So this green stuff should actually sit in this slightly dimmer magenta region. So we can also then interactively move the data around and see if it gets better. So this is worse. Now we have a bigger distance. I tried this out before. So this is now fitting nicely. And also in this direction, there might be a small shift. So I will also shift it a little bit down. Okay. So we have now corrected the channels. And then finally, you see there's a lot of region that is useless so we can crop this. And this is this beautiful cropping tool that Tobias recently made. So you can interactively move around here. You also want to check if this crop is good for the whole time series, right? So we go to the last time point and we see in fact the sample moved here a little bit. So we make it a bit larger that we capture the sample for the whole time point. For the, yeah, for that it's in all time points in the crop region. Now along the Z direction, we also have to choose a region. And now comes the trick that Tobias showed. So if you press shift X, it will show you the data from the site. And here you're also, it's kind of instructive. You see now this takes actually some time because it has to load now from this time point all the set planes. But here I can already see that this is, I mean the sample starts here. So this is probably quite good. Oops. And then I will now not wait for the sake of time to see where the other end is. So if you have a far as faster heart, this will be also much faster. I have really a super optimal setup here right now. So I go back to this plane. So we have to find our crop. I say, okay. And then we have now our data set which I would argue is now much nicer than before. And what's amazing is if you look, so also here I predict the size of this data set always if you were to save it, it's only five gigabytes. And it was 240. So that's actually something we just learned when we did this exercise. It's pretty amazing. I mean a three by three binning is already a factor of nine. So that's a lot. And then if you crop, this was again a huge factor here. So you kind of sometimes can solve your big data problem by just a bit of processing. Okay. Now it definitely makes sense to resave this because this is much nicer to work with. So as I said, we support here a bunch of options. So I'll just show one. We support different compressions. And also we support that you don't save the whole thing and I will do this now because this will take a long time. Another important thing is there's also this button to only record the savings. So why would you do this? So actually here's the macro. So you wouldn't really do it. You just record a script. And the reason for this is you could then use this script and run it on a computer cluster and then basically run it multiple times and always running it on different time points. So in this way you can in parallel do the whole thing. So if you have really big data, this might be nice. And if you have a computer cluster, so we did that for some data sets. And then you have already the script that you can use on your cluster. Okay. But I will now start to saving. And now it has to think a little bit about it. And I think I get the first feedback when it saved the first time point. And again, now this is the moments where you start to realize, oops, this was a 240 gigabyte data set. So things actually take a bit of time. So here, for example, it took now 20 seconds to process the first time point. And then probably we have to wait another 20 seconds. It's kind of funny when I practice it, this was only 10 seconds. Something is now much slower on my computer than it was this morning. I don't know what, but that's if you do a live demo. Okay. So now it's done. All right. So this is this. What I quickly want to show is that this whole thing, as I promised, is macro recorded. So I will comment out the save as. And if I now run everything we did, it opens it, it bins it, it does the channel alignment, and it does the cropping. Okay. And that's kind of nice also for documentation purposes, right? Then you can keep the script somewhere and you always know what you did. Okay. Then finally, I want to show a little bit how you can go on from here. So I prepared some of these output files. So this is how it looks like what we did just now. So you have one TIFF stack per volume. So the easiest thing you can do is you just drag and drop this thing onto Fiji. And usually one channel and one time point are not so big. Okay. So that's actually why this is a nice file format because these things are usually manageable. Okay. So you can work with this. You don't need anything special. This is just a normal TIFF stack. You just have to then write some loop across everything. Yeah. So that's one option. Another thing that's really awesome and that I learned about actually only some time ago. So bio formats, if you click on just one of these files, it has this awesome option group files with similar names and use virtual stack. So this is a really cool thing if you have big data in that format because it automatically finds out for you that there is a certain pattern in these file names and opens all of them correctly as a hyper stack. And it does this lazy. Okay. So this is the mid-stay virtual stack. So this would work for a terabyte. It might take a while to parse all these TIFF files though. But in principle, that's pretty cool. The other output file format that we support are these HDF5 files. So I also want to show what you could do with them. So in Fitchi, if you just say file import HDF5, you can, for example, load again just one of them, one channel and time point. And here you see also, you saw this several times. So this is what Tobias called file system in the file, I think, right? So this is as a bunch of stuff in this HDF5 file. So these are the different resolution levels that we saved. And you can then decide which one to load. So I will just load out the highest resolution level. And then, again, you have your data. However, what I also here saved is just one really small HDF5 file with the ending IMS for Imaris. You see it's only 18 kilobyte and a really awesome feature of HDF5 is you can link from this file into all these other files pretending they are inside of it. So that means you can now open the whole thing just with this one header files and you can actually do this with the data viewer because it has an Imaris open option. So we can do this and I have to just the brightness and contrast. And I made somewhere a note to which settings, but of course now I don't find it. Okay, anyway, let's try. Okay, here you see something. And now, because this is now actually saved in a multi-resolution junk format, you can do these fancy things of just slicing in 3D. And also, if I press now shift X, it takes no time because this is now a file format that's made for this. So you can look at the same speed at this orientation then at this with the data that I showed initially. It was really fast to load a set plane like this, but was super slow to load like this. And this is essentially the difference that you have depending on how you save your data. And you could also, in fact, and I can quickly do it, if you have Imaris, and there's also a free viewer now, by the way, that you can just download, you can also open the whole thing in Imaris and then go on from there. So here you have your data set. So this is a pretty flexible format, actually. You can go on in Fiji in Imaris or some other software by interacting with these files. But I think quite popular indeed is also this. And as I said initially, let's hope we as a community can agree on something that I just have to save one file format here. Okay. I think that's it. Thank you. I can take questions. Thank you. There was a question concerning this exporting format. So you did it with TIFFs. Can you export with other formats? Yeah, as I just said, I support only this, either TIFF stacks, so a bunch of TIFF stacks or a bunch of multi-resolution HDF5 stacks. So multi-resolution means pyramid or OME TIFF, is it same? Okay. Good. So this is answered. And then next question is, so you're doing this registration manually in a sense, I mean, with adding markers. Do you plan to implement something automatic? I could. So in principle, adding new processing options is relatively easy and it's even now the code is in the way that if the person that asked the questions can write a bit of MlipTool, they can do it themselves. I don't have any concrete plans, but it's an obvious thing that one could add. So I mean, if you really need this, contact me. So in a sense, it's like, great. Please develop and push. Okay. So there's some question that is a bit uncertain, but could we correct the multiple drift and same dataset? My zebrafish move in a bit in XYZ. So multiple drift probably means in three different directions, I guess, but you can. I mean, the thing is 3D. So that is one answer. Maybe that's the answer. So maybe. Okay. So there's also a question about whether this corrects also in Z and then apparently it does. I think time is already 11 minutes past. So maybe we can go for a bit more the overall question about three, all of you, Tobias, Nicholas, and Tishi. There was a kind of a overall question about what is the resource, web resource documentation that would be the best entry point in a web where you can actually access all these usages and everything. Is there any recommendation for this? So for big data viewer, background, maybe I can try to answer. I think there is the image J.net website, which at the moment that there's some transition phase. So I think that's why most of us like Nico and myself didn't add anything there yet because there are some, you know, we have to wait till this works again. But I think this image, I don't know, Tobias, what do you think Tobias knows? Okay, he's noted. Yes, yes. That's like image J.net is the big key and then it's image J.net slash big stitch slash big wall and so on and so on. So like many of the tools have their own Viki page, which is which is partially very detailed. Like for big data viewer, there's a lot of content. It's not 100% up to date because of the issues that Gigi mentioned. So it's read only at the moment during this transition phase. But also for big stitch, so there's a lot of content and so on. So I think the question is probably, somehow I shared the same impression, but you know, if there could be a one single page where actually it's like a hub of all this ecosystem where you access this and then depending on the needs and what you want to do, I mean, there could be a kind of switchboard page where a single switchboard page for big data viewer could be good. I mean, honestly, I was actually kind of hoping that, I mean, one motivation I had for this webinar series was that maybe once we all gave these talks, we all feel like maybe a little kickstart to saying there is actually an ecosystem now. Let's make it, I don't know. I mean, it was like a hidden agenda. I have a bit, but it's always question of time of people. Okay, good. Next question. In general, for big data storage and access, this is a good sentence. In general, for big data storage and access, do you have any recommendations or how to guide for newbies? Where is it? Also, big data can also be in TIF format. Will BDB, BDBG, and BDB2 open it? Sorry, maybe I missed during the webinar, but I think it is a kind of overall question about what would be the, let's say that, I mean, if there could be a short comment about what would be the storage access, like in Tishy case, he's using a portable hard disk. What would be the kind of optimal configuration and so on? Maybe there could be a guideline somewhere, or could you answer to it? No, okay, okay. I think it's a very general question. So it's really hard. What BDB brings is once you've dealt with this issue, then you can apply basically anything. Now, depending on the use case, they are too varied. So Omero server works nice for gigantic data. There is this cloud storage in which I'm not experienced. Now the output of a microscope can be gigantic TIF files. And just you will need to spend a little bit of time to define your data set representing by an XML file. And then you can just work with it directly. Now, I'm no expert in transfer speed depending on the architecture. So I cannot answer this. Yeah, yeah. But I mean, for example, for us, we several types shared like light sheet data, which was recorded in January by sending a hard drive, actually, by the mail. Because yeah, I mean, if you ever try to transfer a terabyte over FTP or something, just unrealistic. I want to maybe add for the TIF files. We can do that. Like there is a big data of your back end for TIF files, but you have to have this XML file which references the TIF files. And you can most easily make this with big stitcher. So I would watch the webinar next week, maybe. I'd say as a kind of user side opinion would be that if there could be a kind of a diagram, you know, all these big stitcher and all these things. And then there could be a diagram saying that what type of input is available and then what type of output is available. Maybe, I mean, if you organize this, you might even find that there's something missing. So this access input-output organization probably have one good view, might be very good. So next question is, can I use GPU for processing? I mean, does GPU, how much GPU matters with these all these visualizations are hard? Of course, I mean, if you have a gaming GPU, it's faster. Could you answer on this hardware again about these aspects? One of you, anyone? Yeah, Nicholas. Yeah, I was asking to Tobias that maybe he could discuss. But okay, my two cents on this is that for visualization, GPU is supported in the module called BigVolumeViewer. So that's why Tobias, I think, he knows more about this. And now there is also the plugin called SciZoosenary where they are leveraging BigVolumeViewer in order to put more complex scenes. So this is for the display part. Now, for the processing part, you need to perform some filters and so on. You can just stream any block, any cache and send it to the GPU, perform some processing and get it back. And I think with the lazy loading and processing, this can work, even if I'm not experienced in this case. Okay, yeah. Oh, I think, well, okay. Sorry, yes. Sorry. For GPU processing, the CLIJ project by Robert Haas is very interesting. And recently, I know that Stefan Zalfeld made a demo of very dusted streaming, like having a cached image, a tool image, where basically, if you need a block, it's obtained by some bag and put it put on the GPU process there and then put back into the image lit 2 image. So that in principle works, but it's in its infancy. Okay, so it's not the whole smooth combination, but if you put it here, put it here, you can combine. Okay, so there's a question. I wanted to ask also again, my original question, is there a way to open up a set of TIFF Z stacks, representing time points in bio formats, and then open it up in big data processor too? Tishi? Yeah, I'm not sure. I think that's what I... Yeah, the answer, I think the answer is yes. Yes, I think it's yes. Okay, so again, I mean, so I think people want... There's another question about this, what would be the guideline? So people want to hash, see the... How to say, kind of this typical workflow of how you actually have access to your own big data, and I think it's include visualization and also processing that you show. It might be very viable to have something, but I think it's still not so organized, I would say. I mean, okay, maybe just one sentence. I think the big data of your playground project of Nico was a bit along those lines. I mean, like, kind of integrating everything somehow and making it more accessible. And I, as I said, I feel maybe after we have watched all these seminars, maybe, I don't know, maybe we have some clever idea to make this like a more, like a one entry point ecosystem than a 10 entry point ecosystem. I mean, I don't know, but it could be nice, yeah. So Tishi, you have responsibility to organize. I can host the hackathon, but people have to come. Okay, so let's finish because we passed already 20 minutes. And then let's finally thank all the speakers, Tobias, Nicolas, and Tishi. From the wall. Okay, thank you very much. Is there anything, Julian? Nothing? Finito? I think we're fine. I mean, in the end, we'll try to make the speakers answer all the questions in the written form in the forum. So even though they answered live, you will find an answer, say within one or two weeks in the image.sc forum. So stay tuned in image.forum.image.sc. So thank you very, thank you all for attention and participation. And then maybe you could also still put some questions in the forum in the web. Okay, so thank you very much and bye-bye. Have a nice evening.