Open Regard3d and start a new project. Add a photoset by selecting the directory where you saved the photos.
+Click on compute matches. Slide the keypoint density sliders (two sliders) all the way to ‘ultra’. You can try with just the default values at first, which is faster, but using ‘ultra’ means we get as many data points as possible, which can be necessary given our source images. This might take some time. When it is finished, proceed through the next steps as Regard3d presents them to you (the options in the bottom left panel of the program are context-specific. If you want to revisit a previous step and try different settings, select the results from that step in the inspector panel top left to redo).
+The final procedure in model generation is to compute the surfaces. When you click on the ‘surface’ button (having just completed the ‘densification’ step), make sure to tick off the ‘texture’ radio button. When this step is complete, you can hit the ‘export’ button. The model will be in your project folder - .obj, .stl., and .png. To share the model on something like Sketchfab.com zip these three files into a single zip folder. On Sketchfab (or similar services), you would upload the zip folder. These services would then unzip the folder, and their 3d viewers know how to read and display your data.
+Once you have downloaded and installed Meshlab, double-click on the .obj file in your project folder. Meshlab will open and display your model. The exact tools you might wish to use to enhance or clean up your model depends very much on how your model turned out. At the very least, you’ll use the ‘vertice select’ tool (which allows you to draw a box over the offending part) and the ‘vertice delete’ tool.
+SG: screenshots, paths to frequently used useful tools in this regard.
-
Adding metadata to images
+
Adding metadata to images
- Go to https://www.sno.phy.queensu.ca/~phil/exiftool/index.html and download the version of the Exiftool appropriate to your computer.
- Windows users you need to fully extract the tool from the zipped download. THEN you need to rename the file to just
exiftool.exe. When you extract it, the tool name is exiftool(-k).exe. Delete the (-k) in the file name.
-- You need to add data about the camera make, camera model, and focal length to the image files themselves -
- Move the file
exiftool.exe to the folder where your images are.
- Mac users Unzip if you need to, double click on the dmg file, follow the prompts. You’re good to go.
Navigate to where your images are store. Windows users, search your machine for command prompt. Mac users, search your machine for terminal. Run that program. This opens up a window where you can type commands into your computer. You use the cd command to ‘change directories’, followed by the exact location (path) of your images. On a PC it’ll probably look something like cd c:\users\yourname\documents\myimages. When you’re in the location, dir will show you everything in that director. Mac users, the command ls will list the directory contents. Make sure you’re in the right location, (and windows users, that exiftool.exe is in that directory).
- The following commands will add the required metadata to your images. Note that each command is saying, in effect, exiftool, change the following metadata field to this new setting for the following image. the
*.jpeg means, every single jpeg in this folder. NB if your files end with .jpg, you’d use .jpg, right?
+The following commands will add the required metadata to your images. Note that each command is saying, in effect, exiftool, change the following metadata field to this new setting for the following image. the *.jpeg means, every single jpeg in this folder. NB if your files end with .jpg, you’d use .jpg, right?
-
-exiftool -FocalLength="3.97" *.jpeg . <- sets the focal length of your image at 3.97 mm. You should search for your cellphone make online to see if you can find the actual measurement. If you can’t find it, 3.97 is probably close enough.exiftool -Make="CameraMake" *.jpeg <- you can use whatever value you want instead of CameraMake. E.g., myphone works.exiftool -Model="CameraModel" *.jpeg <- you can use whatever value you want.
-- If all goes according to plan, the computer will report the number of images modified. Exiftool also makes a copy of your images with the new file extension,
.jpeg_original so that if something goes wrong, you can delete the new files and restore the old ones by changing their file names (eg, remove _original from the name).
-
+
exiftool -FocalLength="3.97" *.jpeg
+
This sets the focal length of your image at 3.97 mm. You should search for your cellphone make online to see if you can find the actual measurement. If you can’t find it, 3.97 is probably close enough.
+
exiftool -Make="CameraMake" *.jpeg
+
You can use whatever value you want instead of CameraMake. E.g., myphone works.
+
exiftool -Model="CameraModel" *.jpeg
+
You can use whatever value you want, eg LG3.
+
If all goes according to plan, the computer will report the number of images modified. Exiftool also makes a copy of your images with the new file extension, .jpeg_original so that if something goes wrong, you can delete the new files and restore the old ones by changing their file names (eg, remove _original from the name).
- Regard3d looks for that metadata in order to do the calculations that generate the point cloud from which the model is created. It needs the focal length, and it needs the size of the image sensor to work. It reads the metadata on make and model and compares it against a database of cameras to get the size of the image sensor plate. Oddly enough, this information is not encoded in the image metadata, which is why we need the database. This database is just a text file that uses commas to delimit the fields of information. The pattern looks like this:
make;model;width-in-mm. EG: Canon;Canon-sure-shot;6. So, we find that file, and we add that information at the end of it.
-- windows users This information will be at this location:
C:\Users\[User name]\AppData\Local\Regard3D eg, on my PC: C:\Users\ShawnGraham\AppData\Local\Regard3D, and is in the file “sensor_database.csv”.
-- *mac users Open your finder, and hit shift+command+g and go to
/Applications/Regard3D.app/Contents/Resources
-- Do not open
sensor_database.csv with Excel; Excel will add hidden characters and screw everything up. Instead, you need a proper text editor to work with the file (notepad or wordpad are not useful here). One good option is Sublime Text. Download, install, and use it to open sensor_database.csv
-- Add whatever you put in for camera make and camera model (back in step 3) exactly - uppercase/lowercase matters. You can search to find the size of the image sensor for your cell phone camera. Use that info if you can find it; otherwise 6 mm is probably pretty close.
-ShawnsPhone;LG3;6- Save.
+- windows users This information will be at this location:
+
+
C:\Users\[User name]\AppData\Local\Regard3D
+
eg, on my PC:
+
C:\Users\ShawnGraham\AppData\Local\Regard3D
+
and is in the file “sensor_database.csv”.
+
+- *mac users Open your finder, and hit shift+command+g and go to
-
Now you can open Regard3d, ‘add a picture set’, select these images, and Regard3d will have all of the necessary metadata with which to work.
-
Build the model
-
Open Regard3d and start a new project. Add a photoset by selecting your frames directory. Note that when you used the exiftool, the original images were copied within the folder with a new name. Don’t select those original images. As the images load up, you will see whether or not your metadata is being correctly read. If you get NaN under make, model, focal length, or sensor width, revisit step three again carefully. Click ok to use the images. Click on compute matches. Slide the keypoint density sliders (two sliders) all the way to ‘ultra’. You can try with just the default values at first, which is faster, but using ‘ultra’ means we get as many data points as possible, which can be necessary given our source images. This might take some time. When it is finished, proceed through the next steps as Regard3d presents them to you (the options in the bottom left panel of the program are context-specific. If you want to revisit a previous step and try different settings, select the results from that step in the inspector panel top left to redo). The final procedure in model generation is to compute the surfaces. When you click on the ‘surface’ button (having just completed the ‘densification’ step), make sure to tick off the ‘texture’ radio button. When this step is complete, you can hit the ‘export’ button. The model will be in your project folder - .obj, .stl., and .png. To share the model on something like Sketchfab.com zip these three files into a single zip folder. On sketchfab, you upload the zip folder.
-
Step Five Clean Up Double click on the .obj file in your project folder. Meshlab will open and display your model. The exact tools you might wish to use to enhance or clean up your model depends very much on how your model turned out. At the very least, you’ll use the ‘vertice select’ tool (which allows you to draw a box over the offending part) and the ‘vertice delete’ tool. Search the web for help and examples for the effective use of Meshlab.
-
link to humcommons piece for the archival build
+
/Applications/Regard3D.app/Contents/Resources
+
+- Do not open
sensor_database.csv with Excel; Excel will add hidden characters which cause trouble. Instead, you need a proper text editor to work with the file (notepad or wordpad are not useful here). One good option is Sublime Text. Download, install, and use it to open sensor_database.csv
+- Add whatever you put in for camera make and camera model (back in step 3) exactly - uppercase/lowercase matters. You can search to find the size of the image sensor for your cell phone camera. Use that info if you can find it; otherwise 6 mm is probably pretty close. The line you add to the database then will look something like this:
+
+
+- Save.
+
+Now you can open Regard3d, 'add a picture set', select these images, and Regard3d will have all of the necessary metadata with which to work.
+
+
+
+
+
+<!--chapter:end:04.1-3d-photogrammetry.rmd-->
+
+## 3D Printing, the Internet of Things and “Maker” Archaeology
+
+yay
+
+### discussion
+
+### exercises
+
+<!--chapter:end:04.2-3d-printing.rmd-->
+
+
+
+## Artificial Intelligence in Digital Archaeology
+
+To speak of 'artificial intelligence' in archaeology may be to speak too soon yet. We do have machine learning in the service of archaeology (neural networks for classificatory purposes, for instance), and there is a well-established body of work in terms of simulation that could fall under the rubric of 'artificial intelligence'.
+
+Then why use the term? We think it is still useful to use the term because it reminds us that, in using computational power for simulation or image classification we are off-loading some of our expertise and abilities to a non-human actor. In the case of machine learning and neural networks, we really *can't* see inside the 'black box'. But we can examine the training data, for it is in the selection of training data that we introduce biases or agendas into the computation. By thinking of the machine in this case as something non-human, our hope is that we remind you to not accept the results or methods of AI in archaeology blindly, as if the machine was not capable of racist or colonialist results.
+
+Machine learning: a series of techniques that endeavour to train a computer program to identify and classify data according to some previously determined values. We will in this chapter discuss image recognition using the neural network model trained by Google, the Inception3 model, which we will query using the Tensorflow package.
+
+Agent based simulation: a series of techniques that create a population of software 'agents' who are programmed with contextual rules (e.g., *if this happens, do that*) governing the behaviour of individual agents. The context can be both in terms of the simulated environment (GIS data, for instance) or the social environment (social relationships as a network).<!---The simulation iterates--> Simulation experiments iterate over multiple combinations of parameters' values<!---an entire landscape of possible variables-->, <!---creating--> the 'behaviour space'. <!---which is--> Simulation results are then used by the investigator to <!---understand the emergent behaviour in the situation, to understand better the possible range of situations that could account for the observed phenomenon in the 'real world'--> explain the 'real world' phenomenon as an emergency of a population of agents following a set of rules under certain situations.
+
+The value of machine learning: it makes us think carefully about what we are looking for and at in the first place; and then it can be scaled massively.
+
+The value of agent-based modeling: it forces us to think carefully about what it is we think actually *happened* in the past such that it can be <!---encoded as a series of individual-level instructions--> expressed as a series of contextual rules of behavior, functioning under certain conditions.
+
+
+### Agent-based modeling (ABM)
+
+This section is an overview of agent-based modeling (**_ABM_**), as it is used within archaeology, anthropology, and behavioral sciences. Before tackling the append "agent-based", we start with a brief introduction to what "modeling" means. To place ABM in a bigger picture, we introduce the student to several dimensions of the variability of simulation models. We describe the necessary and optional parts of ABM models, including their characteristic type of element, i.e. the agent. At this point, the student must be aware that _**simulation models**_ in our context involve computer code (they are *digital*) and the iteration of processes (they are *dynamic*).
+
+Following the definition of ABM, we describe the process of creating a model or *formalizing* an informal model. Although the reality is messier, this process can be divided into *definition* of research question and phenomenon, *design*, *implementation*, and *verification*. *Validation*, which is considered a fifth step by most of the modeling literature, is regarded here as an extra, lengthy process, often separable from the tasks involved in creating and exploring a model. Furthermore, we introduce two additional steps that are not normally acknowledged: *understanding* and *documenting* the model. In explaining all modeling steps, we keep instructions general enough for them to be valid when dealing with any platform or programming language.
+
+Next, we cover the *why* and *how* of the application of ABM in archaeology, history, and social sciences. We recover some key foundational works, including models that predate the development of ABM as it defined today. Specifically regarding archaeological applications, we illustrate the diversity of ABM approaches by presenting several examples of models with varying goals, spatial and temporal scales, and theoretical backgrounds.
+
+Last, we walkthrough the steps involved creating an ABM model. Inspired in the theme of emergence and collapse of territorial integration, we designed a model, the _**Pond Trade model**_, showcasing many elements that are common in ABM models in archaeology. The coupled process of design and programming was intentionally broken down into smaller, progressive steps to illustrate an organized pace of code development, from simple to increasingly complex algorithms. The Pond Trade model is implemented in _**NetLogo**_ (https://ccl.northwestern.edu/netlogo/), which is free, easy to install and use, and widely used in academia. The exercise assumes no previous programming knowledge, though practice with NetLogo is required to fully undertand the later versions of the model.
+
+Throughout this section, several concepts will probably sound *alien* for most history and archaeology students; and some may remain obscure long after completing this lesson. Beyond any practical application, ABM has strong roots in mathematics and logic. _**Don't panic!**_ Most ABM modelers don't go through formal introductions nor are well-versed in algebra and calculus. As in most digital approaches in humanities and social sciences, ABM is mostly done by self-taught experts with hybrid and tortuous academic profiles. Also, because ABM modellers in archaeology are not often computer scientists, the community lacks conventions about how to communicate models and simulation results, though proposals do exist (**REF ODD**). In this sense, the content of this section should NOT be considered the standard among the ABM-archaeology community.
+
+To the date, there is no easy way to begin doing ABM. We encourage students to engage in modelling the sooner, the better, by following our exercises, other tutorials, or their interests and creative anxieties. The full comprehension of ABM will require years of practice and transdisciplinary readings; certainly, a greater mastery in programming. Despite the rarity of ABM in history and archaeology mainstream curricula, there are many publications that offer introductions to ABM in archaeology, writen by authors with different backgrounds and perspectives [e.g., @Breitenecker2015, @Cegielski2016, @Romanowska2015; also visit https://github.com/ArchoLen/The-ABM-in-Archaeology-Bibliography, for an extensive and constantly updated list of references].
+
+#### What is ABM?
+
+>"Essentially, all models are wrong, but some are useful"
+>George Box, 1987
+>*Empirical Model-Building and Response Surfaces*, p. 424
+
+The first thing to consider is that ABM is about models. A model is a representation of a phenomenon as a set of elements and their relationships; the key term being *representation*. It is a generalization/abstraction/simplification of what we consider as *THE* phenomenon. Think about a pineapple. The mental representation of the phenomenon, "the pineapple", is already a model. It consists of a set of traits or visual cues, and their relative positions (e.g., crown of spicky leafs on top, thorns covering the oval body). Empirically, every pineapple has different visual properties, but we still are able to identify any pineapple we encounter by using this model.
+
+
+
+Another important statement about models is that they are--as any mental process--a phenomenon in its own right. That puts us in the realm of epistemology and cognitive sciences. It follows that one's model is *a* model and that there are many models representing a phenomenon as there are minds that recognise this phenomenon. Observe the diversity of pineapple drawings. Adding further complexity to this picture, minds are constantly changing with the integration of new experiences--creating, modifying, merging, and forgetting models--and we often exchange and contrast alternative models through expressing them to ourselves and others. As the last straw of confusion, the ability for communicating models give them the status of *'material objects'*, with a *existence* of their own, reproduced through learning, checked by the clash of new experiences, and in perpetual change through innovation and creativity. For example, a child with little or no experience with the 'real pineapple' is able to learn--and graciously modify--a model of pineapple.
+
+Well, what do pineapple drawings have in common with doing models in archaeology? You may imagine that, if your mental representation of a pineapple is a model, human minds are bursting with models about everything, including *models of models*, *models within models*, and *models of ourselves*. If an archaeologist, there will be many archaeologically-sensitive models buried deep inside such mental apparatus. *"Why did people in this site buried food remains in small pits?" "They wanted to avoid attracting critters." "They did not stand the smell of decomposition." "One person with high status started doing it and them the rest just followed." "They were offering sustainance to the land spirit."* These explanations derive directly from models of *why people behave as they do*. Often tagged as *social* or *behavioral*, this kind of model is as key in archaeology as it is neglected. Given that archaeological practice orbits around materials, archaeologists tend to relegate social models to a second plane, as if the goal is actually to understand the material remains of human behavior rather than the behavior itself. More importantly, many archaeologists are hardly conscient that they are using social models even when emitting a conservative interpretations. Another common practice is to present authoritative models as mantras while unconsciously hidding the models used. Social models are indeed more permeable to *personal*, *subjective* perspectives--in contrast with a model of stratification, for example--because we use them daily to interact with others, apart from archaeological affairs. Thus, they are strongly mould to our life experiences and beliefs, which vary depending on many socio-cultural factors, including those less obvious such as age and gender. Even though there are shared traits between them, these models are as many and diverse as pineapple drawings.
+
+Why bother then doing models in academia? Ultimately, we are searching for knowledge, staments with at least some *value of truth*, independent of any individual, not a ever-growing collection of models, even if they are *authorative* and well-accepted. Remember that models of a phenomena, as diverse they may be, are contrasted with experiences of that phenomena, which are much less variable. As George Box's famous phrase states, models are NOT equivalent reproductions of a phenomenon, but tools for looking and interacting with it. What we could define as *imaginative models*, such as the smiling pineapple, though still able to exist for other purposes, can be clearly distinguished from models with *vocation of truth*, because they fail to match our sensible experience and are incompatible with other successful models. Those that cannot be distinguished, should be considered *valid*, *competing* models; their study, validation, and improvement being the main goal of scientific endeavours.
+
+Unfortunately, models involving human behavior are less straightforward to validate or dismiss than a "smiley pineapple". Still, when having many competing models, progress can be made by ordering them by 'probability of being true', following many criteria. A warning though: almost-certain models might be eventually proven deciduous, and marginal--even discredited--models can end being mainstream. To be alive--read *useful*--models must be communicated, used, re-used, abused, recycled, hacked, and broken. A well-documented model, preserved in many locations and formats, could as easily be considered *hibernating*, awaiting new evidence for validation or a new generation with a more favorable mentality.
+
+Fine. Models are not only inevitable for any living mind, but they are also the keystone for the generation of knowledge. However, if models can be so simple, spontaneous, and intuitive as a pineapple drawing, what is the need of doing strange models with complicated equations, painstaking specifications, and fathomless designs? Archaeologist use models to define their research agenda and guide their interpretations. A lot of letter has been spent in presenting, discussing, and revisiting archaeological and archaeologicaly-relevant models. Nonetheless, few of these works are able to define unambiguosly the model(s) in question, not because they lack in effort but due to the intrinsic limitation of the media objectifying the model: human, natural, verbal language. For example, we may write a book on how we believe, given known evidence, that kinship relates to property rights among, say, the Armenians contemporaneous to the Early Roman Empire. Our reasoning and description of possible casuistics can be lengthy and impeccable; however, we are bound to be misunderstood at some point, because readers may not share the same concepts and certainly not all connotations that we may have wanted to convey. A significant part of the model in our minds would be writen between the lines or not at all. Depending on their background, readers can potentially miss altogether that we are referring to *a model*, and consider the elements of our model as loose speculations or, worse, as given facts.
+
+Formal models--or rather *formalizing* informal models--reduce ambiguity, setting aside part of the risk of being misunderstood. In a formal model everything must be defined, even when the elements of our model are still abstract and general. Our imaginary book about ancient Armenians could be complemented with one or several formal models that crystalize the main features of our informal model(s). For instance, if our informal model about property inheritance includes the nuclear patriarchal family as the main kinship structure, we must define it in *dummy* terms, explaining--to ourselves and others--what "family", "nuclear", and "patriarchal" means, at least in the context of our model. *Do a model assume that family implies co-habitation?* *Do our model consider adopted members?* *What happens if a spouse dies?* As it is often the case, we may end up changing our informal model through the effort of formalization; by realizing, for example, that we can replace "patriarchal" with "patrilineal" because our model do not assume a particular power structure within families.
+
+Formalization often demand the use of formal logic and some extend of quantification. Seen from the perspective of the human natural language, mathematics and logic are languages for idiots, with a lot of repetitions, fixed vocabulary, and no nuances. Dull. Computational systems function strictly with this kind of language, and they are both empowered and limited by it. A piece of software can potentially do so many increadible things, most of them impossible for the brightest human minds. However, software will be fit for a task as long as we give it enough instructions. Imagine a *formal entity* bumping into a closed door just because nobody explained it how to open doors. So much for Artificial *Inteligence*!
+
+A formal definition is a disclaimer saying: *"This is what X means in this model, no more, no less. You can now criticize it at will."* Whitout the formal definition, we would probably spend a chapter reviewing everything we read and thought about "nuclear patriarchal family" and still would not be "at the same page" with all our readers. The terms of this definition are assumptions of the model. At any point, new evidence or insight can suggest us that an assumption is unjustified or unnecessary, and we may change it or remove it from the model.
+
+
+
+- Why model with ABM? open with the idea that we are always modeling
+- Mention review article 'Why model?'
+
+- def system, model, formal model
+- The origins of computer simulation
+- 3d models and statistical models (e.g., regression) are not simulation models. Simulation implies the passing of time as the driving variable of a model. Other kinds of models may share the goal of inferring new data from a given knowledge or dataset. For instance, we can design a curve that fits the number of archaeological sites in a region for all known periods, and use it to estimate this value during periods not represented in any sites. However, this equation is not representing the mechanisms that are supposely causing the phenomenon, i.e. the distribution of human activity in space and time. The idea of step, iteration, or repetition as the representation of passing time is the keystone of any simulation model.
+- Equation-based modeling, System Dynamics - ODE systems as models (mention Lorenz attractor, end with the idea of iteration of a process)
+- Algorithm-based modeling, Algorithms as behavioral models (mention cellular automata, Van Neumann, Schelling, etc)
+- The variety of algorithm-based models, much coincides with the variety of programming paradigm.
+ a. Flow: spectrum between centralized (iteration of a single process, e.g. event) and distributed (multiple processes are iterated contextually by multiple entities).
+ b. Schedule: spectrum between fully-scheduled (processes are initiated in a predetermined order) and event-driven (processes are initiated given a certain input).
+ABMs fall somewhere in-between these two spectra, though normally leaning towards distributed (e.g., using Monte Carlo methods) and fully-scheduled. Applications in several disciplines (see Wikipedia)
+- Parts of an ABM model
+ (re-visit presentations)
+
+#### How to model with ABM?
+
+- Define hypotheses, questions or simply the phenomenon of interest (identify the system)
+- Define the elements and processes (you believe are) required to address the system (model the system). mention paradox Occam's razor vs. emergence
+- Express the chosen elements and processes as computer code (implement the model)
+- Modeling is a process of constant iteration. Each stage is an iteration loop that is often repeated several times before jumping into the next step. The end result of development and exploration of a model may be relatively stable, often in the form of publications. However, this product potentially feeds a new modeling effort (and that is actually the main usefulness of models in the long run).
+- ABM in python, Java, C#, or C++? in R? in NetLogo? (Any language can do it, really). Pros and cons, talk in terms of higher/lower level programming languages (still, they are all quite high-level).
+- remember to talk about https://www.openabm.org/
+
+#### ABM in Archaeology and Social Sciences
+
+- Emergence... Life game, deterministic chaos
+- Saving the gap between atomism and holism, or individual and social structure
+- Virtual laboratory for social sciences
+- Examples
+- Mention the cycles of enthusiasm and skepticism, and the tendency to develop closed circles
+- Challenges and pitfalls
+
+#### ABM tutorial: the Pond Trade model
+
+brief overview
+disclaimer: MY modelling strategy is highly focused in theory-building (general, explorative), not hypothesis-testing and prediction (specific, data-driven).
+
+##### Phenomena of interest and conceptual model
+
+- phenomena: cycles of growth and collapse, i.e. flutuations in the scale of site occupation, out of phase with environmental change. Focus on coastal settlements around a water body (e.g., lake, bay, sea).
+- Belief or main assumption: topography, transport technology, trade, settlement size and wealth, and cultural exchange are intertwined.
+
+
+
+
library(DiagrammeR) grViz(“diagrams/boxes.dot”)
+
+- Elements: "pond" or water body, settlements, ships, routes, goods.
+- Rules:
+ - coastal settlements of variable size around a pond.
+ - each settlement has a "cultural vector".
+ - trade ships travel between the settlements.
+ - once in their base settlement, ships evaluate all possible trips and choose the one with the greater cost-benefit ratio.
+ - ships carry economic value and cultural traits between the base and destination settlements.
+ - settlements size depends on the economic value they receive from trade.
+ - the economic value produced in a settlement depends on its size.
+ - the number of ships per settlement depends on its size.
+
+##### Implementation
+
+- Implement the model based on general definition (agents, variables, parameters)
+- Walk-through the implementation in NetLogo
+
+Pond Trade model repository: https://github.com/Andros-Spica/PondTrade
+
+
+
+##### Simulation experiments and analysis
+- Simulations and experiment design
+- Analysis and display of results (R example)
+
+
plot(1:10, 1:10) ``` 
+
SG: code chunks didn’t render correctly through the bookdown generation process, which is baffling. check the original bookdown book for how to sort this out. removed the executable code chunk, put it into a different script, ran it, copied the output here. this is not optimal.
+
AA: didn’t find anything useful about that… Anyhow, I can continue by loading images and leaving r chunks as generic code
+