Add configurable resolution variables for JPEG and GIF generation

[Copilot]

GIF and JPEG resolution currently depends on simulation domain size, and make gif uses deprecated magick convert syntax.

Changes

• Added configurable variables for ImageMagick density and resize parameters:

  MAGICK_DENSITY := 96        # DPI for rasterization
  MAGICK_RESIZE_X := 1024     # Target width
  MAGICK_RESIZE_Y := 1024     # Target height
  MAGICK_RESIZE := $(MAGICK_RESIZE_X)x$(MAGICK_RESIZE_Y)

• Simplified jpeg target from 8 lines with temporary files to single command:

  jpeg: 
      magick mogrify -density $(MAGICK_DENSITY) -format jpg -resize $(MAGICK_RESIZE) $(OUTPUT)/s*.svg

• Updated gif target to use modern syntax and add resolution control:

  gif:
      magick -density $(MAGICK_DENSITY) $(OUTPUT)/s*.svg -resize $(MAGICK_RESIZE) $(OUTPUT)/out.gif

Usage

Override from command line for custom resolution:

make jpeg MAGICK_DENSITY=300 MAGICK_RESIZE_X=2048 MAGICK_RESIZE_Y=2048

Scope

Updated 20 Makefiles: main repository, Makefile-default, all 17 sample projects, and template_BM intracellular project.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>robust resolution in jpeg and gif</issue_title>
<issue_description>As hinted at in a recent Slack post¹, GIF resolution depends on the domain size. The same is true for make jpeg.

Something like

magick -density 300 $(OUTPUT)/s*.svg -resize 1024x1024 $(OUTPUT)/out.gif

works to resolve this (and a similar command for the jpeg target). The issue with this simple fix is that for larger domains, this would rasterize at much higher resolutions than necessary (don't always need -density 300) and then would resize out of resolution (-resize 1024x1024).

So, something more robust would be needed. I see two options:

• do the math in the Makefile
• doing the math when writing the SVG²

Either way, exposing these through Makefile variables would be a nice touch for users.

Proposed solution

Simplest is to introduce new Makefile variables that set defaults that can be customized:

MAGICK_DENSITY := 96
MAGICK_RESIZE_X := 1024
MAGICK_RESIZE_Y := 1024
MAGICK_RESIZE := $(MAGICK_RESIZE_X)x$(MAGICK_RESIZE_Y)

jpeg: 
	magick mogrify -density $(MAGICK_DENSITY) -format jpg -resize $(MAGICK_RESIZE) $(OUTPUT)/s*.svg

gif:
	magick -density $(MAGICK_DENSITY) $(OUTPUT)/s*.svg -resize $(MAGICK_RESIZE) $(OUTPUT)/out.gif

Notes:

1. This simplifies the jpeg target down to one line, eliminating need for intermediate files to store height and width
2. I am now getting a deprecation warning for magick convert (currently used in the gif target), so we'll eventually need to migrate to this new syntax, but I don't know if that will disrupt others with an older installation of magick...

For future reference

Here's my understanding of how all the numbers are computed after looking into this:

1. PhysiCell records in the <svg> element the width and height attributes. These are the simulation domain size plus necessary padding for title text and colorbar (if needed). Title text padding scales with the domain size so if you display the snapshot as a 1-inch-wide figure, the text is always the same size. The colorbar has a fixed padding (which is what causes it to render different widths and sometimes pushes the label outside the clipping mask.
2. Magick interprets these as the number of pixels in each dimension and computes a desired physical size of the image in inches using 1"=96pixels. E.g. 960 pixels --> 10 inches
3. The -density flag converts this desired size (in inches) to pixels, treating the flag value as dpi. E.g., -density 300 would take the 10" above and set that dimension to rasterize to 300 x 10 = 3000 pixels.
4. Rasterize at these dimensions
5. If -resize is provided, then downsample (if either dimension has more pixels from above then requested in this flag), preserving the aspect ratio. Minor note: if the -resize value ends with ! (e.g. -resize 1000x1000!), this will force both dimensions; i.e. not preserve the aspect ratio. To finish our example, if -resize 1000x1000 and the rasterized intermediate was 3000x6000 pixels, the final image will be 500x1000 pixels

Comments on the Issue (you are @copilot in this section)

• Fixes robust resolution in jpeg and gif #404

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

Footnotes

1. When we reduce the domain size via the config file, we're noticed that the gifs generated with magick appear to have lower resolution. Is there a way to maintain or improve the resolution when using a smaller domain? The output SVGs seem to retain their quality. ↩

2. width and height attributes control the resolution. Those attributes are dependent on the simulation domain size, but are not equivalent due to padding for text / colorbar, so those could be good targets to put default sizes.</issue_description> ↩

[drbergman]

I have confirmed that this PR updates all make jpeg targets (n=20) that this should update. Details of search

• Match whole word and case: jpeg:
• files to include: Makefile* (so we also get the Makefile-default
• files to exclude: unit_tests/, user_projects/, Makefile-backup

Some notes on this:

• The same results turn up when changing the search from jpeg: to gif:.
• Not all Makefiles have these targets. A non-exhaustive search turned up the ODE sample and the boolean cancer_invasion project

[drbergman]

I have confirmed that this PR updates all make jpeg targets (n=20) that this should update. Details of search

• Match whole word and case: jpeg:
• files to include: Makefile* (so we also get the Makefile-default
• files to exclude: unit_tests/, user_projects/, Makefile-backup

Some notes on this:

• The same results turn up when changing the search from jpeg: to gif:.
• Not all Makefiles have these targets. A non-exhaustive search turned up the ODE sample and the boolean cancer_invasion project

[drbergman]

@copilot why that now the dev branch is the base does the modules/PhysiCell_settings.cpp show a diff? even if I literally copy the contents of that file and commit, it shows a diff?

[Copilot]

@copilot why that now the dev branch is the base does the modules/PhysiCell_settings.cpp show a diff? even if I literally copy the contents of that file and commit, it shows a diff?

The modules/PhysiCell_settings.cpp file shows a diff in the GitHub PR view because both branches contain the filesystem refactoring changes, but they arrived via different commits:

• In this branch: commit bd8ef98 "Refactor create_directory to use C++17 filesystem"
• In development: commit 87f3346 "Including PR#366 from Daniel"

When I compare the actual file contents, they are identical (verified with git diff development HEAD -- modules/PhysiCell_settings.cpp which returns no diff). GitHub's PR interface may show it as changed due to the different commit history, even though the final content is the same.

To resolve this in the PR, you could either:

1. Rebase this branch onto development (which would drop bd8ef98 since it's already in the base)
2. Keep it as-is since the content is identical (the diff is just visual noise in the PR)

[drbergman]

superseded by #408 (that was properly based on development)