Camera not detected in notebook: compare Python environments

A camera that works from a Windows Python terminal but disappears inside a notebook usually needs an environment comparison before a driver change. The notebook kernel is a separate process, and its interpreter, native-library search paths, and loaded transport producer may differ from the terminal. This troubleshooting procedure helps you locate that difference, distinguish discovery from connection failures, and verify the repair without replacing working hardware.

Start with the failing acquisition stage

Use the same minimal acquisition sequence in both environments. Register the transport producer, refresh discovery, and print the complete device list before attempting to open anything. Keep image processing, display widgets, and background acquisition threads out of this test.

Record the actual outcome rather than describing every failure as an undetected camera:

A successful import proves that Python found a package. It does not prove that the package loaded the intended native transport components.

If enumeration already succeeds, move to GenTL camera open failure after successful discovery. If acquisition starts but transfers fail, use USB3 Vision transfer error troubleshooting. Those are different failure stages.

Compare the terminal and kernel fingerprints

Run the following diagnostic code once in the working terminal and once in the failing notebook. It reads process information without changing camera settings or installing anything.

import os
import struct
import sys

print("executable:", sys.executable)
print("version:", sys.version)
print("prefix:", sys.prefix)
print("pointer_bits:", struct.calcsize("P") * 8)
print("working_directory:", os.getcwd())
print("module_search_paths:", sys.path)

for name in (
    "PATH",
    "GENICAM_GENTL64_PATH",
    "GENICAM_GENTL32_PATH",
):
    print(name + ":", os.environ.get(name, "<not set>"))

Compare the full executable paths first. Matching environment names or notebook labels are not sufficient evidence that the same interpreter is running.

Next compare Python versions, prefixes, and module search paths. A user-level package installation or a local file can shadow the intended acquisition package. After importing your acquisition package, inspect its __file__ attribute in both processes to identify the loaded location.

For a worked architecture check, an 8-byte pointer gives 8 × 8 = 64 bits. A 4-byte pointer gives 4 × 8 = 32 bits. If the terminal reports 64 bits and the notebook reports 32 bits, they cannot load the same 64-bit producer successfully.

Save both fingerprints with the test results. Redact account names and private directory paths before sharing them outside your organization.

Correct the kernel selection before changing drivers

The notebook server and its kernel do not have to use the same Python environment. Starting the server from a particular terminal does not guarantee that an existing notebook selects that terminal's interpreter.

Use this sequence to correct the mismatch:

1. In the working terminal, confirm sys.executable and the successful camera discovery result.
2. Check whether that interpreter has the notebook kernel package required by your supported notebook installation.
3. Register that environment as a kernel, if necessary, using the command below from the verified terminal.
4. Select the registered kernel in the notebook interface.
5. Restart the kernel and rerun the fingerprint before importing the acquisition package.

python -m ipykernel install --user --name vision-acquisition --display-name "Vision acquisition"

This command registers the interpreter that executes it; it does not install the camera SDK. If the kernel package is unavailable, follow your approved notebook distribution's installation procedure rather than downloading unrelated binaries.

The executable printed by the new kernel should match the verified terminal executable. If it does not, inspect the selected kernel specification and its executable entry.

For broader integration choices, camera acquisition software compatibility explains why the Python wrapper, transport producer, and camera interface must be considered separately.

Make producer registration explicit and reproducible

A GenTL producer is a native library, commonly distributed as a CTI file. Use the producer supplied through the camera manufacturer's supported SDK or its authorized distribution channel.

For the comparison test, register exactly the same absolute CTI path in both processes. Do not rely on the working directory, an abbreviated filename, or whichever producer happens to appear first during automatic discovery.

Check these details:

• Confirm that the path exists from inside the kernel process.
• Compare the actual CTI file, not only its filename. Different SDK installations can contain similarly named files.
• Use a raw Python string or forward slashes when entering Windows paths. Backslashes can otherwise become escape sequences.
• Register only the intended producer during the minimal test, unless its documentation requires additional components.
• Preserve registration and discovery exceptions instead of converting them into an empty list.

GENICAM_GENTL64_PATH and GENICAM_GENTL32_PATH are useful evidence when software discovers producers through environment variables. Explicit registration may bypass that discovery mechanism, but it does not resolve the producer's dependent libraries.

A notebook can also retain an old producer after cells have been edited. Restart the kernel whenever changing producer files or native-library configuration, then run the setup cells in order.

Separate Python imports from native-library dependencies

Python module paths and Windows DLL search paths solve different problems. Adding a directory to sys.path may help Python find a wrapper, but it does not necessarily help Windows load the wrapper's native dependencies.

A producer can exist at the specified path and still fail because a required DLL is missing, incompatible, or loaded from another SDK installation. Compare the SDK installation, documented runtime prerequisites, and dependency locations between the two launch environments.

Follow the supported SDK procedure for configuring native-library loading. Some supported Python versions provide os.add_dll_directory() for explicit DLL search directories. Where the SDK documents that approach, configure it before the relevant native imports and retain the returned directory handle for the required lifetime.

Do not copy DLLs into unrelated system folders or download individual dependency files from unofficial archives. Install or repair the documented SDK prerequisites through their official distribution channels.

Avoid installing several SDK versions while troubleshooting. First establish which producer and dependent libraries the working terminal actually uses, then reproduce that configuration deliberately.

Release camera ownership and compare execution context

Close the working terminal acquisition session before testing the notebook. Also close preview applications, background services, and other notebooks that might have opened the camera.

Ownership behavior varies by producer. Another process may prevent opening a discovered camera, and some implementations may change what discovery reports. Therefore, an empty list alone does not establish either ownership or a permissions problem.

Notebook exceptions can leave native acquisition objects alive. Stopping a cell or deleting a variable is not always equivalent to executing the SDK's documented stop, close, and cleanup sequence. Use that sequence before restarting the kernel.

For the isolation test:

1. Close every acquisition client using the camera.
2. Start only the notebook kernel with the verified environment.
3. Run registration and discovery once.
4. Open and close the camera through the documented API.
5. Repeat from a fresh kernel to confirm the result.

Check account and service context only after comparing environments and ownership. A notebook launched as a service, through remote access, or under another account may inherit different settings and filesystem access.

Do not make administrator execution the permanent repair. If an account difference is confirmed, correct the documented installation or access requirement with the system administrator.

The Linux USB camera detection guide addresses a related discovery symptom, but its operating-system checks are not a substitute for this Windows process comparison.

Verify the fix with a controlled test matrix

Change one variable at a time and keep a short evidence table. A useful sequence is:

Run at least three fresh-kernel trials after the apparent repair. In each trial, record discovery count, camera identity, open result, and whether one image arrives. Use consistent exposure and trigger settings rather than adding automatic configuration changes.

Success means more than a nonempty device list. Confirm that the expected camera opens, produces a valid image, closes cleanly, and remains available after a new kernel starts.

If both environments now fail, the original comparison no longer isolates a notebook issue. Recheck the baseline connection and SDK installation. If only the notebook fails, retain its exact exception and fingerprint for application support.

Keep hardware selection separate from environment repair

A successful terminal capture is strong evidence that the existing camera and connection can work with that installed software stack. Replacing the camera or moving to another host is therefore not the first diagnostic step.

When specifying a new station, browse area scan cameras and the camera finder. Confirm operating-system support, producer architecture, SDK compatibility, and the required acquisition features before selecting an interface.

The LS-CMR-0166 is a USB3 area scan camera. Treat it as a hardware candidate, not as a remedy for an incorrectly selected notebook kernel.

The MV-CS200-10UM is another USB3 area scan camera. Confirm the supported acquisition software for your deployment before ordering.

If the project also requires vision controllers, evaluate their software environment separately from camera connector availability. A suitable port does not establish compatibility with your Python runtime or transport producer.

Final checks and next step

Before approving the repair or ordering replacement hardware, confirm the following:

• Interpreter: the terminal and kernel report the intended executable and architecture.
• Package: both processes import the acquisition wrapper from the expected location.
• Producer: the same supported CTI file is registered explicitly.
• Dependencies: native-library configuration follows the SDK's documented procedure.
• Ownership: no other process holds the camera during the test.
• Recovery: fresh kernels repeatedly discover, open, capture, and close successfully.
• Deployment: the startup procedure works without manual cell-order corrections or unnecessary elevation.

If the existing hardware passes, keep it and document the environment repair. For a new inspection station, start with the camera configurator, bringing the verified operating system, runtime architecture, interface, and acquisition requirements.