Merge branch 'master' into spinboxui

docs/source/_static/css/util.css

@@ -2918,3 +2918,47 @@ iframe {border: none;}
 	right: 0px;
 	bottom: 0px;
 }
+
+/* Grid */
+.grid {
+	display: grid;
+}
+
+/* Gaps */
+.g-gap-2 {
+	grid-gap: 2em;
+}
+
+/* Columns */
+.g-col-3 {
+	grid-template-columns: repeat(3, 1fr);
+}
+.g-col-2 {
+	grid-template-columns: repeat(2, 1fr);
+}
+
+/* Rows */
+.g-row-2 {
+	grid-template-rows: repeat(2, 1fr);
+}
+
+/* Spans */
+.g-span-2 {
+	grid-column: span 2;
+}
+
+/* Mobile section */
+@media only screen and (max-width: 600px) {
+	/* Columns */
+	.g-m-col-2 {
+		grid-template-columns: repeat(2, 1fr);
+	}
+	.g-m-col-1 {
+		grid-template-columns: repeat(1, 1fr);
+	}
+
+	/* Rows */
+	.g-m-rows-3 {
+		grid-template-rows: repeat(3, 1fr);
+	}
+}

docs/source/_static/vendor/display-card.css

@@ -56,6 +56,15 @@
   margin-right: 12px;
 }
 
+@media only screen and (max-width: 600px) {
+  .h-card__title-icon {
+    width: 15px;
+    height: 15px;
+    filter: brightness(0) invert(1);
+    margin-right: 8px;
+  }
+}
+
 .h-card__title {
   font-weight: 600;
   color: var(--colorPrimaryDark);
@@ -64,6 +73,13 @@
   margin-bottom: 10px;
 }
 
+@media only screen and (max-width: 600px) {
+  .h-card__title {
+    font-size: 12px;
+    color: white;
+  }
+}
+
 .h-card__data {
   display: flex;
   flex-direction: column;

docs/source/_static/vendor/tabs.css

@@ -21,6 +21,18 @@
     margin: 30px 0;
 }
 
+.tabs-info {
+    font-size: 16px;
+    color: #4a4a4a;
+}
+
+@media screen and (max-width: 600px) {
+    .tabs-info {
+        font-size: 12.8px;
+        font-weight: bold;
+    }
+}
+
 .visualization, .data-science, .scientific-domains, .machine-learning, .array-libraries {
     max-width: 900px;
     margin: 15px auto;
@@ -43,14 +55,18 @@
     font-weight: 500;
     color: rgb(108, 122, 137);
 }
+.uk-tab > .uk-active > a {
+    color: var(--colorPrimaryDark) !important;
+    border-color: var(--colorPrimaryDark) !important;
+}
 
 @media screen and (max-width: 600px) {
 
     .uk-tab {
         margin-left: 0 !important;
     }
 
-    .uk-tab> .uk-active > a {
+    .uk-tab > .uk-active > a {
         border-color: var(--colorPrimaryDark) !important;
         color: var(--colorPrimaryDark) !important;
     }
@@ -106,40 +122,41 @@
     }
 }
 
-.grid-container {
-    display: grid;
-    grid-template-columns: auto auto;
-    grid-gap: 20px;
+/* Visualization */
+.visualization-images img,
+.visualization-images a {
+    border-radius: 10px;
 }
 
-.grid-container > div {
-    /* White, with 80% opacity */
-    background-color: rgba(255, 255, 255, 0.8);
-    text-align: middle;
+.image-grid > div {
+    background-color: rgb(0, 0, 0);
+    border-radius: 10px;
+
+    display: flex;
+    align-items: center;
+    justify-content: center;
+    flex-direction: column;
+
+    box-shadow: rgba(0, 0, 0, 0.35) 0px 5px 15px;
 }
 
 @media only screen and (max-width: 600px) {
-    .grid-container {
-        display: block;
+    .image-grid > div {
+        min-height: 150px;
     }
 }
 
-/* Visualization */
-.visualization-images > img {
-    border-radius: 10px;
+.molecular-band {
+    padding: 30px;
+    background-color: white !important;
 }
 
-.image-grid {
-    display: grid;
-    grid-template-columns: auto auto auto;
-    grid-gap: 10px;
+.image-description {
+    color: black;
 }
 
-.image-grid > div {
-    background-color: rgb(238, 238, 238);
-    border: 2px solid rgb(255, 255, 255);
-    border-radius: 10px;
-    padding: 10px;
+.image-grid > div:hover {
+    box-shadow: rgba(255, 255, 255, 0.1) 0px 1px 1px 0px inset, rgba(50, 50, 93, 0.25) 0px 50px 100px -20px, rgba(0, 0, 0, 0.3) 0px 30px 60px -30px;
 }
 
 /* Scientific Domains */

docs/source/posts/2023/2023-06-27-week-4-tvcastillod.rst

@@ -0,0 +1,30 @@
+Week 4: First draft of the DTI uncertainty visualization
+========================================================
+
+.. post:: June 27, 2023
+   :author: Tania Castillo
+   :tags: google
+   :category: gsoc
+
+What did I do this week?
+------------------------
+
+`#PR 810: DTI uncertainty visualization <https://github.com/fury-gl/fury/pull/810>`_
+
+I made a second PR with the implementation of DTI uncertainty calculation and visualization. Below is an image of diffusion tensor ellipsoids and their associated uncertainty cones.
+
+.. image:: https://user-images.githubusercontent.com/31288525/254747296-09a8674e-bfc0-4b3f-820f-8a1b1ad8c5c9.png
+    :width: 530
+    :align: center
+
+I had to use some **dipy** functions, specifically: `estimate_sigma <https://github.com/dipy/dipy/blob/321e06722ef42b5add3a7f570f6422845177eafa/dipy/denoise/noise_estimate.py#L272>`_ for the noise variance calculation, `design_matrix <https://github.com/dipy/dipy/blob/321e06722ef42b5add3a7f570f6422845177eafa/dipy/reconst/dti.py#L2112>`_ to get the b-matrix, and `tensor_prediction <https://github.com/dipy/dipy/blob/321e06722ef42b5add3a7f570f6422845177eafa/dipy/reconst/dti.py#L639>`_ for the signal estimation. The details of this calculations can be found `here <https://onlinelibrary.wiley.com/doi/full/10.1002/mrm.21111>`_.
+
+What is coming up next?
+-----------------------
+
+I will continue working on the uncertainty PR which is still in its early stage, I'm going to make a couple of adjustments to the description of the parameters and the actor, and keep working on based on the feedback I receive. There are also minor details to be discussed with my mentors about the first PR, which I hope to finish refining.
+
+Did I get stuck anywhere?
+-------------------------
+
+It took me a while to make the PR because I had some problems with the uncertainty function definition. I tried to use the least amount of parameters for the function, since with data, bvals and bvecs it is possible to obtain the rest of the parameters needed to generate the cones, which led me to readjust some calculations from the base implementation I had, to keep everything working correctly.

docs/source/posts/2023/2023-07-01-week-5-praneeth.rst

@@ -0,0 +1,28 @@
+Week 5: Trying out PRs and Planning Ahead
+=========================================
+
+.. post:: July 01, 2023
+   :author: Praneeth Shetty
+   :tags: google
+   :category: gsoc
+
+
+What did you do this week?
+--------------------------
+Due to ongoing exams, my productivity was limited this week. However, I managed to find some time to explore and review a few PRs submitted by contributors:
+
+1. Ellipsoid PR `#791 <https://github.com/fury-gl/fury/pull/791>`_:
+   This PR focuses on creating a new ellipsoid actor defined with SDF and raymarching techniques. 
+
+2. Website Improvement PR `#812 <https://github.com/fury-gl/fury/pull/812>`_:
+   This PR includes changes for the new compatibility section on the FURY home page.
+
+Towards the end of the week, I had a meeting with my mentor. We discussed the current status of ongoing PRs and identified action points to focus on in the upcoming weeks. This discussion provided clarity on the challenges faced with certain PRs and issues.
+
+Did you get stuck anywhere?
+---------------------------
+Fortunately, I didn't encounter any major roadblocks or challenges that hindered my progress this week.
+
+What is coming up next?
+------------------------
+With the action points provided by my mentor, I will be dedicating the next week to completing those tasks.

docs/source/posts/2023/2023-07-03-week-5-joaodellagli.rst

@@ -0,0 +1,77 @@
+Week 5: All Roads Lead to Rome
+==============================
+
+.. post:: July 03, 2023
+   :author: João Victor Dell Agli Floriano
+   :tags: google
+   :category: gsoc
+
+
+Hello everyone, time for another weekly blogpost! Today, we will talk about taking different paths to reach your objective.
+
+Last Week's Effort
+------------------
+After having the FBO properly set up, the plan was to finally *render* something to it. Well, I wished for a less bumpy road
+at my :doc:`last blogpost <2023-06-26-week-4-joaodellagli>` but as in this project things apparently tend to go wrong, 
+of course the same happened with this step. 
+
+
+Where the Problem Was
+---------------------
+Days passed without anything being rendered to the FBO. The setup I was working on followed the simplest OpenGL pipeline of rendering to 
+an FBO:
+
+1. Setup the FBO
+2. Attach a texture to it's color attachment
+3. Setup the shader to be used in the FBO render and the shader to render the FBO's Color Attachment
+4. Render to the FBO
+5. Use the color attachment as texture attached to a billboard to render what was on the screen
+
+But it seems like this pipeline doesn't translate well into VTK. I paired again on wednesday with my mentors, Bruno and Filipi, to try to figure out 
+where the problem was, but after hours we could not find it. Wednesday passed and then thursday came, and with thursday, a solution: 
+Bruno didn't give up on the idea and dug deep on VTK's documentation until he found a workaround to do what we wanted, that was retrieving a 
+texture from what was rendered to the screen and pass it as a texture to render to the billboard. To do it, he figured out we needed to use
+a different class, `vtkWindowToImageFilter <https://vtk.org/doc/nightly/html/classvtkWindowToImageFilter.html>`_, a class that has the specific
+job of doing exactly what I described above. Below, the steps to do it:
+
+::
+
+   windowToImageFilter = vtk.vtkWindowToImageFilter()
+   windowToImageFilter.SetInput(scene.GetRenderWindow())
+   windowToImageFilter.Update()
+
+   texture = vtk.vtkTexture()
+   texture.SetInputConnection(windowToImageFilter.GetOutputPort())
+
+   # Bind the framebuffer texture to the desired actor
+   actor.SetTexture(texture)
+
+This is enough to bind to the desired actor a texture that corresponds to what was prior rendered to the screen.
+
+
+This Week's Goals
+-----------------
+Having a solution to that, now its time to finally render some KDE's! This week's plans involve implementing the first version of a KDE
+calculation. For anyone interested in understanding what a Kernel Density Estimation is, here is a brief summary from this 
+`Wikipedia page <https://en.wikipedia.org/wiki/Kernel_density_estimation>`_:
+
+
+   In statistics, kernel density estimation (KDE) is the application of kernel smoothing for probability density estimation, i.e., a 
+   non-parametric method to estimate the probability density function of a random variable based on kernels as weights. KDE answers a 
+   fundamental data smoothing problem where inferences about the population are made, based on a finite data sample. In some fields 
+   such as signal processing and econometrics it is also termed the Parzen–Rosenblatt window method, after Emanuel Parzen and Murray 
+   Rosenblatt, who are usually credited with independently creating it in its current form. One of the famous applications of 
+   kernel density estimation is in estimating the class-conditional marginal densities of data when using a naive Bayes classifier, 
+   which can improve its prediction accuracy.
+
+This complicated sentence can be translated into the below image:
+
+.. image:: https://raw.githubusercontent.com/JoaoDell/gsoc_assets/main/images/KDE_plot.png
+   :align: center
+   :alt: KDE plot of 100 random points
+
+That is what a KDE plot of 100 random points looks like. The greener the area, the greater the density of points. The plan is to implement 
+something like that with the tools we now have available.
+
+Let's get to work!
+

docs/source/posts/2023/2023-07-03-week-5-tvcastillod.rst

@@ -0,0 +1,22 @@
+Week 5: Preparing the data for the Ellipsoid tutorial
+=====================================================
+
+.. post:: July 03, 2023
+   :author: Tania Castillo
+   :tags: google
+   :category: gsoc
+
+What did I do this week?
+------------------------
+
+During the weekly meeting with my mentors, there was a small discussion over the naming of the actor and its usage. On the one hand, although the purpose of the actor is to visualize diffusion tensor ellipsoids, the idea is that it can also be used for any other type of visualization that requires the use of ellipsoids, so in the end, we decided to keep the name *ellipsoid* as it is more generic. On the other hand, as there is already an actor made for the purpose of tensor visualization, namely `tensor_slicer <https://github.com/fury-gl/fury/blob/e595bad0246899d58d24121dcc291eb050721f9f/fury/actor.py#L1172>`_, it might not be obvious how and why one would use this new ellipsoid actor for this purpose, thus it was proposed to make a tutorial that can clarify this. The main difference between both actors relies on the quality and the amount of data that can be displayed, so the idea is to show the difference between both alternatives so the user can choose which one to use depending on their needs. To prepare the tutorial the first step was to `add the data <https://github.com/fury-gl/fury-data/pull/12>`_ I will use on `fury-data <https://github.com/fury-gl/fury-data>`_ so I can then fetch and load the datasets I need to work on the tutorial.
+
+What is coming up next?
+-----------------------
+
+I need `#PR 791 <https://github.com/fury-gl/fury/pull/791>`_ to be reviewed by my GSoC fellows at FURY, so I will address their comments, and additionally make adjustments on `#PR 810 <https://github.com/fury-gl/fury/pull/810>`_ based on the feedback I receive. I will also start working on the tutorial, the idea is to show the use that can be made of the ellipsoid actor in the visualization of diffusion tensor ellipsoids, compared to the *tensor_slicer* actor. I plan to create a WIP PR to start getting feedback on the general structure of the tutorial and the way everything will be explained.
+
+Did I get stuck anywhere?
+-------------------------
+
+I did not encounter any obstacles this week.

docs/source/posts/2023/2023-07-08-week-6-praneeth.rst

@@ -0,0 +1,26 @@
+Week 6: BoundingBox for TextBlock2D!
+====================================
+
+.. post:: July 08, 2023
+   :author: Praneeth Shetty
+   :tags: google
+   :category: gsoc
+
+
+What did you do this week?
+--------------------------
+This week, I worked on improving the **TextBlock2D** component in the UI system. I started from scratch to address alignment and scaling issues. When resizing the **TextBlock2D**, the text alignment and justification with the background rectangle were inconsistent. To resolve this, I introduced a new "boundingbox" property that calculates the text bounding box based on its content. Additionally, I separated the scaling mode from the resizing action with the new "auto_font_scale" property, enabling automatic font scaling according to the bounding box. This will provide better alignment, justified text, and smoother font scaling for the **TextBlock2D** component. Try it out at `PR #803 <https://github.com/fury-gl/fury/pull/803>`_.
+
+.. image:: https://github.com/fury-gl/fury/assets/64432063/94212105-7259-48da-8fdc-41ee987bda84
+   :align: center
+   :alt: TextBlock2D will different justifications
+
+As discussed last week, we also made a decision regarding the scrollbar. After exploring different use cases, we concluded that creating an independent scrollbar is not necessary at the moment. Therefore, we will close the related pull requests. You can find out more about it in the discussion `here <https://github.com/fury-gl/fury/discussions/816>`_.
+
+Did you get stuck anywhere?
+---------------------------
+Implementing the bounding box feature took some extra time as I needed to carefully consider its impact on other UI elements that rely on the **TextBlock2D** component.
+
+What is coming up next?
+-----------------------
+Next, I will focus on completing the TextBlock2D Bounding Box PR, which will also indirectly finalize the Spinbox PR.