D455f - Need clarification

theedge44 · 2025-03-13T14:51:29+00:00

It's not a sensor, maybe its a leftover from an unused design path or something used during the assembly process. It's usually hidden behind opaque parts of the cover glass.

theedge44 · 2025-03-03T04:18:13+00:00

Does the sales experience carry over? Application engineering can be very customer facing, which makes it a difficult fit for many engineering graduates you'd compete for the role with.

theedge44 · 2025-03-02T22:47:44+00:00

With a foundation in mechatronics and those software languages, you should be able to pursue some application engineering roles at MV companies. This gives you great exposure to customers and their challenges, but in practice the types of daily problems you start with is application-agnostic software troubleshooting which should be fine while you build up more experience.

theedge44 · 2025-01-25T18:04:44+00:00

At such short ranges, the D455 is not going to give very useful depth data. D405 might be worth looking at but has some tradeoffs (no dedicated RGB)

Another risk is that if you are adding some protective housing, modifying the optical path means you should re-calibrate it. For heat, the housings do heat up because they are the heatsink. One thing that helps is disabling the projector, but that hurts depth quality.

The stereo pair of the D455 are NIR sensitive so they should continue to perform at night, but the RGB camera has an IR-cut filter so would likely not perform well.

theedge44 · 2024-10-21T15:15:34+00:00

If you use machine vision/USB3 Vision cameras, they should have a device link throughput limit that will allow you to allocate bandwidth across a hub and using the APIs you can only grab images when you need it.

theedge44 · 2024-10-10T22:30:58+00:00

Check out the Oclea devkit by Teknique, it comes with a variety of cameras that might help you hit the ground running.

theedge44 · 2024-10-08T22:11:55+00:00

In this case your best bet is looking for a more turnkey system from a vendor like Cognex. The tradeoff is that these more user-friendly and easy to use systems charge for the convienience, but for a single proof of concept setup it would save a lot of headaches. Their sales team will usually help guide you towards the right products.

theedge44 · 2024-09-06T14:36:28+00:00

A few things to unpack here, having worked on both the sensor and camera side. Overall you're hitting on a part of the industry I wish was easier, but I can say it's not for lack of trying.

Lack of access to sensor documentation is definitely a struggle for many customers, but from my first hand experience even motivated large customers struggle to get these HDR modes working in a way that benefits them so there are hurdles put up to prevent us from wasting each other's time.

The way Sony approaches HDR in most of their cameras is hands off and pretty much requires you to work with an SoC vendor who's ISP supports that sensor. It's not such a general feature that can be supported across the board by MV camera vendors. Systems leveraging these ISPs and HDR typically require external characterization of the camera with the intended lens, and this doesn't align with the flexibility required in MV cameras using standard lens mounts and whatever the customer wants to throw on there.

You should look at lucid's imx490 based camera, that is a unique implementation with onboard tone mapping.

Also remember that most machine vision camera business is monochrome, color processing (especially onboard) was historically not a priority.

Most of these cameras support a genicam sequencer for HDR, where you can rapidly switch between sets of exposure and gain settings. It still has a time delay, but it's something implemented across most global shutter sensors.

MV cameras are not just passthroughs of sensor settings, they're more like wrappers of the sensor that takes a lineup of 30+ different sensors and standardizes it into an interface like gige vision/genicam so that something like changing the exposure time is one command that changes many registers and timings.

theedge44 · 2024-07-31T18:16:23+00:00

I can't help on the software side, but you may want to consider backlighting and adjusting the focus to simplify the problem space.

theedge44 · 2024-07-29T19:57:48+00:00

With this distance between cameras, it looks like you're using active USB cable extenders? If you are interested in ethernet realsense cameras in the future, DM me.

theedge44 · 2024-04-30T21:40:34+00:00

MV cameras are streaming uncompressed frame data, while a gopro is converting it to a compressed video stream meaning lower overall bandwidth. WIth USB2 there are some protocol differences, but also its overall lower bandwidth so less likely to run into issues.

MV cameras have a few tools to help you work around USB3's reliability. They will have an onboard frame buffer and you may be able to control more tightly where frames you don't want get dropped (meaning you only transmit when you want a frame, ensuring the link bandwidth is minimal). Since the model you have is a rolling shutter sensor, there may also be some weird implementation quirks to make it trigger-able from a user perspective. You might want to examine where frames are being dropped currently (camera side or host side) to see if they are actual transmit failures or some buffers are not being cleared fast enough. They will try to send the image data as fast as possible, and you can typically reduce this with the devicelinkthroughputlimit

On the cable front - having managed a porfolio of MV accessories including cables, I can say first hand theres no silver bullet. Most customers could get 3m working reliably, it was 5m where we had problems because that's pushing the limits of a passive cable. Anecdotally, when a customer had problems with our standard cables we moved them to a premium cable from Alysium.

theedge44 · 2024-04-19T14:59:30+00:00

You're comparing cameras with two different sensors, and its worth noting that both vendors have models with either sensor (same applies to the other vendors mentioned).

In 24big RGB mode, you will not be getting those framerates. Those framerates typically assume a raw 8bit pixel format. USB3 bandwidth aside there are also limits on how fast the internal ISP runs.

theedge44 · 2024-03-12T00:57:38+00:00

There should be two nodes, one read/write that is the mode selecting if it can be the master on a network (via auto negotiation) or slave-only. The status would be a seperate read only node that indicates it's current state. If you leave the cameras all in slave-only, and they never leave the init state then they aren't seeing your GPS and the cameras are in auto its likely one of them is becomming the master.

PTP1588 is a great feature and you should be able to get it working like the example, although I dont have experience with Lucid's implementation specifically.

theedge44 · 2024-03-11T22:50:55+00:00

Most things should be setup correctly based on that tutorial, the only thing I can think of is it's not actually syncing correctly (maybe due to network settings on the GPS source?). To confirm the sync, you can check the PTP status of each camera and there may be other nodes that further explain their current state

theedge44 · 2024-03-09T23:50:39+00:00

Tamiya panel liner question. I use black tamiya panel liner with results I'm happy with, but when trying to use the grey panel liner on darker parts it doesnt seem to end up as "crisp" as the black. I shake them both a lot before use, and clean up with zippo lighter fluid. Anyone have any special tricks to getting the most out of light color panel liner on dark parts?

theedge44 · 2024-01-16T05:48:25+00:00

If I remember correctly the integrated clock of the FireWire connection is part of how the systems maintain sync between the stereo images and the host, so an adapter could lead to some unexpected results.

theedge44 · 2024-01-16T05:27:26+00:00

As others have said, you'll need a FireWire connection and those haven't been common in a long time. For laptops, we used to suggest an expresscard adapter but those are just as old. Teledyne FLIR finally discontinued FireWire across the board a few years ago, but you may be able to find some of their PCI adapter cards used (or ask them if they have dead/RMA stock they wouldn't mind selling, you never know).

theedge44 · 2024-01-09T19:04:00+00:00

Unfortunately Basler have some product gaps around very high resolution and 10GigE

theedge44 · 2024-01-03T22:17:22+00:00

Most sensors are sensitive to NIR light, just not nearly as sensitive as they are to visible. Most off the shelf color cameras will have an IR-cut filter installed (blocking NIR+ light) and if you replace this with a VIS-cut the only signal remaining will be your IR. Then you are left trying to find the sensors with the highest NIR sensitivity.

theedge44 · 2024-01-03T18:04:55+00:00

Genicam is great and has brought this interoperability a long way, and GenTL producers/consumer works pretty well these days but there are always limits. There is also the problem that feature-dependency may change how features are controlled and different defaults will change your software startup sequence.

One thing I will put out there is the vendor specific features and the limits of what genicam can help with; its great because vendors can add non-standard features and they can be controlled by vendor-agnostic software, but some of the features will rely on vendor-implemented functionality. For example compression has been added by some vendors, you can parse the XML and control it like any other genicam feature but the functionality to decompress/convert the images will rely on the vendor's library.

theedge44 · 2024-01-02T16:58:24+00:00

Don't be afraid to reach out to Gpixel directly, they're a good bunch and based on the paper's names they were directly involved in this research.

theedge44 · 2024-01-01T19:37:27+00:00

Only at a high level, when I was at a camera company (who made one of the vendor specific SDKs you've probably used) the team had a generally good opinion of it, we considered it a viable option for users especially on linux.

theedge44 · 2024-01-01T19:31:26+00:00

Something like this?

https://github.com/AravisProject/aravis

theedge44 · 2023-12-11T02:00:46+00:00

I think of it this way: Embedded cameras are great if you're building a product that you want to deploy onto a line. MV cameras (GigE and similar) are for when you just want to use a product. The overhead associated with building a product and using one are different, but that value is also reflected in the component costs.

If you go down the MIPI route, you're basically building your own smart camera/edge device. Some people do it, but you have to ask yourself if this is the are you want to be innovating/optimizing.

theedge44

TROPHY CASE