add coc

.github/CODE_OF_CONDUCT.md

@@ -0,0 +1,104 @@
+# Community Guidelines
+
+The FURY community is a community of practice devoted to the use of the Python programming language
+in the scientific visualization. The following code of conduct is a guideline for our behavior
+as we participate in this community.
+
+It is based on, and heavily inspired by a reading of the Python community code of conduct, the
+Apache foundation code of conduct, the Debian code of conduct, and the Ten Principles of Burning
+Man.
+
+## The code of conduct for the FURY community
+
+The FURY community is made up of members with a diverse set of skills,
+personalities, background, and experiences. We welcome these differences because they are the
+source of diverse ideas, solutions and decisions about our work. Decisions we make affect users,
+colleagues, and through scientific results, the general public. We take these consequences
+seriously when making decisions. When you are working with members of the community, we encourage
+you to follow these guidelines, which help steer our interactions and help keep FURY a positive,
+successful, and growing community.
+
+### As members of the FURY community we try to:
+
+#### Be open
+
+Members of the community are open to collaboration. Be it on the reuse of data, on the
+implementation of methods, on finding technical solutions, establishing best practices, and
+otherwise. We are accepting of all who wish to take part in our activities, fostering an
+environment where anyone can participate and everyone can make a difference.
+
+#### Be collaborative
+
+Our work will be used by other people, and in turn we will depend on the work of others. When we
+make something for the benefit of others, we are willing to explain to others how it works, so that
+they can build on the work to make it even better. We are willing to provide constructive criticism
+on the work of others and accept criticism of our own work, as the experiences and skill sets of
+other members contribute to the whole of our efforts.
+
+#### Be inquisitive
+
+Nobody knows everything! Asking questions early avoids many problems later, so questions are
+encouraged, though they may be directed to the appropriate forum. Those who are asked should be
+responsive and helpful, within the context of our shared goal of improving scientific visualization practice.
+
+#### Be considerate
+
+Members of the community are considerate of their peers. We are thoughtful when addressing the
+efforts of others, keeping in mind that often-times the labor was completed simply for the good of
+the community. We are attentive in our communications, whether in person or online, and we are
+tactful when approaching differing views.
+
+#### Be careful in the words that we choose:
+
+We value courtesy, kindness and inclusiveness in all our interactions. Therefore, we take
+responsibility for our own speech. In particular, we avoid:
+
+ * Personal insults.
+ * Violent threats or language directed against another person.
+ * Sexist, racist, or otherwise discriminatory jokes and language.
+ * Any form of sexual or violent material.
+ * Sharing private content, such as emails sent privately or non-publicly, or unlogged forums such
+   as IRC channel history.
+ * Excessive or unnecessary profanity.
+ * Repeated harassment of others. In general, if someone asks you to stop, then stop.
+ * Advocating for, or encouraging, any of the above behaviour.
+
+#### Try to be concise in communication
+
+Keep in mind that what you write once will be read by many others. Writing a short email means
+people can understand the conversation as efficiently as possible. Even short emails should always
+strive to be empathetic, welcoming, friendly and patient. When a long explanation is necessary,
+consider adding a summary.
+
+Try to bring new ideas to a conversation, so that each message adds something unique to the
+conversation. Keep in mind that, when using email, the rest of the thread still contains the other
+messages with arguments that have already been made.
+
+Try to stay on topic, especially in discussions that are already fairly long and complex.
+
+#### Be respectful
+
+Members of the community are respectful. We are respectful of others, their positions, their
+skills, their commitments, and their efforts. We are respectful of the volunteer and professional
+efforts that permeate the FURY community. We are respectful of the processes set forth in the
+community, and we work within them. When we disagree, we are courteous and kind in raising our
+issues.
+
+## Incident Reporting
+
+We put great value on respectful, friendly and helpful communication.
+
+If you feel that any of our DIPY communications lack respect, or are unfriendly or unhelpful,
+please try the following steps:
+
+* If you feel able, please let the person who has sent the email or comment that you found it
+  disrespectful / unhelpful / unfriendly, and why;
+
+* If you don't feel able to do that, or that didn't work, please contact Eleftherios Garyfallidis directly
+  by email (<[email protected]>), and he will do his best to resolve it.
+  If you don't feel comfortable contacting Eleftherios, please email Serge Koudoro
+  (<[email protected]>) instead.
+
+## Attribution
+
+The vast majority of the above was taken from the FURY Code of Conduct.

docs/source/posts/2023/2023-08-24-week-12-tvcastillod.rst

@@ -0,0 +1,46 @@
+Week 12 : Experimenting with ODFs implementation
+================================================
+
+.. post:: August 24, 2023
+   :author: Tania Castillo
+   :tags: google
+   :category: gsoc
+
+What did I do this week?
+------------------------
+
+There were different issues I needed to address for the ODF implementation. Even though I could not solve any of them completely, I did check each of the issues and made some progress. All the work in progress is being recorded in the following branch `SH-for-ODF-impl <https://github.com/tvcastillod/fury/tree/SH-for-ODF-impl>`_, which when ready will be associated with a well-structured PR.
+
+First, about the scaling, I was suggested to check Generalized Fractional Anisotropy **gfa** metric to adjust the scaling depending on the shape of the ODF glyph, i.e., the less the **gfa** the more sphere-shaped and smaller, so I had to associate a greater scaling for those. However, this did not work very well as I was unable to define an appropriate scale relation that would give an equitable result for each glyph. For this reason, I opted to use peak values which are extracted from the ODFs, setting the scales as 1/peak_value*0.4 and I got a more uniformly sized glyph without the need of setting it manually. That is a temporal solution as I would like to see better why this happens and if possible do the adjustment inside the shader instead of a precalculation.
+
+Second, for the direction, I made a small adjustment to the spherical coordinates which affected the direction of the ODF glyph. As you can see below,
+
+.. image:: https://user-images.githubusercontent.com/31288525/263122770-b9ee19d2-d82b-4d7f-a5bb-1cbbf5907049.png
+    :width: 400
+    :align: center
+
+All the glyphs are aligned over the y-axis but not over the z-axis, to correct this I precalculated the main direction of each glyph using peaks and passed it to the shader as a *vec3*, then used *vec2vecrotmat* to align the main axis vector of the ODF to the required direction vector, the only problem with this is that not all the glyps are equally aligned to the axis, i.e., the first 3 glyphs are aligned with the x-axis but the last one is aligned with the y-axis, so the final rotation gives a different result for that one.
+
+.. image:: https://user-images.githubusercontent.com/31288525/263122752-b2aa696f-62a5-4b09-b8dd-0cb1ec49431c.png
+    :width: 400
+    :align: center
+
+As with the first small adjustment of the coordinates the direction was partially correct, I need to double check the theta, phi and r definitions to see if I can get the right direction without the need of the additional data of direction. Also, there might be a way to get the specific rotation angles associated to each individual glyph from the data associated with the ODFs.
+
+Third, about passing the coefficients data through textures, I understand better now how to pass textures to the shaders but I still have problems understanding how to retrieve the data inside the shader. I used `this base implementation <https://github.com/fury-gl/fury/blob/master/docs/experimental/viz_shader_texture.py>`_, suggested by one of my mentors, to store the data as a `texture cubemap <http://www.khronos.org/opengl/wiki/Cubemap_Texture#:~:text=A%20Cubemap%20Texture%20is%20a,the%20value%20to%20be%20accessed.>`_, "a texture, where each mipmap level consists of six 2D images which must be square. The 6 images represent the faces of a cube". I had 4x15 coefficients and inside the function, a grid of RGB colors is made so then it can be mapped as a texture. To check if was passing the data correctly, I used the same value, .5, for all the textures, so then I could pick a random texel get a specific color (gray), and pass it as *fragOutput0* to see if the value was correct. However, it didn't appear to work correctly as I couldn't get the expected color. To get the specific color I used `texture(sampler, P) <https://registry.khronos.org/OpenGL-Refpages/gl4/html/texture.xhtml>`_ which samples texels from the texture bound to sampler at texture coordinate P. Now, what I still need to figure out is which should be the corresponding texture coordinate. I have tried with random coordinates, as they are supposed to correspond to a point on the cube and since the information I have encoded in the texture is all the same, I assumed that I would get the expected result for any set of values. It might be a problem with the data normalization, or maybe there is something failing on the texture definition, but I need to review it in more detail to see where is the problem.
+
+Lastly, about the colormapping, I created the texture based on a generic colormap from `matplotlib <https://matplotlib.org/stable/tutorials/colors/colormaps.html>`_. I was able to give some color to the glyph but it does not match correctly its shape. Some adjustment must be done regarding the texels, as the colormap is mapped on a cube, but I need it to fit the shape of the glyph correctly.
+
+.. image:: https://user-images.githubusercontent.com/31288525/263122760-7d1fff5e-7787-473c-8053-ea69f3009fb4.png
+    :width: 250
+    :align: center
+
+What is coming up next?
+-----------------------
+
+I will continue to explore more on how to handle textures so I can solve the issues related to the coefficient data and colormapping. Also, take a deeper look at the SH implementation and check what is the information needed to adjust the main direction of the ODF correctly.
+
+Did I get stuck anywhere?
+-------------------------
+
+As I mentioned I had some drawbacks in understanding the use of textures and how to retrieve the data inside the shaders. This is a topic that might take some time to manage properly but if I can master it and understand it better, it is a tool that can be useful later. Additionally, there are details of the SH implementation that I still need to understand and explore better in order to make sure I get exactly the same result as the current *odf_slicer* implementation.