Build and Record a Processing Pipeline
The team builds a raw-image-to-report pipeline for the part.
Read the full lesson and open its transcript below. A narrated video will be added after production.
What you will learn
The team builds a raw-image-to-report pipeline for the part.
A practical question
The part moves under the camera. To produce a scratch-width report, we first capture and preserve the raw image, then apply recorded calibration, locate the part, process a copy, find the candidate scratch, measure it, and make the defined decision.
The useful idea
At every stage, name the input, output, parameters, and failure condition. If the camera is out of focus, stop and flag the capture rather than reporting a precise width. If a mask touches the image border, show that intermediate result for review. The final number should be traceable back to the actual pixels and scale used.
Work through the example
Run a known sample through the complete sequence. Save the calibrated view, candidate mask, measured boundary, and decision. Ask a second person to trace one rejected part without relying on a spoken explanation from the developer. Follow one known part through capture, calibration, enhancement, segmentation, measurement, and decision. Save the output and settings at each important step. If the final width looks wrong, the intermediate records show whether an early resize, a shifted mask, or a unit conversion caused it. Test a clean part too, because a pipeline can produce plausible numbers even when no defect exists. A reproducible chain is more valuable than one polished final image. Use this case to test your understanding: Run a known part through each stage and save intermediate measurements. Here is the limitation to watch for: A final number without its processing history cannot be audited. This supports a careful conclusion: Record capture settings, calibration, transforms, thresholds, and software versions in order. A measured width can be wrong because of segmentation, resizing, or unit conversion. Saved intermediate outputs let the team find the first stage where the result diverged from the known part.
Limits and next step
Version the code and settings with the outputs. A pipeline that works on a comfortable sample is only the beginning. Next, we'll challenge it under the conditions a real factory will encounter.
Worked example
Run a known part through each stage and save intermediate measurements.
Quick check: test your understanding
Try it yourself: Consider this case: Run a known part through each stage and save intermediate measurements. Explain how you would check the result. In your answer, address this limitation: A final number without its processing history cannot be audited.
Check the reasoning
Record capture settings, calibration, transforms, thresholds, and software versions in order. A final number without its processing history cannot be audited.
What is the main idea behind build and record a processing pipeline?
Record capture settings, calibration, transforms, thresholds, and software versions in order.
How is it used in the example?
Run a known part through each stage and save intermediate measurements.
What limitation should be checked?
A final number without its processing history cannot be audited.
Further reading
Digital Image Processing, 4th edition — Rafael C. Gonzalez and Richard E. Woods.
Original ToolsInVision teaching examples. Editorial approach · Suggest a correction
Accessible referenceLesson 78 transcript318 words · Narration ready for the upcoming videoOpen transcript
The part moves under the camera. To produce a scratch-width report, we first capture and preserve the raw image, then apply recorded calibration, locate the part, process a copy, find the candidate scratch, measure it, and make the defined decision.
At every stage, name the input, output, parameters, and failure condition. If the camera is out of focus, stop and flag the capture rather than reporting a precise width. If a mask touches the image border, show that intermediate result for review. The final number should be traceable back to the actual pixels and scale used.
Run a known sample through the complete sequence. Save the calibrated view, candidate mask, measured boundary, and decision. Ask a second person to trace one rejected part without relying on a spoken explanation from the developer. Follow one known part through capture, calibration, enhancement, segmentation, measurement, and decision. Save the output and settings at each important step. If the final width looks wrong, the intermediate records show whether an early resize, a shifted mask, or a unit conversion caused it. Test a clean part too, because a pipeline can produce plausible numbers even when no defect exists. A reproducible chain is more valuable than one polished final image. Use this case to test your understanding: Run a known part through each stage and save intermediate measurements. Here is the limitation to watch for: A final number without its processing history cannot be audited. This supports a careful conclusion: Record capture settings, calibration, transforms, thresholds, and software versions in order. A measured width can be wrong because of segmentation, resizing, or unit conversion. Saved intermediate outputs let the team find the first stage where the result diverged from the known part.
Version the code and settings with the outputs. A pipeline that works on a comfortable sample is only the beginning. Next, we'll challenge it under the conditions a real factory will encounter.