Parent roadmap: #3
Related: #5, #8, #13, #22, #23, #24
Objective
Refine LaserLab's hardware/capture model around the community's actual laser hardware pattern: diffracted cross lasers, not only generic dot lasers or educational diffraction clips.
Community discussion points to wavelength-specific diffracted laser cross devices as the target search/hardware family:
- red:
650nm diffracted laser cross
- green:
532nm diffracted laser cross
- cyan:
488nm diffracted laser cross
- blue:
450nm diffracted laser cross
- violet / near-UV:
405nm diffracted laser cross
This issue should encode those as metadata/protocol options and analysis branches, while keeping safety and evidence language conservative.
Why this matters
The community claim is not merely laser dot on a wall. Participants are specifically discussing a cross/diffracted line-field projection where code-like symbols are reported in or around the diffracted lines. Some community members explicitly distinguish cross lasers from non-cross lasers when describing near-success or failed observation attempts.
LaserLab should therefore make the projected pattern type first-class:
dot
cross
line
grid
fan/diffraction spread
unknown
The cross profile should be treated as a primary wall-projection capture archetype.
Metadata fields to add
Extend capture/hardware metadata with:
Laser identity
laser_pattern_type: dot, cross, line, grid, fan, unknown
wavelength_nm: numeric, e.g. 650, 532, 488, 450, 405
color_label: red, green, cyan, blue, violet/near-UV
rated_power_mw
measured_power_mw if available
laser_class_label
manufacturer_model
device_label_photo_hash or attachment pointer if implemented later
diffraction_optic_type: built-in cross optic, external grating, cylindrical lens, unknown
mount_type: tripod, clamp, handheld, lab stand
beam_path_fixed: true/false/unknown
Cross-pattern geometry
cross_center_coordinate if visible
horizontal_arm_angle_degrees
vertical_arm_angle_degrees
line_width_px_estimate
arm_length_px_estimate
cross_rotation_degrees
fan_angle_degrees if known
projection_distance_meters
angle_of_incidence_degrees
Capture quality
- saturation/clipping fraction near the cross arms
- whether cross center is blown out
- whether the entire cross is visible
- whether the wall/surface texture is visible
- whether camera is fixed
- whether ambient light is low/controlled
Analysis tasks
- Add cross-pattern registration: detect cross arms, center, rotation, and line width when visible.
- Add ROI generation along cross arms, intersection, and high-contrast edge bands.
- Add candidate grouping by cross coordinate: center, horizontal arm, vertical arm, edge band, off-cross background.
- Compare detector/OCR/structure scores inside cross arms vs off-cross background and controls.
- Support wavelength-stratified summaries: compare 650/532/488/450/405 nm runs only when setup metadata is sufficient.
- Report saturation warnings when the cross center or arms are clipped.
Control tasks
For each wavelength/cross-laser run, guide users toward controls such as:
- same wall and camera with laser off;
- same wall/camera using a non-cross dot or line laser if available;
- same cross laser at different orientation/rotation;
- same cross laser on another matte surface;
- same wavelength without intermediate material/layer if applicable;
- alternate wavelength with otherwise matched geometry, only if safe/legal/equipment-available.
UI tasks
- In Study Context / Capture Protocol, add
Laser pattern selector with cross as a primary option.
- Add wavelength selector presets: 650 red, 532 green, 488 cyan, 450 blue, 405 violet/near-UV, custom.
- Show safety warnings for short wavelengths, higher powers, reflective paths, and unknown laser class.
- Add a
Cross projection quality checklist:
- cross visible;
- camera fixed;
- wall/surface visible;
- center not fully saturated;
- matched control exists;
- wavelength/power/class recorded.
Symbol corpus / Veilbreak linkage
Community discussion also asks whether observed symbols/codes are compiled in one place, with Veilbreak mentioned as the apparent community data platform.
LaserLab should not scrape or assume access to external datasets, but it should support future interoperability:
- optional
external_dataset_reference field, e.g. Veilbreak, community archive, manual import;
- optional symbol/glyph transcription import/export CSV;
- hashed/redacted participant/session IDs;
- fields for symbol image crops, manual transcription, coordinate, timestamp, wavelength, and pattern type;
- report section showing whether a candidate was compared to a known symbol corpus or not.
Safety boundaries
- Do not recommend purchase links or specific sellers.
- Do not treat user-entered power/class labels as verified measurements.
- Warn that 405 nm and higher-powered visible lasers can be especially hazardous and require appropriate laser safety review, eyewear, beam stops, and non-reflective projection paths.
- Never instruct direct viewing of the beam or unsafe alignment.
- Keep all substance-related content in external research-context metadata only.
Acceptance criteria
- Manifest supports wavelength and cross-pattern metadata.
- UI lets users identify a run as a
diffracted cross laser wall-projection capture.
- Reports include wavelength, color label, pattern type, and cross-projection quality warnings.
- Detector pipeline can at minimum segment or register visible cross-arm regions for ROI generation.
- Documentation distinguishes cross-laser community hardware from generic dot-laser or educational laser-video fixtures.
- Optional symbol-corpus fields exist without requiring any external Veilbreak integration.
Notes
This is a key alignment detail: LaserLab should target the actual community protocol hardware vocabulary — 650nm/532nm/488nm/450nm/405nm diffracted laser cross — while still requiring controls and avoiding any claim that a wavelength or device type proves the phenomenon.
Parent roadmap: #3
Related: #5, #8, #13, #22, #23, #24
Objective
Refine LaserLab's hardware/capture model around the community's actual laser hardware pattern: diffracted cross lasers, not only generic dot lasers or educational diffraction clips.
Community discussion points to wavelength-specific
diffracted laser crossdevices as the target search/hardware family:650nm diffracted laser cross532nm diffracted laser cross488nm diffracted laser cross450nm diffracted laser cross405nm diffracted laser crossThis issue should encode those as metadata/protocol options and analysis branches, while keeping safety and evidence language conservative.
Why this matters
The community claim is not merely
laser dot on a wall. Participants are specifically discussing a cross/diffracted line-field projection where code-like symbols are reported in or around the diffracted lines. Some community members explicitly distinguish cross lasers from non-cross lasers when describing near-success or failed observation attempts.LaserLab should therefore make the projected pattern type first-class:
dotcrosslinegridfan/diffraction spreadunknownThe
crossprofile should be treated as a primary wall-projection capture archetype.Metadata fields to add
Extend capture/hardware metadata with:
Laser identity
laser_pattern_type:dot,cross,line,grid,fan,unknownwavelength_nm: numeric, e.g.650,532,488,450,405color_label: red, green, cyan, blue, violet/near-UVrated_power_mwmeasured_power_mwif availablelaser_class_labelmanufacturer_modeldevice_label_photo_hashor attachment pointer if implemented laterdiffraction_optic_type: built-in cross optic, external grating, cylindrical lens, unknownmount_type: tripod, clamp, handheld, lab standbeam_path_fixed: true/false/unknownCross-pattern geometry
cross_center_coordinateif visiblehorizontal_arm_angle_degreesvertical_arm_angle_degreesline_width_px_estimatearm_length_px_estimatecross_rotation_degreesfan_angle_degreesif knownprojection_distance_metersangle_of_incidence_degreesCapture quality
Analysis tasks
Control tasks
For each wavelength/cross-laser run, guide users toward controls such as:
UI tasks
Laser patternselector withcrossas a primary option.Cross projection qualitychecklist:Symbol corpus / Veilbreak linkage
Community discussion also asks whether observed symbols/codes are compiled in one place, with Veilbreak mentioned as the apparent community data platform.
LaserLab should not scrape or assume access to external datasets, but it should support future interoperability:
external_dataset_referencefield, e.g.Veilbreak,community archive,manual import;Safety boundaries
Acceptance criteria
diffracted cross laserwall-projection capture.Notes
This is a key alignment detail: LaserLab should target the actual community protocol hardware vocabulary —
650nm/532nm/488nm/450nm/405nm diffracted laser cross— while still requiring controls and avoiding any claim that a wavelength or device type proves the phenomenon.