Skip to main content
Glama
mxcoppell

pixinsight

by mxcoppell
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

run_spcc

Calibrate color of linear astrophotography images with an astrometric solution via SpectrophotometricColorCalibration; supports narrowband filters and white reference selection.

Instructions

Run SpectrophotometricColorCalibration (SPCC). Requires the image to have an astrometric solution (run_plate_solve adds one) and to be linear (not stretched). Narrowband mode (narrowband_mode true) calibrates each channel as a narrow band: give the real filter centre and width per channel (red_/green_/blue_wavelength_nm and _bandwidth_nm; PixInsight's defaults are 656.3 / 500.7 / 500.7 nm and 3 nm for every band, wrong for a 5 nm H-alpha filter). The white reference matters for star colour: use a solar-type reference such as "G2V Star"; the default "Average Spiral Galaxy" makes a galaxy neutral and tints stars.

Input Schema

NameRequiredDescriptionDefault
qe_nameNoCamera QE curve name (find_filters channel Q)
view_idYesView ID to calibrate (must be linear, must have a WCS/astrometric solution)
narrowband_modeNoEnable narrowband mode (default false)
red_filter_nameNoMeasured R filter curve name, as listed by find_filters. Set all three filters and qe_name together for a full calibration.
white_referenceNoWhite reference name from PixInsight's database, e.g. "Average Spiral Galaxy", "G2V Star"
blue_filter_nameNoMeasured B filter curve name, as listed by find_filters
red_bandwidth_nmNoNarrowband mode: bandwidth of the red channel's filter in nm (PixInsight default 3)
blue_bandwidth_nmNoNarrowband mode: bandwidth of the blue channel's filter in nm (PixInsight default 3)
green_filter_nameNoMeasured G filter curve name, as listed by find_filters
red_wavelength_nmNoNarrowband mode: centre wavelength of the red channel's filter in nm (default 656.3)
blue_wavelength_nmNoNarrowband mode: centre wavelength of the blue channel's filter in nm (default 500.7)
green_bandwidth_nmNoNarrowband mode: bandwidth of the green channel's filter in nm (PixInsight default 3)
green_wavelength_nmNoNarrowband mode: centre wavelength of the green channel's filter in nm (default 500.7)
white_reference_nameNoSame as white_reference

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv2.4.1
    • addedInput schema / properties / blue_bandwidth_nm
      Added value: +{
+  "description": "Narrowband mode: bandwidth of the blue channel's filter in nm (PixInsight default 3)",
+  "type": "number"
+}
    • addedInput schema / properties / blue_wavelength_nm
      Added value: +{
+  "description": "Narrowband mode: centre wavelength of the blue channel's filter in nm (default 500.7)",
+  "type": "number"
+}
    • addedInput schema / properties / green_bandwidth_nm
      Added value: +{
+  "description": "Narrowband mode: bandwidth of the green channel's filter in nm (PixInsight default 3)",
+  "type": "number"
+}
    • addedInput schema / properties / green_wavelength_nm
      Added value: +{
+  "description": "Narrowband mode: centre wavelength of the green channel's filter in nm (default 500.7)",
+  "type": "number"
+}
    • addedInput schema / properties / red_bandwidth_nm
      Added value: +{
+  "description": "Narrowband mode: bandwidth of the red channel's filter in nm (PixInsight default 3)",
+  "type": "number"
+}
    • addedInput schema / properties / red_wavelength_nm
      Added value: +{
+  "description": "Narrowband mode: centre wavelength of the red channel's filter in nm (default 656.3)",
+  "type": "number"
+}
  2. First observedv2.1.0

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does add real behavioral context: linearity/WCS prerequisites, the fact that PixInsight's narrowband defaults are wrong for real filters, and the downstream effect of the white reference on star colour. It does not state whether the view is modified in place or whether a new image is produced, which is the one notable gap for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One dense paragraph that front-loads the verb and then layers prerequisites, narrowband usage, and the white-reference caveat in that order. Every sentence carries information, though the white-reference clause at the end is slightly buried and could be split for scanability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 14-parameter calibration tool with no annotations and no output schema, the description covers prerequisites, narrowband mode and white-reference behavior well enough to invoke it correctly. It omits the in-place mutation behavior and does not address the duplicated white_reference/white_reference_name fields, which leaves minor gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the 3 baseline applies, but the description goes beyond it by explaining the semantics of narrowband_mode, the per-channel wavelength/bandwidth pairing, and why the default centre/width values (656.3/500.7 nm, 3 nm) are often wrong. This adds genuine meaning over the schema's field-level text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and named resource (Run SpectrophotometricColorCalibration), and distinguishes itself from the generic run_process/run_spfc siblings by naming the exact process and its calibration intent. An agent can tell this tool apart from the other run_* wrappers without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly gives preconditions: the image must have an astrometric solution (with a concrete pointer to run_plate_solve) and must be linear, not stretched. It also explains when to set narrowband_mode true and how to supply per-channel values. It stops short of naming when NOT to use it versus run_spfc, so it is a little less than fully routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools