FLIR Oryx 5.3K 10GigE Smearing

I finally timed the camera trigger and did my first scan on the new machine. You can see my scanner thread here: RobinoScan RT 16/35 Scanner - #17 by robinojones

I scanned an old dirty trailer, it’s been on the scanner to test transport for months. This was scanned at approx 12fps, with 36us exposure times in Flir Spinview.

Using the FLIR ORYX 5.3K Model: ORX-10G-245S8C 24.6MP camera.

The scan is showing smearing/motion blur and I’m not sure why since my exposure times are very short.(36us) I don’t flash the LEDs, they are constantly on, could this be the issue? You can see smearing everywhere but especially on titles and high contrast/highlights areas. On the scan you will see, the smear direction is bottom > top, because on the scanner, the camera is tilted on its side and the film moves right to left (from the camera perspective) - so it makes sense that blur would be this way. But this much at 36us??

I have 12 days left to return the FLIR, I could get the emergent with same sensor for almost same price. Maybe the FLIR just doesn’t cut it for this job? It’s my first machine vision system, I don’t know how these camera are supposed to behave.

Please don’t judge the scan picture quality, the camera is literally sitting on an aluminum plate, not bolted, focus is totally guessed - Saved as JPEG sequence, I have no clue how to process FLIR .RAW files at the moment - I actually can’t believe it came out this good as my first test - except for the smearing. I stabilized the scan in Resolve, it was pretty stable for a temp 3D printed gate.

I also see a lot of stuck pixels (red, green, white) - but I’m sure they(FLIR) could map them out.

Let me know what you think about the smearing, is it because I’m not flashing the LEDs? Or maybe this camera needs to go back to its maker.

PS: Audio was extracted with AEOLIGHT - it’s nice to get a lot of headroom in a scan so you can easily extract audio like this.

Password: rsrt

1 Like

I ran more tests and can’t figure this out, I sent a support tix to FLIR

Below is a video of the machine in action - showing the speed at which the film was moving during scan of the A.I film trailer

password: flir

I also tried slowing down the machine to minimum speed and set to the fastest exposure time allowed (11us) and it still exhibited smearing.
Here’s a video of the machine moving film at slow speed.

password: flir

Here are screenshots of smearing at that speed (super slow like ~2fps) and with 11us exposure times. These are ugly as I had to raise the gains for this test.

The part I was puzzled with is that in the AI trailer (first video on the post), the length of the smear seemed to dance a bit, and then in the last part of the video (at 1:15) de smear is downward. Looks like at that time the film jump one perforation down.
Could this be a reflection on something hitting the sensor at an angle?

The jump at the end is most probably because of a defective perforation, the sensor missed a beat. Which is expected when using this type of sensor.

Upon further investigation, I am 80% sure the camera is fine. Just did a dirty “not so scientific” test where I strobed the LED very fast and ran a capture - some of the frames I got were perfect without smearing. I still need to review all frames to confirm 100% - It’s all about synchronization I will need to sync the LED pulses with the camera exposure time.

I didn’t want to flash but in the end I didn’t have a choice!

Strobing the light is what the shutter should do. If the shutter is unable to perform it, it makes sense to do it with the light… but I wouldn’t expect that from that level of camera.

Any theory why does the smear changes direction at 1:15?

Yes I figured it out! It’s because I stopped the scanner at that point and forgot to hit “stop” in SpinView… so with spinVew still grabbing frames, I hit the rewind button on the scanner, and that’s why it goes the other way.

So in your experience with non-intermittent scanning this should not happen? Strobing is not necessary? If that’s the case I will return the camera for sure and get the Emergent version. Will do more testing obviously and also wait for FLIR to respond.

Makes sense then. The smearing is consistent.

I have no experience with non-intermittent scanning. I’m drawing from past experience (video and old camera sensors not-for-industrial). In a moving subject, moving that slow, if you have a capture time that fast, it makes no sense that what you are seeing is the movement.

Another point corroborating above is that the smear is proportional to the amount of light. If it was just movement, everything would be be smear, not just whites. For example no smear on the blue clouds, only on the white letters of the Dreamworks logo. If it was movement, smear would be on the colors too.

Since the smear is bad, regardless of the film speed, and actually becomes well defined at slow speeds, it seems like the electronic shutter leaking (overflowing). Too much light?

To test that theory, you can decrease the amount of light, and slower shutter. If the theory checks, you should be able to find an amount of light that eliminates the smear.
It may be what the sensor global shutter can handle. I do not know if that is a limitation of the shutter or defect, FLIR tech support can weight on it it turns out to be too much light.

Hope the above observations give you some clues to find the issue.

Got a response from FLIR about the smear.

Here’s an article he linked about

In the solutions. one of the option is:

Use a pulsed or flashed light source. A pulsed light of 1/10,000 duration is sufficient in most cases to allow an extremely short 100ns exposure without smear effect.

1 Like

Interesting, it confirms the issue is light, not motion.

Another factor that affects smear is the angle that light hits the sensor. Many CCDs use on-chip microlenses that cover each pixel in order to increase sensitivity. When light hitting the sensor is not highly collimated (which is often the case with wide angle lenses), light can be refracted by the outer edges of the lens in such a way that it hits the light-shielded portions of the CCD.

The above is what I thought when I mentioned:

From what I understand, the key would be:

  • Eliminate or reduce light on the unprotected areas of the CCD.
  • Reduce or eliminate light when the sensor is shifting down the frame.

Very interesting information. Thank you for sharing it.


Notice that at the top of the list is… increase the shutter!

Reducing Smear

Smear may be addressed by reducing the source of bright light hitting the sensor, reducing the aperture, and using a lens that more effectively collimates light. Other, more specific, measures for reducing smear include the following:

    • Increase shutter (integration) time. This will increase the amount of time light is collected in the photosensors relative to the time in the vertical transfer register.

Test with another lens. Test with another camera. Ideally.

There shouldn’t be this level of smearing at all even if you’re not flashing the light.

I like the idea of testing with another lens. I can ship one to you for quick testing if you want, @robinojones. As for collimated light, our sphere is obviously the opposite of that. But I refuse to believe this is the cause of the smear. If you wanted to eliminate that as a possible source of the error, you could test with a) another light source in the sphere, and b). the original light source in a directly diffused configuration. But still…it just can’t be that!

I fixed it by flashing! it’s 98% there, it’s all about synchronization. I need to tweak the flash pulse duration and it will be 100% but it’s already night and day from the scan you guys saw. I will update later when i come back home.

The smearing shouldn’t exist in the first place. We have examples with a similar camera and a non-flashing light that looks fine. It’s possible there’s a UV filter in the lens or something else that’s causing the smearing.

Really good work though on your scanner and progress.

1 Like

Please share an example when you get the chance I would like to see that working with constant light.

Not sure why a dirty lens would cause smearing like this. My lens was very clean with no filter in front.


The smear is gone after timing the flashes to the camera exposure using oscilloscope.

If anyone can scan real-time with a continuous light, without flashing and without smear, please share examples here.

I have a couple blackflyS and chameleon USB3 cameras, I don’t have issues with smearing if i choose a short enough exposure time. Running at around 15fps in super 8, i use around 250us exposure time to remove signs of smearing.

It’s also a constant light. But timing a strobe to fire from one of the line outs from the camera is ideal to keep heat down and overdrive (something i haven’t done yet)

1 Like

That’s very interesting and thanks for sharing the video. I wonder if it’s something with the IMX530 sensor line? The camera is under warranty so if It is defective I can get it fixed. But as I said, flashing completely fixed the issue.

No it isn’t, although that sensor is a different generation Pregius. I think @Andyw has a Pregius S one as well though so he could (hopefully) show you that.

Flir will take forever to replace it under warranty - you could see if you can get them to send a test camera even if it’s monochrome or a slightly different model as long as it’s Pregius S.

We are seeing a little bit of smearing with one (an IMX253) using a continuous light, but not to the extent of yours. If anyone wants to see PM me and I’ll show you a sample we did on two different scanners.

I have a few that I’ve tried, one that came on the moviestuff Mkii, and two others that I bought on ebay 2nd hand.

Moviestuff 2k - FLIR CM3-U3-31S4C-CS (3.2mp global shutter IMX265)
FLIR BFS-U3-50S5C-C (5mp global shutter IMX264)
FLIR BFS-U3-122S6C-C (12mp global shutter IMX304)

all used with the Componon 50mm or APO 45mm and ebay brass helicoid

I haven’t noticed any smearing, using constant illumination. but maybe my eye isn’t as tuned in to it as it’s all I’ve ever seen.
I did experiment with strobing using one of the line outs from the GPIO that was set to activate high when exposure was active. this triggered a mosfet to strobe the light, it worked really well, but the power supply needed work.

I couldn’t really see it on that sample you showed me, it just looked slightly softer, but I would have first guessed lens sharpness. you’ll have to elaborate for me!