I get notifications of PRs in this repo so had a look at this one. Some observations:

1. You need a .gitignore file to exclude mac files such as .DS_Store and any other hidden files.
2. Images should be captured at 1:1 resolution. The Mac screen captures at 2:1 so screenshots are 2X enlarged in web pages.
3. We do need some guidance on full screen image sizes to capture - I have settled on something over 1200px wide (1440) in png or jpg so that the Joomla responsive image plugin can build a collection of webp images at different sizes.
4. My opinion: we need to think "multilingual" at the outset. How to capture all of the images again in French, German, .... I have a method for doing that using Playwright.
5. I am apprehensive about annotations with boxes and arrows, and using a commercial product to produce them.

Thank you Cliff.

In this repo will not be the final images we'll show in the presentation, but the "raw" images from which we can make optimised versions for the documentation. We had discussed some things about that in our weekly sessions and Jeff now just tried out some things. Based on that he'll change this PR. And we are still experimenting what will finally be the way to go.

Your points:

1. yes, a .gitignore will be added. Indeed, we don't want those .DS_Store and other things.
2. these raw images can be bigger than what we finally use.
3. they will be solely in .png format
4. yes, multilingual is for sure also our goal (somewhere next year), but it can probably not be 100% automated for all screenshots, like the Help Pages, because we sometimes need only a part of a window. Still figuring that out (but if you have tips for that, we are interested). I'm looking forward to a presentation from you (on JUG London, I assume) about how you use Playwright.
5. we are going to seperate the boxes and arrows etc. from the raw images, so we can apply them seperately. We can use a good commercial tool for that (we have several sponsored options for that in Joomla), but we are also looking for good Open Source tools. We do not want to be dependent on a tool that someone has to buy her/himself in order to be able to process the screenshots. And we want unity in it, but still have to work that out. We will also build a website in order to all use the same (installable) examples. Documentation should be a cooperative effort and we need some standards and coordination for that. That takes some extra time. Working on it.

Thank you Cliff and Herman,

I've added the .gitignore file, excluded the DS_Store files and reworked my content to remove the proprietary editor files. I've saved all the screen captures as 72 dpi png files, uncropped with no arrows, boxes, text or other mark-ups.

There is one exception that I'd like your opinion and guidance. In article 304 I'm using images from Wikimedia Commons and a PDF file from NASA (re: 304/Resources where I've included copies of those images and an MD file with the attributions). Do we want to save content like that, and if so, is this the right place to do it?

Thanks!

I've saved all the screen captures as 72 dpi png files, uncropped with no arrows, boxes, text or other mark-ups.

I don't think dpi is relevant - it is meta data that may be stripped in processing. The actual image size in pixels is used in processing. And photographs should be in jpg.

There is one exception that I'd like your opinion and guidance. In article 304 I'm using images from Wikimedia Commons and a PDF file from NASA (re: 304/Resources where I've included copies of those images and an MD file with the attributions). Do we want to save content like that, and if so, is this the right place to do it?

In our Wiki all content carries the JEDL (joomla Electronic Document Licence) - so I would avoid using images requiring attribution if at all possible. Get some AI generated images and perhaps use different subject matter. I don't have an answer or recommendation - other than avoid anything likely to lead to a copyright problem.

Do we need to host files hosted by NASA? Where does that fit into documentation? Recommendation: avoid it.

5. we are going to seperate the boxes and arrows etc. from the raw images, so we can apply them seperately. 

I have reservations about using boxes and arrows at all! Images are inherently inaccessible and adding an arrow can make it worse. How do you propose to use them? For example, in your text you might write "Select the button indicated by the red arrow". That is not much use to someone with poor or absent vision. You might write "Select the New button in the Toolbar." A red arrow or box might be helpful to a sighted person - but I have seen images with many arrows and boxes, which can be confusing. So my recommendation: avoid image annotations if possible (and the associated work).

@JeffOnWire A pixel is a pixel, is a pixel, is a pixel! 😁
It is sufficient to concentrate on the absolute number of pixels - everything else is a conversion that determines the display or print size of the image in inches (cm or mm).
DPI is the wrong term in the case discussed here - it is often confused with the correct PPI.
See also: https://99designs.com/blog/tips/ppi-vs-dpi-whats-the-difference/

I agree with Cliff that we should avoid images with unclear licence terms or images that require acknowledgment of an author when used.
Wikimedia Commons images are generally in the public domain and can usually be published without attribution. To be on the safe side, however, the licence should be checked carefully.
See also: https://commons.wikimedia.org/wiki/Commons:Licensing

Thanks! I've uploaded the 144ppi originals and removed the non-original work.

As for arrows and other highlights, I agree that they can add confusion and should be used carefully, but they can be helpful to sighted users. I find them helpful, especially on busy images when following a tutorial, when my poor eyesight compels me to squint and move my head closer to the screen and launch into a visual search and breaks my concentration. I would imagine non-sighted users would find them benign unless their screen readers noticed them and started reciting alt-text (which can be perplexing especially if referencing arrows or highlights) in which case they may be more of a distraction than a help.

Imagine text that reads "click the save button". Screen reader users would simply use screen-reader resources to locate the save button. A screen shot showing the save button is pointless, and I would imagine having your screen reader find it and read out alternate text "A screen shot of the edit form with the save button in the upper-right corner as highlighted by a red arrow" would be distracting; better if that screen shot went unnoticed. Sighted users might benefit greatly from glancing at the screen shot with their attention quickly drawn to the location of the save button, especially on a form with multiple buttons in different regions of the screen, and especially if they experience some forms of vision impairment that may make that task more difficult. Just thinking aloud here really.

Attributions were noted more to identify the source of the image than to give credit to anyone. When writing a tutorial on how to insert images into an article, it seemed like a good idea to use a couple of interesting images with free-use licenses. The NASA file was simply a free-use file where I wanted a PDF. If I were to use my own photographs, would I need to somehow document the fact and specify some sort of free-use licensing for them to be used here? J

Points well taken though, as I'm as inexpert in graphic arts, accessibility, and copyright law as may be expected from an average volunteer (ha ha) I appreciate and benefit from this guidance. Thank you all for your continued patience—I do appreciate it.

Thanks! I've uploaded the 144ppi originals and removed the non-original work.

The screenshots all have extraneous content to the left and right, including part of the side bar of an app. That is not acceptable. I recommend you use Firefox to take screenshots, paste into GIMP (or whatever) and scale to 50% so that the images are in 1:1 image:screen ratio. In Cypress or Playwright you can specify the image size in pixels (but using one of those involves a significant learning curve).

I did a few tests and uploaded them here:
https://github.com/max123kl/Joomla_documentation/tree/examples/examples/image_diffs
https://github.com/max123kl/Joomla_documentation/blob/examples/examples/image_diffs/about.md

The effect of the "unsharp mask" filter in particular is significant for the quality.