Instructors

Claudiu C. Papasteri

     Claudiu C. Papasteri, Ph.D., is a clinical psychologist, psychotherapist and a lecturer in the Department of Psychology and Cognitive Science, Faculty of Psychology and Educational Sciences, University of Bucharest. Trained in experiential, emotion focused and ericksonian psychotherapy, Claudiu’s past research touched on intervention targeting, intervention development and psychotherapy process-research. More recently, he has became interested in the physiological underpinnings of change processes arising both through pathogenesis, but also as a result of successful psychological intervention. His main areas of research pertain to clinical psychology, psychotherapy and electropsychophysiology, blending his passionate work to data science and psychometrics.

Ana Toma

     Ana Toma is a psychologist, doctoral student, and doctoral teaching assistant at the Faculty of Psychology and Educational Science, University of Bucharest. Ana is specialized in cognitive-behavioral psychotherapy and clinical psychology and is now getting a second specialization in Emotion Focused Psychotherapy. As a researcher, Ana focuses on couple psychology as part of her doctoral studies, being also interested in the neuroscience of social cognition. Besides neuroscience, her teaching activity includes areas such as psychotherapy and statistics in the social sciences.

Introduction to Neuroscience

Bear, M., Connors, B., & Paradiso, M. A. (2016). Neuroscience: exploring the brain (4th Ed.). Jones & Bartlett Learning.

Bermúdez, J. L. (2020). Cognitive science: An introduction to the science of the mind. Cambridge University Press.

Ward, J. (2019). The Student’s Guide to Cognitive Neuroscience. Routledge.

Introduction to Neuroscience

Here you can find seminar and home activities.

Markdown syntax

Let’s face it: Writing content for the web is tiresome. WYSIWYG editors help alleviate this task, but they generally result in horrible code, or worse yet, ugly web pages.

Markdown is a better way to write HTML, without all the complexities and ugliness that usually accompanies it.

Some of the key benefits are:

1. Markdown is simple to learn, with minimal extra characters so it’s also quicker to write content.
2. Less chance of errors when writing in Markdown.
3. Produces valid HTML output.
4. Keeps the content and the visual display separate, so you cannot mess up the look of your site.
5. Write in any text editor or Markdown application you like.
6. Markdown is a joy to use!

John Gruber, the author of Markdown, puts it like this:

The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions. While Markdown’s syntax has been influenced by several existing text-to-HTML filters, the single biggest source of inspiration for Markdown’s syntax is the format of plain text email. John Gruber

Without further delay, let us go over the main elements of Markdown and what the resulting HTML looks like:

Paragraphs

In Markdown your content usually spans the whole available document width. This is called a block. Blocks are always separated by whitespace to their adjacent blocks in the resulting document.

Any text not starting with a special sign is written as normal, plain text paragraph block and must be separated to its adjacent blocks by empty lines.

Lorem ipsum dolor sit amet, graecis denique ei vel, at duo primis mandamus.

Et legere ocurreret pri, animal tacimates complectitur ad cum. Cu eum inermis inimicus efficiendi. Labore officiis his ex, soluta officiis concludaturque ei qui, vide sensibus vim ad.

Headings

A good idea is to structure your content using headings and subheadings. HTML-headings from h1 through h6 are constructed with a # for each level.

In Hugo you usually don’t use h1 as this is generated by your theme and you should only have one such element in a document.

# h1 Heading

## h2 Heading

### h3 Heading

#### h4 Heading

##### h5 Heading

###### h6 Heading

Horizontal Rules

To further structure your content you can add horizontal rules. They create a “thematic break” between paragraph blocks. In Markdown, you can create it with three consecutive dashes ---.

Lorem ipsum dolor sit amet, graecis denique ei vel, at duo primis mandamus.

---

Et legere ocurreret pri, animal tacimates complectitur ad cum. Cu eum inermis inimicus efficiendi. Labore officiis his ex, soluta officiis concludaturque ei qui, vide sensibus vim ad.

Text Markers

Bold

You can show importance of a snippet of text with a heavier font-weight by enclosing it with two asterisks **.

I am rendered with **bold text**

Italics

You can emphasize a snippet of text with italics by enclosing it with underscores _.

I am rendered with _italicized text_

Strikethrough

In GFM (GitHub Flavored Markdown) you can do strikethroughs by enclosing text with two tildes ~~.

~~Strike through this text~~

Text substitution

This Markdown dialect supports an extension to combine multiple punctuation characters to single typographic entities. This will only be applied to text outside of code blocks or inline code.

Double quotes `"` and single quotes `'` of enclosed text are replaced by **"double curly quotes"** and **'single curly quotes'**.

Double dashes `--` and triple dashes `---` are replaced by en-dash **--** and em-dash **---** entities.

Double arrows pointing left `<<` or right `>>` are replaced by arrow **<<** and **>>** entities.

Three consecutive dots `...` are replaced by an ellipsis **...** entity.

Lists

Unordered

You can write a list of items in which the order of the items does not explicitly matter.

It is possible to nest lists by indenting an item for the next sublevel.

You may use any of -, * or + to denote bullets for each list item but should not switch between those symbols inside one whole list.

- Lorem ipsum dolor sit amet
- Consectetur adipiscing elit
  - Vestibulum laoreet porttitor sem
  - Ac tristique libero volutpat at
- Nulla volutpat aliquam velit
  - Phasellus iaculis neque
  - Purus sodales ultricies
- Faucibus porta lacus fringilla vel

Ordered

You can create a list of items in which the order of items does explicitly matter.

It is possible to nest lists by indenting an item for the next sublevel.

Markdown will automatically number each of your items consecutively. This means, the order number you are providing is irrelevant.

1. Lorem ipsum dolor sit amet
3. Consectetur adipiscing elit
    1. Integer molestie lorem at massa
    7. Facilisis in pretium nisl aliquet
99. Nulla volutpat aliquam velit
    1. Faucibus porta lacus fringilla vel
    1. Aenean sit amet erat nunc
17. Eget porttitor lorem

Tasks

In GFM (GitHub Flavored Markdown) you can add task lists resulting in checked or unchecked non-clickable items

- [x] Basic Test
- [ ] More Tests
  - [x] View
  - [x] Hear
  - [ ] Smell

Definitions

This Markdown dialect supports an extension to add definition lists. Definition lists are made of terms and definitions of these terms, much like in a dictionary.

A definition list in Markdown Extra is made of a single-line term followed by a colon and the definition for that term. You can also associate more than one term to a definition.

If you add empty lines around the definition terms, additional vertical space will be generated. Also multiple paragraphs are possible

Apple
: Pomaceous fruit of plants of the genus Malus in the family Rosaceae.
: An American computer company.

Orange
: The fruit of an evergreen tree of the genus Citrus.

  You can make juice out of it.
: A telecommunication company.

  You can't make juice out of it.

Code

Inline Code

Inline snippets of code can be wrapped with backticks `.

In this example, `<div></div>` is marked as code.

Indented Code Block

A simple code block can be generated by indenting several lines of code by at least two spaces.

Be impressed by my advanced code:

    // Some comments
    line 1 of code
    line 2 of code
    line 3 of code

// Some comments
line 1 of code
line 2 of code
line 3 of code

Fenced Code Block

If you want to gain more control of your code block you can enclose your code by at least three backticks ``` a so called fence.

In GFM (GitHub Flavored Markdown) you can also add a language specifier directly after the opening fence, ```js, and syntax highlighting will automatically be applied according to the selected language in the rendered HTML.

See Code Highlighting for additional documentation.

```js
grunt.initConfig({
  assemble: {
    options: {
      assets: 'docs/assets',
      data: 'src/data/*.{json,yml}',
      helpers: 'src/custom-helpers.js',
      partials: ['src/partials/**/*.{hbs,md}']
    },
    pages: {
      options: {
        layout: 'default.hbs'
      },
      files: {
        './': ['src/templates/pages/index.hbs']
      }
    }
  }
};
```

grunt.initConfig({
  assemble: {
    options: {
      assets: 'docs/assets',
      data: 'src/data/*.{json,yml}',
      helpers: 'src/custom-helpers.js',
      partials: ['src/partials/**/*.{hbs,md}']
    },
    pages: {
      options: {
        layout: 'default.hbs'
      },
      files: {
        './': ['src/templates/pages/index.hbs']
      }
    }
  }
};

Tables

In GFM (GitHub Flavored Markdown) you can create tables by adding pipes as dividers between each cell, and by adding a line of dashes (also separated by bars) beneath the header. Note that the pipes do not need to be vertically aligned.

| Option | Description |
|--------|-------------|
| data   | path to data files to supply the data that will be passed into templates. |
| engine | engine to be used for processing templates. Handlebars is the default. |
| ext    | extension to be used for dest files. |

Aligned Columns

Adding a colon on the left and/or right side of the dashes below any heading will align the text for that column accordingly.

| Option | Number | Description |
|-------:|:------:|:------------|
| data   | 1      | path to data files to supply the data that will be passed into templates. |
| engine | 2      | engine to be used for processing templates. Handlebars is the default. |
| ext    | 3      | extension to be used for dest files. |

Blockquotes

For quoting blocks of content from another source within your document add > before any text you want to quote.

Blockquotes can also be nested.

> Donec massa lacus, ultricies a ullamcorper in, fermentum sed augue. Nunc augue augue, aliquam non hendrerit ac, commodo vel nisi.
>
> > Sed adipiscing elit vitae augue consectetur a gravida nunc vehicula. Donec auctor odio non est accumsan facilisis. Aliquam id turpis in dolor tincidunt mollis ac eu diam.
>
> Mauris sit amet ligula egestas, feugiat metus tincidunt, luctus libero. Donec congue finibus tempor. Vestibulum aliquet sollicitudin erat, ut aliquet purus posuere luctus.

Links

Autolink

In GFM (GitHub Flavored Markdown) absolute URLs will automatically be converted into a link.

This is a link to https://example.com.

Basic Link

You can explicitly define links in case you want to use non-absolute URLs or want to give different text.

[Assemble](http://assemble.io)

Link with Tooltip

For even further information, you can add an additional text, displayed in a tooltip on hovering over the link.

[Upstage](https://github.com/upstage/ "Visit Upstage!")

Link References

Links can be simplyfied for recurring reuse by using a reference ID to later define the URL location. This simplyfies writing if you want to use a link more than once in a document.

[Example][somelinkID]

[somelinkID]: https://example.com "Go to example domain"

Footnotes

Footnotes work mostly like reference-style links. A footnote is made of two things, a marker in the text that will become a superscript number and a footnote definition that will be placed in a list of footnotes.

Usually the list of footnotes will be shown at the end of your document. If we use a footnote in a notice box it will instead be listed at the end of its box.

Footnotes can contain block elements, which means that you can put multiple paragraphs, lists, blockquotes and so on in a footnote. It works the same as for list items, just indent the following paragraphs by four spaces in the footnote definition.

That's some text with a footnote[^1]

[^1]: And that's the footnote.

That's some more text with a footnote.[^someid]

[^someid]:
    Anything of interest goes here.

    Blue light glows blue.

Images

Basic Images

Images have a similar syntax to links but include a preceding exclamation mark.

![Spock](https://octodex.github.com/images/spocktocat.png)

Image with Tooltip

Like links, images can also be given a tooltip.

![Picard](https://octodex.github.com/images/jean-luc-picat.jpg "Jean Luc Picard")

Image References

Images can also be linked by reference ID to later define the URL location. This simplyfies writing if you want to use an image more than once in a document.

![La Forge][laforge]

[laforge]: https://octodex.github.com/images/trekkie.jpg "Geordi La Forge"

Image Effects

This theme allows additional non-standard formatting by setting query parameter at the end of the image URL. The default behavior is configurable thru your config.toml or frontmatter parameter.

Resizing

Add query parameter width and/or height to the link image to resize the image. Values are CSS values (default is auto).

![Minion](https://octodex.github.com/images/minion.png?width=20vw)

![Minion](https://octodex.github.com/images/minion.png?height=50px)

![Minion](https://octodex.github.com/images/minion.png?height=50px&width=40vw)

CSS Classes

Add a query parameter classes to the link image to add CSS classes. Add some of the predefined values or even define your own in your CSS.

Shadow

![Spidertocat](https://octodex.github.com/images/spidertocat.png?classes=shadow)

Border

![DrOctocat](https://octodex.github.com/images/droctocat.png?classes=border)

Left

![Supertocat](https://octodex.github.com/images/okal-eltocat.jpg?classes=left)

Right

![Riddlocat](https://octodex.github.com/images/riddlocat.jpg?classes=right)

Inline

![Spidertocat](https://octodex.github.com/images/spidertocat.png?classes=inline)
![DrOctocat](https://octodex.github.com/images/droctocat.png?classes=inline)
![Supertocat](https://octodex.github.com/images/okal-eltocat.jpg?classes=inline)
![Riddlocat](https://octodex.github.com/images/riddlocat.jpg?classes=inline)

Combination

![X-tocat](https://octodex.github.com/images/xtocat.jpg?classes=shadow,border,left)

Lightbox

Add the query parameter lightbox=false to the image link to disable the lightbox.

![Homercat](https://octodex.github.com/images/homercat.png?lightbox=false)

[![Homercat](https://octodex.github.com/images/homercat.png?lightbox=false)](https://octodex.github.com/#homercat)

Schedule

The theme comes with a reasonably configured topbar.

Nevertheless, your requirements may differ from this configuration. Luckily the theme got you covered as the themebar, its buttons and the functionality behind these buttons is fully configurable by you.

Areas

The default configuration comes with three predefined areas that may contain an arbitrary set of buttons.

• start: shown between menu and breadcrumb
• end: shown on the opposite breadcrumb side in comparison to the start area
• more: shown when pressing the more button in the topbar

While you can not add additional areas in the topbar, you are free to configure addtional buttons that behave like the more button, providing further user defined areas.

Buttons

The theme ships with the following predefined buttons (from left to right in the screenshot)

• sidebar: opens the sidebar flyout if in mobile layout
• toc: opens the table of contents in an overlay
• edit: browses to the editable page if the editURL parameter is set
• print: browses to the chapters printable page if print support was activated
• prev: browses to the previous page if there is one
• next: browses to the next page if there is one
• more: opens the overlay for the more area

Not all buttons are displayed at every given time. This is configurable (see below if interested).

Redefining Areas

Each predefined area and button comes in their own file. By that it is easy for you to overwrite an area file in your installation reusing only the buttons you like.

Eg. you can redefine the predefined end area by adding the file layouts/partials/topbar/area/end.html in your installation (not in the theme itself) to remove all but the more button.

The below example sets an explicit value for the onempty parameter, overriding the specific default value for this button (these defaults vary depending on the button). The parameter causes the more button to always be displayed instead of hiding once its content is empty.

{{ partial "topbar/button/more.html" (dict
    "page" .
    "onempty" "disable"
)}}

Defining own Buttons

Button Types

The theme distingushies between two types of buttons:

• button: a clickable button that either browses to another site, triggers a user defined script or opens an overlay containing user defined content
• area-button: the template for the more button, to define your own area overlay buttons

Button Parameter

Screen Widths and Actions

Depending on the screen width you can configure how the button should behave. Screen width is divided into three classes:

• s: (controlled by the onwidths parameter) mobile layout where the menu sidebar is hidden
• m: (controlled by the onwidthm parameter) desktop layout with visible sidebar while the content area width still resizes
• l: (controlled by the onwidthl parameter) desktop layout with visible sidebar once the content area reached its maximum width

For each width class, you can configure one of the following actions:

• show: the button is displayed in its given area
• hide: the button is removed
• area-XXX: the button is moved from its given area into the area XXX; eg. this is used to move buttons to the more area overlay in the mobile layout

Hiding and Disabling Stuff

While hiding a button dependend on the screen size can be configured with the above described hide action, you may want to hide the button on certain other conditions aswell.

For example, the print button in its default configuration should only be displayed if print support was configured. This is done in your button template by checking the conditions first before displaying the button (see layouts/partials/topbar/button/print.html).

Another prefered condition for hiding a button is, if the displayed overlay is empty. This is the case for the toc (see layouts/partials/topbar/button/toc.html) aswell as the more button (see layouts/partials/topbar/button/more.html) and controlled by the parameter onempty.

This parameter can have one of the following values:

• disable: the button displayed in disabled state if the overlay is empty
• hide: the button is removed if the overlay is empty

If you want to disable a button containing no overlay, this can be achieved by an empty href parameter. An example can be seen in the prev button (see layouts/partials/topbar/button/prev.html) where the URL for the previous site may be empty.

Reference

Button

Contains the basic button functionality and is used as a base implementation for all other buttons (layouts/partials/topbar/func/button.html).

Call this from your own button templates if you want to implement a button without an overlay like the print button (layouts/partials/topbar/button/print.html) or with an overlay containing arbitrary content like the toc button (layouts/partials/topbar/button/toc.html).

For displaying an area in the button’s overlay, see Area-Button.

Parameter

Area-Button

Contains the basic functionality to display area overlay buttons (layouts/partials/topbar/func/area-button.html).

Call this from your own button templates if you want to implement a button with an area overlay like the more button (layouts/partials/topbar/button/more.html).

Parameter

Predefined Buttons

The predefined buttons by the theme (all other buttons besides the more and toc button in layouts/partials/topbar/button).

Call these from your own redefined area templates if you want to use default button behavior.

The <varying> parameter values are different for each button and configured for standard behavior as seen on this page.

Parameter

Predefined Overlay-Buttons

The predefined buttons by the theme that open an overlay (the more and toc button in layouts/partials/topbar/button).

Call these from your own redefined area templates if you want to use default button behavior utilizing overlay functionality.

The <varying> parameter values are different for each button and configured for standard behavior as seen on this page.

Parameter

Laboratory etiquette

1. Safety – The principal investigator of the study and his/her designated users are responsible to make sure the laboratory is a safe environment. Please review your experimental protocol and make sure it is approved by your PI. Never leave a participant alone in the laboratory.

2. Courtesy – Do not remove any equipment or cables from the laboratory that do not belong to you. Return any equipment changes to their original state (e.g., moving monitors or chairs, etc.). Do not leave used equipment in the rooms (e.g., cables or monitors), as they can cause artifacts (e.g., with EEG) and accidents.

3. Cleanliness – Keep the laboratory clean (ex: throw away garbage). Pick up any loose cables or equipment (return to where you found them) when you are finished using them. Keep the shelves organized and neat. When you are finished with your experiment, the laboratory suite should look like you were never there.

4. Do not go over your allotted time – The rooms should be turned over to the next user group at the beginning of their session. This means you should leave time at the end of your slot to remove your participant and tidy the areas you used for the next user. Even if you get started late, your session must end on time.

5. Food and drinks – No Food is allowed in the laboratory, unless they are dry snacks provided to the study participants or if this will be part of your experimental protocol. Hot food is never allowed because it is smelly and the laboratory is an enclosed space! Drinks are okay only if they are covered containers!

6. Responsibilities – As well as what is mentioned above, responsibilities also include filling out the log book, backing up your data such that it is not stored on the computers in the laboratory. Please report any issues or broken equipment to the principal investigator right away.

Reproducibility: recipes for science

Reproducibility

Replicability in is vital for science, but we may get it every time.

Reproducibility ensures that using the obtained data anyone can achieve the same results.This is not as easy as it seems because it necessitates (1) methodological procedures and analytic pipeline to be explicitly documented in their entirety (like a recipe), and (2) the use of a fully reproducible environment.

To give you an example, here we will reproduce the hexagonal logo (sometimes refereed to as hex-stickers) of our course. Keep in mind that this example is only partial computational reproducibility, as we employ only package management. R version, system packages, operating system can vary and bias our results.

Full computational reproducibility, achievable with Docker containers or NixOS derivations, is beyond the scope of this demo.

Managing packages

For simplicity, we just store package versions within the .Rmd file and use renv for package management and taking care of all other dependencies.

Take note that renv is more powerful then this and should typically be used in a project-centric (i.e. .prj) workflow.

if (!require("renv")) install.packages("renv", dependencies = TRUE)

renv::use(
  "renv@1.0.3",
  "here@1.0.1",
  "dplyr@1.1.4",
  "tidyr@1.3.0",
  "ggseg3d@1.6.3",
  "ggseg@1.6.5",
  "plotly@4.10.3",
  "RColorBrewer@1.1-3",
  "reticulate@1.34.0",
  "magick@2.8.2",
  "cropcircles@0.2.4",
  "hexSticker@0.4.9"
)

Loading packages and setting up

# Packages
library(renv)
library(here)
library(dplyr)
library(tidyr)
library(ggseg)
library(ggseg3d)
library(plotly)
library(RColorBrewer)
library(reticulate)
library(magick)
library(cropcircles)
library(hexSticker)

As we are doing everything within a single .Rmd file. Here we use an unusual way of setting up an working directory for the .Rmd file that can be reproduced on any other system. Nevertheless, the usual way would be to use knitr options to set a root directory.

# Settings 
# If working in .prj directory and not using RStudio
here::set_here()

## File .here already exists in C:\Users\User\c\Github\ns101-website\content\lab_docs\2024-01-20-reproducibility

unloadNamespace("here")   # need new R session or unload namespace for .here file to take precedence over .Rproj
script_path <- file.path(here::here())

# If using RStudio
# script_path <- dirname(rstudioapi::getActiveDocumentContext()$path) 

# Create output folder if it doesn't exist
setwd(script_path)
folder_name <- "output"
if(!exists(folder_name)) {dir.create(folder_name)} 

## Warning in dir.create(folder_name): 'output' already exists

setwd(file.path(script_path, folder_name))

Making an interactive plot

The package aseg_3d helps us build a plotly interactive plot using a brain atlas.

# Make the Brain plot -------------------------------------------------------------------------
scene <- list(eye = list(x = -1.5, y = 0.3, z = 0))

my_aseg <- aseg_3d %>% 
  unnest(cols = ggseg_3d) %>% 
  select(label, colour) %>% 
  mutate(coln = as.integer(as.factor(colour))) %>% 
  mutate(coln = if_else(grepl("Cerebellum|Ventricle|Vent", label), NA_integer_, coln)) %>% 
  mutate(coln = if_else(grepl("CC_", label), 1L, coln)) %>% 
  mutate(col = RColorBrewer::brewer.pal(11, "Paired")[12 - as.integer(as.factor(coln))]) %>% 
  mutate(col = if_else(grepl("Cerebellum", label), "#012169", col))  # UB color

brain_plotly <- 
  ggseg3d(.data = my_aseg, atlas = aseg_3d, 
    colour = "col", 
    na.colour = "#A6CEE3",
    show.legend = TRUE
  ) %>% 
  add_glassbrain(
    hemisphere = "left",  
    colour = "#A6CEE3", # "#cecece"
    opacity = 0.3
  ) %>% 
  remove_axes() %>% 
  pan_camera(camera = scene) %>% 
  hide_colorbar()

You can interact with this visualization of a glass brain showing its subcortical structures.

brain_plotly

# Export to html
# htmlwidgets::saveWidget(brain_plotly, "brain_plotly.html")

Exporting the plot

Exporting plotly graphics is a bit of a hassle, as we need to spawn a python environment in order to use the kaleido library.

## Error : Miniconda is already installed at path "C:/Users/User/AppData/Local/r-miniconda".
## - Use `reticulate::install_miniconda(force = TRUE)` to overwrite the previous installation.

Now we have a .png of our glass brain!

# file.show(here::here("output", "brain_img.png"))
knitr::include_graphics(here::here("output", "brain_img.png"))

Let’s crop around it so we can then fit it inside a hexagonal shape.

# Make the hex sticker -------------------------------------------------------------------------
brain_img <- magick::image_read(here::here("output", "brain_img.png"))

cropcircles::circle_crop(
  images = brain_img,
  border_colour = "#ffffff",
  border_size = 10,
  to = here::here("output", "brain_img_cropped.png")
)

## [1] "C:/Users/User/c/Github/ns101-website/content/lab_docs/2024-01-20-reproducibility/output/brain_img_cropped.png"

brain_img_cropped <- magick::image_read(here::here("output", "brain_img_cropped.png"))
# brain_img_cropped

knitr::include_graphics(here::here("output", "brain_img_cropped.png"))

Now we hexSticker package to make out image into a hex sticker!

hexSticker::sticker(
  brain_img_cropped, 
  package = "UniBuc NS101", p_color="#012169", p_family = "sans",     # don't use: p_fontface = "bold"
  p_size = 14, p_y = 1.5,  
  s_x = 1, s_y = 0.9, s_width = 2, s_height = 1.5,
  h_fill="#ffffff", h_color="#012169", 
  url = "ns101.psychlab.eu", u_color = "#012169", u_size	= 8,
  filename = here::here("output", "brain_hex_bg.png")
)

brain_hex_bg <- magick::image_read(here::here("output", "brain_hex_bg.png"))

knitr::include_graphics(here::here("output", "brain_hex_bg.png"))

A little bit more styling and we are done - we really want the background to be transparent, not white.

fuzz <- 50

brain_hex <- brain_hex_bg %>%             # make background transparent
  magick::image_fill(color = "transparent", refcolor = "white", fuzz = fuzz, point = "+1+1") %>%
  magick::image_fill(color = "transparent", refcolor = "white", fuzz = fuzz, 
             point = paste0("+", image_info(brain_hex_bg)$width-1, "+1")) %>%
  magick::image_fill(color = "transparent", refcolor = "white", fuzz = fuzz, 
             point = paste0("+1", "+", image_info(brain_hex_bg)$height-1)) %>%
  magick::image_fill(color = "transparent", refcolor = "white", fuzz = fuzz, 
             point = paste0("+", image_info(brain_hex_bg)$width-1, "+", image_info(brain_hex_bg)$height-1))
magick::image_write(image = brain_hex, path = here::here("output", "brain_hex.png"))

# file.show(here::here("output", "brain_hex.png"))
knitr::include_graphics(here::here("output", "brain_hex.png"))

If we documented everything well enough and if you have a similar system, there should be a very high probability that by running this .Rmd file, you will re-construct our brain hex logo.