rcicr 1.3.0

Behaviour changes

• A decorated z-map on a device too small for it now says so, and can be made to fit.
  plotZmap(decoration = TRUE) needs room for margins, labels and the colour scale — about
  160px at the default text size on Linux and macOS, and about 200px on Windows, whose
  graphics device is 96 ppi where theirs is 72 — and below that base R stopped with figure margins too large, naming neither rcicr nor a way forward. It now stops with a message giving the
  size, the minimum, and the three ways out. plotZmap() gains pointsize and
  generateCI() gains zmappointsize: the decoration is measured in lines of text, so a
  smaller size fits it onto a smaller image. This matters most through generateCI(), which
  sizes the z-map to img_size, so a stimulus set below about 160px could not produce a
  decorated z-map at all — a 128px set now can, with zmappointsize = 6.

  Both arguments default to the graphics device's own 12, so every existing call renders
  exactly as before; a 512px decorated z-map is byte-identical.

• plotZmap() no longer depends on raster, and its ... arguments now go to
  graphics::image() instead of the raster package's plot method. col behaves the same
  way in both (and now actually works — see the bug fixes below); a call passing an argument
  specific to that method will now be rejected as unused. Dropping the dependency also removes
  terra, sp and Rcpp, and with them the GDAL/GEOS/PROJ system libraries that every
  Linux CI job had to install before it could start.

  The z-map itself renders identically — the undecorated figures generateCI() writes
  are pixel-for-pixel the same as before, within colour quantisation, and a golden reference
  rendered by the old raster code is committed as a test fixture to keep it that way. The
  palettes are unchanged, including the quirk that a z-map drawn over a background image uses
  the default palette rather than the viridis one.

• A decoration = TRUE z-map is laid out slightly differently. The colour bar is now
  drawn by hand rather than by raster, and the map is a few pixels wider at 512px. If you
  regenerate a decorated z-map figure, it will not be pixel-identical to one saved with 1.2.3
  — the same is already true of regenerating it on a different operating system, and for the
  same reason: what a graphics device paints is not part of what this package computes. No
  z-score, classification image, scaling result or informational value changes, and
  generateCI()'s own z-map figures are undecorated and unaffected. See
  ?plotZmap, "Reproducibility across platforms".

• generateCI(mask = matrix(NA, 1, 1)) now reports the malformed mask instead of silently
  ignoring it. The internal test for "was a mask supplied?" asked only whether the argument
  was a single NA — which a one-cell NA matrix, a one-element array(NA) and a list(NA)
  all are. Such a mask was mistaken for the NA default, discarded without a word, and an
  entirely unmasked classification image came back. A call that passes a mask and gets an
  unmasked CI is the failure worth catching early; it now stops in the same mask validation
  every other malformed mask reaches. The sentinel is now specifically an atomic scalar with no
  dimensions, so mask = NA still means "no mask" — it is the default, and every unmasked call
  relies on it — while matrix(1, 1, 1), larger matrices, PNG paths and NULL are unchanged.

• generateStimuli2IFC() now checks base_face_files before it generates anything,
  and names the entry it cannot use. Four inputs used to get past the old check and
  fail from inside a parallel worker with attempt to select less than one element in get1index, which names neither the argument nor the file: a list with no names, a
  list with some names missing, an empty list, and an element that is not a single file
  name. They now stop immediately with a message saying which entry is wrong and why.

  One of them could previously appear to work. A base_face_files with two entries
  under the same name silently dropped all but the first — the loop looked each name
  up by string, so list(face = 'a.png', face = 'b.png') produced one set of stimuli,
  from a.png, and nothing at all from b.png. That is now an error naming the
  duplicated name. If you have a script that relies on it, the stimuli it produced were
  never what the call asked for; give each base image its own name.

• The PNG-or-JPEG test now looks at the file extension rather than anywhere in the
  path. It was grepl('png|PNG', filename) against the whole path, so a JPEG stored
  under a directory called png was handed to png::readPNG() and died with file is not in PNG format, blaming the file for a choice the package had made. Files are now
  recognised by a .png, .jpg or .jpeg extension, case-insensitively. A base image
  whose extension does not say what it is is rejected up front, by name, instead of
  reaching a reader that cannot parse it.

• The .Rdata validation errors now name the version of rcicr that wrote the file.
  generateCI() and computeCumulativeCICorrelation() already said which field a file was
  missing; they now also say where the file came from, which is what turns "this file has no
  stimuli_params" into "it predates the version that added it — regenerate the stimuli, or
  install that version". The version is read tolerantly, because the field cannot be taken at
  face value: p$generator_version is preferred over the top-level generator_version, which
  every release from 0.4.0 through 1.1.0 recorded as a hardcoded 0.4.0, and a file that only
  claims 0.4.0 is reported as unknown rather than as 0.4.0. A file with no version field at
  all reports the absence and stops there — an absent field is equally a file older than 0.4.0,
  a truncated one, or one rcicr never wrote.

  generateReferenceDistribution2IFC()'s two warnings about a missing nscales or
  noise_type were reworded for the same reason. They said the file "was written by a version
  of rcicr that did not save" the field, which an absence does not establish; they now report
  what is missing, and keep the version as context rather than as a conclusion. The advice is
  unchanged, and was always right either way: regenerate the stimulus set with this version.

• A stimulus file with gabor noise and no saved sigma now says so.
  generateReferenceDistribution2IFC() assumes the historical default of 25 when a file
  predates 1.1.0 and lacks the field, which it has always done silently — unlike the loud
  warnings for a missing nscales or noise_type. For gabor noise that silence hid the same
  hazard those warnings exist for: sigma is what shapes the Gaussian mask, so guessing it
  wrong rebuilds the null on a different noise basis than participants saw, and the resulting
  InfoVal is wrong. On a 1.0.1 gabor stimulus set the reference norms move from
  0.681/0.689/0.680 at sigma = 25 to 0.615/0.620/0.626 at sigma = 10.

  Sinusoidal files are unaffected and stay silent, which is the point of doing this by
  noise type rather than by field: sigma reaches the basis through generateGabor() alone,
  so for sinusoidal noise the norms are identical whatever it is, and a warning would be pure
  noise on the far more common legacy file. Nothing warns that did not previously produce a
  wrong answer, and no numeric output changes.

• plotZmap(mask = ...) now accepts a mask with an alpha channel. It previously required
  every colour channel of a multi-channel PNG mask to match exactly, so a greyscale-plus-alpha
  or RGBA mask whose alpha plane happened to differ from its colour planes was rejected — alpha
  carries no colour information and is now always ignored, matching generateCI(mask = ...).
  A rectangular zmap/mask pair continues to work as before. plotZmap(mask = ...) also now
  rejects a mask that is neither a string nor a matrix with a clear error, instead of failing
  later inside png::readPNG() with an unrelated message.

• plotZmap(mask = NA) now means "no mask", as it already does in generateCI(). The two
  functions detected a supplied mask differently — plotZmap() asked only whether the argument
  was non-NULL — so the same sentinel meant opposite things: generateCI() read NA as "no
  mask" while plotZmap() passed it on and stopped with The mask argument is neither a string nor a matrix!. NaN behaved the same way. Both now render an unmasked z-map. No call that
  worked before changes: the inputs affected all raised that error.

• generateStimuli2IFC() no longer saves trial in the .Rdata file. It was the loop
  counter left over from stimulus generation — always equal to n_trials, which is already
  saved. Nothing in the package or the documented contract reads it. Existing .Rdata files
  that contain trial continue to work; the field is simply ignored on load.

Reproducibility impact

• Individual-CI PNGs written by generateCI(save_individual_cis = TRUE) carried the wrong
  participant's name, and are now named correctly. The per-participant loop selects each
  participant's trials by sorted order and took the output filename from order of
  appearance. Where those two orders differ, every file in <targetpath>/individual_cis
  was given another participant's ID. The pixels were always right; only the names were
  wrong.

  Affected: a direct call to
  generateCI(participants = ..., save_individual_cis = TRUE) where the participants
  vector is not already in sorted order. Such a call produced correct images under incorrect
  filenames, so a figure published as participant p2 may be someone else's classification
  image.

  Do not assume tidy data was safe — the common case is affected. Sorting is lexical,
  so text labels li...

rcicr 1.2.3

Documentation only. Nothing this package computes has changed — no function,
argument, return value or number differs from 1.2.2, and no analysis script needs
revisiting.

The release exists because the package-level help page, ?rcicr, had gone stale enough
to contradict the release before it. It was a hand-maintained .Rd file that roxygen
never touched, so the sweeps behind 1.2.2 — which all worked from R/ — went straight
past it. Every code snippet on it was wrong:

• Two of the three example calls, generateStimuli2IFC(base_face_files, n_trials = 770)
  and generateCI2IFC(stimuli, responses, baseimage, rdata), would now error: they
  omit the write paths that 1.2.2 made required.
• The third, autoscale(cis, saveasjpegs = TRUE), named an argument that has never
  existed under that spelling. It is save_as_pngs.
• The page twice promised output "saved as jpegs to a folder called stimuli in your
  current working directory" — the writing-by-default behaviour that 1.2.2 removed, and
  in a format the package does not write.
• Its \examples section was a single commented-out line, #simple examples will be added soon., left over from 2016.
• It carried a hand-typed Version: 0.4.0 and Date: 2017-07-25, five releases and
  nine years out of date.

The page is now generated by roxygen from R/rcicr-package.R, so its title,
description, author and URLs come from DESCRIPTION and cannot drift from it again. The
version and date table is gone rather than corrected — the way to keep a fact current is
to stop writing it down twice. What remains is a short pointer to
vignette("reverse-correlation-walkthrough") and to the three functions a new user
starts with; the walkthrough itself lives in the vignette and README.md, which are
tested on every build.

The page also now lists all three key references — Dotsch & Todorov (2012), Brinkman,
Todorov & Dotsch (2017), and Dotsch, Wigboldus, Langner & Van Knippenberg (2008) — each
with a DOI. The 2008 paper had been on the old page and was the only one not carried
anywhere else.

?rcicr and package?rcicr both still work.

rcicr 1.2.2

This release exists to answer the changes CRAN asked for when reviewing the previous
submission. Nothing it changes affects a number this package computes: classification
images, scaling, z-maps and informational value are identical to 1.2.1, and the release
gate confirms that against both 1.2.1 and 1.0.1.

Breaking changes

• Functions that write files now require you to say where. stimulus_path
  (generateStimuli2IFC()), targetpath (generateCI(), generateCI2IFC(),
  batchGenerateCI(), batchGenerateCI2IFC(), autoscale(), plotZmap()) and
  zmaptargetpath (generateCI()) have lost their defaults. They used to be ./stimuli,
  ./cis and ./zmaps, which meant a default call created directories in whatever your
  working directory happened to be — writing to your filespace without being asked, which
  CRAN policy does not permit.

  What to change in your scripts. If you relied on the old defaults, name them:

  # before
  generateCI(stimuli, responses, "face", rdata)
  
  # after
  generateCI(stimuli, responses, "face", rdata, targetpath = "./cis")

  You will not silently get files somewhere new — a call that would have written to a
  default path now stops with an error naming the argument to supply. If you do not want
  files at all, save_as_png = FALSE (or save_as_pngs = FALSE for autoscale()) needs
  no path.

Bug fixes

• batchGenerateCI() no longer produces a spurious CI for rows with no group. Rows
  whose by column was NA were kept and collapsed into an extra group named after NA,
  so a data frame with any missing grouping value returned one more classification image
  than it had groups — computed from whatever rows happened to be missing that value.
  batchGenerateCI2IFC() has always dropped those rows; the two now agree.

• generateCI(mask = ) accepts a logical matrix. The matrix branch tested
  typeof(mask) == 'double', so a mask built the obvious way — as TRUE/FALSE rather
  than 1/0 — fell through to The mask argument is neither a string nor a matrix!,
  despite the documentation describing exactly that form. It is now tested with
  is.matrix().

• generateCI() and computeCumulativeCICorrelation() no longer print the entire base
  image when they cannot find stimulus parameters. The "No parameters found for base image"
  error named the base image matrix where its label was meant. Because paste0() is
  vectorized, this did not paste one matrix into one message — it built one complete message
  per pixel, so the error came back as 1,024 concatenated copies at a 32x32 base image (8,190
  characters) and roughly 7 MB at the 512x512 size researchers actually use, with the reason
  for the failure buried inside it. The message now reads, in full, No parameters found for base image: <label>.

  Only the text of an error changed. No function's return value, arguments or numeric output
  are affected, and the condition that triggers the error is unchanged — if your analysis
  script runs today, it behaves identically.

• generateReferenceDistribution2IFC() no longer leaves a stray stimuli directory
  behind. It re-derives the noise basis by calling generateStimuli2IFC() with both save
  options off, purely to work in memory — but the directory was created before either
  option was consulted, so every call to it, and to computeInfoVal2IFC() when no
  reference distribution was cached, created an empty ./stimuli wherever you happened to
  be working. BACKLOG.md item 24.

• plotZmap() restores the graphics parameters it changes. The undecorated branch set
  par(mar = ...) and left it set. It also now closes its PNG device through on.exit(),
  so a failure part-way through plotting can no longer leak the device or leave a
  half-written file.

Documentation

• The DESCRIPTION description no longer opens with the redundant "Functions to", and
  cites the two method references: Dotsch and Todorov (2012)
  doi:10.1177/1948550611430272 and Brinkman, Todorov and Dotsch (2017)
  doi:10.1080/10463283.2017.1381469.

• Every example runs. The \donttest{} wrappers are gone from all eight examples that
  carried them, simulateNoiseIntensities()'s \dontrun{} is gone, and
  generateNoiseImage()'s example is real code rather than three commented-out lines that
  would not have worked (p was never defined, and params was the wrong length for the
  pattern). The whole example set now runs in about nine seconds.

• simulateNoiseIntensities()'s note claiming the function always errors is removed. It
  described two bugs that were fixed in 1.1.0; the note was left behind.

Internal

• Bare T and F are replaced by TRUE and FALSE throughout R/. Two of these were
  public API defaults visible in the documentation (generateCI(zmap =, zmapdecoration =)
  and plotZmap(decoration =)); the values are unchanged.

• The guard that keeps a function's arguments across load() is now a shared helper,
  captureArgs(). It skips required arguments that were not supplied — necessary once
  paths became required, since mget() forces the promise and a wrapper forwarding its own
  missing argument would abort there. Defaulted arguments are still captured: missing()
  reports those missing too, and their default is exactly as vulnerable to being replaced
  by a field in the .Rdata file as a value passed explicitly.

• The failure paths are tested. The suite had 9 assertions covering 33 stop() and
  warning() calls, so most of the package's error messages had never been run. They now
  are: the stimuli/responses length mismatch, every "this .Rdata file did not contain X"
  guard in generateCI() and computeCumulativeCICorrelation(), all four mask-import
  failures, and base images that are unreadable or not square. No behaviour changed — this
  is coverage of messages that were already there. It matters because an unexercised guard
  is indistinguishable from one that works, which is how three separate bugs in this package
  stayed live for years, the most recent being the one fixed just above.

• Every function that reads a stimulus set now keeps its arguments across the
  load(). load() assigns straight into the calling function's frame, so an object
  stored in an .Rdata file silently replaces an argument of the same name. generateCI()
  and generateReferenceDistribution2IFC() already guarded against this; computeInfoVal2IFC()
  guarded three of its five arguments, and computeCumulativeCICorrelation() none.

  No file this package has ever written triggers the problem, so no result changes and
  no analysis needs revisiting — the guard is preventive. It is worth having because the one
  collision that did occur (the z-map sigma, fixed in 1.2.0) was created by adding a field
  to the file, not by adding an argument, so an argument that is safe today stops being safe
  without anything in the function changing. The case now closed in computeInfoVal2IFC() is
  the one that would have mattered most: target_ci is read at the very end to compute the
  CI norm, and after a second load(), so a file carrying that name would have scored a
  different classification image and returned a plausible number rather than an error.

rcicr 1.2.1

No user-facing changes. Nothing this package computes differs from 1.2.0 — no function,
argument, return value or number has changed, and no analysis script needs revisiting.

The release exists because the 1.2.0 source tree does not pass R CMD check on macOS. The
fault was in the package's own test suite, not in the package: a test asserted properties of
a rendered PNG that belong to the graphics device rather than to what was drawn, and those
properties differ between macOS and Linux. No released function was ever affected. A package
still has to pass its own checks on the platforms CRAN builds for, which is what this
release restores.

Documentation

• ?plotZmap and the README now describe what is and is not reproducible across operating
  systems. Classification images, scaling, informational value and the z-scores themselves
  are ordinary R arithmetic and do not depend on your platform — as of this release that is
  verified on Linux, macOS and Windows on every change, rather than assumed. The PNG written
  by plotZmap() is the one exception: it is drawn through a graphics device, and devices
  differ by platform in colour management and in whether they write an alpha channel, so the
  same z-map produces visibly identical figures whose files are not byte-identical.

  The practical advice, now stated in both places: compare numbers, not rendered figures,
  when checking that an analysis reproduces. A z-map image that differs pixel-for-pixel on a
  colleague's machine is not a different result. Every other PNG the package writes —
  stimuli, classification images, autoscaled classification images — is written directly
  from the pixel array and carries no such dependence.

Internal

• R CMD check now runs on macOS and Windows as well as Linux, on every change. It
  previously varied only the R version against a single platform, which is how the macOS
  failure above went unnoticed.
• The test suite pins z-map values as well as classification images, scaling and
  informational value, so cross-platform agreement of the numbers is checked rather than
  assumed.

rcicr 1.2.0

Upgrading from the CRAN version? The last release on CRAN was 0.3.4.1, before the package
was archived in 2021. 1.0.1 and 1.1.0 were GitHub-only releases made in the meantime, so the
1.1.0 section below applies to you too — it is where the bulk of the bug fixes are.

Reproducibility impact

• generateCI(zmap = TRUE) blurred z-maps with the wrong sigma, for stimulus sets
  generated with 1.1.0 only. generateCI() reads the stimulus set with load(), which
  assigns into the function's own frame, and 1.1.0 began storing the noise sigma there —
  the same name as the z-map blur argument. The saved value replaced the argument, so z-maps
  were blurred with 25 rather than the documented 3, and passing sigma did nothing.

  In practice this affects nobody. 1.1.0 was a GitHub tag that stood for about a day and
  was never on CRAN, so almost no stimulus set carries the field that triggers it. Files from
  1.0.1 and earlier have no sigma at all and were never affected. Only z-maps are involved
  — classification images, scaling, InfoVal and every saved number are untouched. It is
  recorded here because it did change a number, and because if you are the one person who
  generated stimuli that day, regenerating the z-map is a one-line rerun.

  Every argument is now kept across the load(), so a field added to the .Rdata later
  cannot quietly capture another one. Found by tools/compare-release-output.R, the release
  gate introduced in this version — the first bug it caught.

Behaviour change

• plotZmap(mask = ...) now actually masks the z-map. The argument has been documented
  since 2016 — "if a cell evaluates to TRUE, the corresponding zmap pixel will be masked" —
  and until now it did nothing at all: the mask was read from its PNG or matrix, checked
  against the z-map's dimensions, validated as binary, converted to boolean, and then
  discarded before plotting. A correct mask produced an unmasked z-map, with no error and no
  warning. Masked cells are now dropped from the z-map exactly as sub-threshold cells are.

  Who is affected. Only direct calls to plotZmap(mask = ...). generateCI() does not
  pass mask to plotZmap() — it masks the classification image itself, via a separate and
  working code path — so z-maps produced through the normal pipeline are unchanged, and no
  stored numbers change anywhere. If you have been passing a mask and your z-maps looked
  unmasked, that is why; they will now come out masked, and the earlier images were wrong
  about which regions carry signal.

  A second bug is fixed alongside: the conversion to boolean set every cell to FALSE
  whatever you passed, so even once applied the mask would have masked nothing.

• The mask convention is documented correctly for the first time, in both
  ?plotZmap and ?generateCI. Both said a matrix masks where the value is 1/TRUE
  while a PNG masks where it is black (0) — two opposite conventions in one sentence.
  generateCI()'s implementation has always masked where the value is 0, for a matrix and
  a PNG alike, so the matrix half of the documentation was simply wrong. The code is
  unchanged and the documentation now matches it, since existing masks were built against
  the behaviour, not the prose. plotZmap() follows the same single convention, so one mask
  can be passed to both functions — which is now asserted by a test rather than assumed.

  If you built a mask by reading ?generateCI rather than by looking at your output, check
  it: 0/black/FALSE is the region that gets masked away.

New features

• generateReferenceDistribution2IFC() and computeInfoVal2IFC() gained a
  response_seed argument, so the null distribution InfoVal is scored against can be
  varied deliberately. Until now there was no way to draw a second, independent null from
  the same stimuli — which meant you could not check how much Monte Carlo error your choice
  of iter was leaving in your InfoVal. response_seed seeds the simulated responses only;
  the stimuli, and so the noise basis the null is built on, are untouched.

  Existing calls are unaffected. The default (NULL) issues no set.seed() call at
  all, so the reference distribution is byte-identical to what earlier versions produced.
  Verified against norms generated before the change, not merely assumed.

  In computeInfoVal2IFC(), passing response_seed forces the reference distribution to be
  regenerated even when the .Rdata file already holds one, and the result is deliberately
  not written back — a one-off check of the Monte Carlo error cannot silently become the
  number every later analysis of that stimulus set reports.

• generateReferenceDistribution2IFC() gained save_rdata (default TRUE, i.e. unchanged)
  and now returns the reference distribution invisibly instead of returning nothing, so the
  norms are reachable when you ask it not to write them to the .Rdata file.

• The .Rdata file gained a reference_norms_seed field recording the response_seed the
  stored reference_norms were generated with (NULL for the default). Purely additive;
  files written by earlier versions simply lack it. A stimulus set carrying a deliberately
  varied null is no longer indistinguishable from one carrying the default.

Bug fixes

• autoscale() works on masked classification images. generateCI(mask = ...) sets masked
  pixels to NA by design, and autoscale() took a bare range() over them, so the scaling
  constant became NA and the call died with missing value where TRUE/FALSE needed. The
  scaling constant is now computed from the unmasked pixels, exactly as generateCI()'s own
  scaling has always done, and masked pixels stay masked in the result. A CI that is
  entirely NA now raises an error naming the CI instead of failing the same opaque way.

• generateCI() accepts a pre-0.3.0 .Rdata file when computing a CI from a single
  trial. rcicr 0.3.0 stopped drawing four random contrasts per trial that no patch index
  ever referred to (4096 → 4092), and generateCI() has truncated older files ever since —
  but the single-trial branch tested for a length of 4092 and then truncated to 4092, a
  no-op that could never fire on the 4096-parameter input it existed for. Such a call failed
  with Stimulus generation aborted: number of parameters doesn't equal number of patches!.
  The multi-trial path was always correct and is unchanged.

• computeInfoVal2IFC() and generateReferenceDistribution2IFC() work on .Rdata files
  written before noise_type was saved (#94). Such a file failed outright with
  object 'noise_type' not found, and the workaround on record was to load the file and
  assign the variable by hand. It now falls back to sinusoid with a loud warning, matching
  how nscales is handled — a warning rather than a silent default, because guessing wrong
  means the null is built on a different kind of noise than participants saw, and the
  resulting InfoVal would be wrong. Files written by 1.1.0 or later already store the field
  and are unaffected.

• generateStimuli2IFC(return_as_dataframe = TRUE) shows its progress bar (#82). The
  return handing back each trial's noise exits the entire loop body, so it jumped past the
  progress-bar update and the bar sat at zero for the whole run — on the slowest path there
  is, since generateReferenceDistribution2IFC() takes it for every InfoVal.

• The .Rdata file written by generateStimuli2IFC() now records the rcicr version that
  actually wrote it (#29). generator_version was a hardcoded '0.4.0' string from 2016
  onwards, so every file produced by 0.4.0 through 1.1.0 claims to come from 0.4.0 —
  useless for the provenance the field exists for, and it disagreed with
  p$generator_version, which held the real version all along.

  No result changes: nothing in the package has ever read this field. If your own code
  does, note two things. Existing files cannot be trusted to say what wrote them, so treat
  a stored '0.4.0' as "unknown, somewhere between 0.4.0 and 1.1.0" rather than as a
  version. And the field is now a package_version object rather than a character string,
  so compare with utils::packageVersion() or numeric_version(), never as text —
  '0.10.0' < '0.4.0' is TRUE when compared as strings.

Documentation

• README.md now describes the package's architecture and, more usefully, the anatomy of
  the .Rdata file field by field. That file is the only link between stimulus generation
  and analysis — nothing about a stimulus set is recoverable without it — and until now its
  contents were documented nowhere a user would look.

• A CONTRIBUTING.md sets out how to work on the package, leading with the constraint that
  makes it unusual: researchers re-run old analysis scripts years later and publish the
  results, so numeric output must not change silently.

• ?generateStimuli2IFC documents a restriction on return_as_dataframe = TRUE: the frame
  holds one noise image per trial, so it is meaningful only under the default
  use_same_parameters = TRUE. With use_same_parameters = FALSE and more than one base
  image, only the first base image's noise comes back — the frame's shape cannot represent
  trial × base image. Behaviour is unchanged, and the files written to disk were never
  affected; the restriction simply was not stated.

• ?generateReferenceDistribution2IFC now documents as a guarantee what was previously
  only true by accident: with the default response_seed, the reference distribution — and
  therefore InfoVal — is reproducible from the stimulus .Rdata file alone, independent of
  the calling session's random number state and of ncores. This held before, but nobody
  had chosen it: it is a consequence of generateStimuli2IFC()'s internal set.seed()
  landing before the simulation draws. That call ...

rcicr 1.1.0

First release since 1.0.1, and the version submitted to CRAN to reinstate the package after its 2021-06-08 archival. The archival cause was an undeliverable maintainer address, which has been corrected.

This tag is the tree to build the CRAN submission tarball from — main has moved on since.

R CMD check --as-cran at this commit: 0 errors, 0 warnings, 2 NOTEs, both expected for a reinstatement (New submission + Package was archived on CRAN; the file-timestamp NOTE is environmental).

Highlights

• Seven P0 bugs fixed, including generateCI(mask = ) being unusable on R >= 4.2, base images silently required to already equal img_size (#124), and nscales/sigma missing from the saved .Rdata in a way that silently corrupted InfoVal (#81).
• Three plotZmap() bugs, one of which made zmapdecoration = FALSE entirely dead since R 4.2.
• generateNoiseImage() is ~6x faster end-to-end (1.66s -> 0.28s at 512px, nscales = 5).
• A reverse-correlation-walkthrough vignette that executes at build time, replacing the Medium tutorial — two lines of which had already stopped working.
• Test suite from nothing to 180 tests with 0 skips, including a golden master pinning the default pipeline's numeric output and an end-to-end test that the CI recovers a known template.

If you have published or in-progress results, read the "Reproducibility impact" section of NEWS.md — it says explicitly which changes can and cannot alter numbers.