Support for high speed area and linear scan industrial cameras

[rkantos]

I haven't got such a camera at hand (yet), so I do not know whether they would already work out of the box with CrossMgrVideo, since at least Basler drivers/SDK have a video output for software called "Basler GenICam source". I see that at least the area scan cameras could work out of the box, at least at lower framerates. There is a comprehensive list of at least Basler area scan cameras here:

https://www.baslerweb.com/en/products/product-highlights/ace-u-and-ace-l/

For example you could get a 800x600 USB3 Vision color camera capable of 510FPS for only ~400$. Also full HD is possible for similar cost. All of these cameras are also global shutter, so can be used for very accurate timing. Furthermore the 510 FPS camera as all others can also be configured for even faster read rates, by decreasing the AOI (area of interest) height. The 1920x1080 camera at 1920x64 can reach a nice equal 1000FPS in color mode. Respectively the 800x600 camera can go much higher.

https://www.baslerweb.com/en/products/tools/frame-rate-calculator/

I understand the current CrossMgrVideo software does lay the pictures in order by frame time, and thus should also be compatible with any camera resolution, but maybe someone (or even me) could get confirmation that it functions well with frame rates exceeding hundreds per second.

[rkantos]

I mean.... This could work!:

Basically I got hold of one of these industrial cameras (It can output the size of the frames to say 1920x200, Basler acA1920-150um ~600$, also a better suited version coming) and tested it with CrossMgrVideo with What this would need however is the possibility for flipping the image from horizontal to vertical, since the camera can only be run significantly faster if you remove vertical and not horizontal pixels.

Also of note is that all of these cameras work of a global shutter, so goodbye jello! Even that in itself is worth a couple hundred in my opinion.

The only downside is that while the camera in question which would make the picture feed nicely display a continous line of images; CrossMgrVideo would probably need some kind of support for the Basler SDK. This would also most likely tremendeously reduce the memory consumption too.

@esitarski Could we get a feature where it would be possible to set any size of the frame? I understand the Basler Dshow driver doesn't most likely actually support this or make it possible, but it would be nice to test it.

[rkantos]

CrossMgrVideo can actually work with framerates approaching 1000fps, at least if you have enough RAM (buffer for the camera / dshow). However currently framerates above 200fps are not the best, since the vertical resolution drops dramatically. If you could input the 1920x200 and rotate it before inputting it to CrossMgrVideo, it would probably work a lot better.

[rkantos]

I'm pretty sure this does work However currently I would recommend for "production" use to have a computer with at least 32GB of RAM (preferably more like 512GB of RAM, YES, RAM!), >2TB NVMe and a 32 core cpu (Ryzen...)... A computer worth 3k will still make this solution cheaper than a professional line scan systems that start at 5k... (and are of course inferior in resolution, about equal in performance, except for timing accuracy, which cannot be said to be in the millisecond range).

However with simple modifications to the CrossMgrVideo app, it should be possible to make use of these cameras with much lower hardware requirements. Currently it seems that everything is loaded in to RAM, and while this is needed when analyzing, a computer with an NVMe SSD should be plenty capable of loading a 5-6 second capture (which doesn't take too much time when capturing BMX races starting every minute for example).

Therefore I'd request a feature, or even a 2nd version of the program that would support these kinds of cameras better. This would mean that there are certain requirements from hardware for it's use (such as NVMe). NVMe should allow for storing much less of the images in RAM, and only load the latest capature selected in the application. Currently one capture of 200fps @ 1280x720 takes about 150-350MB, and makes the program consume >10GB of RAM. I think the RAM consumption does keep pretty at these levels, but more would probably use even more if captured say a 100k or 1000k frames.

A second application could also support Basler, or other GenIcam / USB Vision standard cameras more frequently. This would mean the possibility of cropping the image to lower resolutions, which then increases the framerate to the thousands range.

In my opinion this kind of application of hardware and software holds the promise of the near future (before you can just point your phone camera to a race and AI does the work).

[esitarski]

There is a lot here, so let me take it one step at time.

I will look into adding a custom framesize. That is probably easy. However, it would also be easy to add the frame sizes that are missing, and perhaps, allow the frame to be rotated. That frame sizes do you need?

I was a bit surprised that you were able to run CrossMgrVideo at 200 fps. My crappy laptop 8Gig laptop doesn't get near this ;). It is also prone to overheating, which switches it into a slow clock rate.

You are correct that CrossMgrVideo caches all photos in memory as bitmaps and stores them on disk as jpegs to conserve space. And, when its does a capture, it writes the photos on a queue, then a secondary thread converts them to jpeg and writes them to the sqlite database. As the conversion and disk writes are slower than the capture rate, the queue grows until the processing catches up. This is why CrossMgrVideo takes more memory during the capture.

Unfortunately, Microsoft "improved" their video handling so that it is impossible to get jpeg photos directly from a camera even if the camera supports it (this happened around the time of facial recognition security in Windows 10). It would be great if I could just write out jpegs to disk from the camera and avoid the jpeg conversion step, but that is impossible.

The GeniCam interface is interesting (thanks for finding it). In the past, it was impractical for me to build vendor-specific interfaces to vendor-specific cameras. GeniCam appears to answer this problem. And there is a Python library here https://pypi.org/project/harvesters/ (well, python 3.4 anyway) GeniCam appears to handle large resolution and fast frame rates easily - much better than the Microsoft USB drivers. It also supports USB and GigE with a common interface. GigE cameras are more flexible than USB due to the longer cable. GeniCam is relatively new as the documentation was only available in May

2018. Not all manufacturers support it yet, but more and more are coming on board. Also, the GeniCam supported formats all seem to be binary. Without direct jpeg access from the camera, the CrossMgrVideo write queue will remain an issue (the higher the frame rate, the worse it will get).

The performance of video cameras continues to improve, and I expect to see low cost cameras with frame rates rivaling scan-line cameras in the near future.

So, I will look at the GeniCam interface. Unfortunately, buying a GeniCam compliant camera to test with is out of the budget for now.

On Sat, Sep 15, 2018 at 8:40 PM rkantos notifications@github.com wrote:

I'm pretty sure this does work However currently I would recommend for "production" use to have a computer with at least 32GB of RAM (preferably more like 512GB of RAM, YES, RAM!), >2TB NVMe and a 32 core cpu (Ryzen...)... A computer worth 3k will still make this solution cheaper than a professional line scan systems that start at 5k... (and are of course inferior in resolution, about equal in performance, except for timing accuracy, which cannot be said to be in the millisecond range).

However with simple modifications to the CrossMgrVideo app, it should be possible to make use of these cameras with much lower hardware requirements. Currently it seems that everything is loaded in to RAM, and while this is needed when analyzing, a computer with an NVMe SSD should be plenty capable of loading a 5-6 second capture (which doesn't take too much time when capturing BMX races starting every minute for example).

Therefore I'd request a feature, or even a 2nd version of the program that would support these kinds of cameras better. This would mean that there are certain requirements from hardware for it's use (such as NVMe). NVMe should allow for storing much less of the images in RAM, and only load the latest capature selected in the application. Currently one capture of 200fps @ 1280x720 takes about 150-350MB, and makes the program consume >10GB of RAM. I think the RAM consumption does keep pretty at these levels, but more would probably use even more if captured say a 100k or 1000k frames.

A second application could also support Basler, or other GenIcam / USB Vision standard cameras more frequently. This would mean the possibility of cropping the image to lower resolutions, which then increases the framerate to the thousands range.

In my opinion this kind of application of hardware and software holds the promise of the near future (before you can just point your phone camera to a race and AI does the work).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/esitarski/CrossMgr/issues/11#issuecomment-421662159, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJrqa68J1L27yPZFJ5-T52nIN7CBSs3ks5ubZ3wgaJpZM4WHWOI .

--

Edward Sitarski Provincial Chief Commissaire of Ontario, Track Cycling

[rkantos]

I will look into adding a custom framesize. That is probably easy. However, it would also be easy to add the frame sizes that are missing, and perhaps, allow the frame to be rotated. That frame sizes do you need?

The rotation of the image by the software is a prerequisite for using the camera with it's horizontal side rotated 90 degrees (Horizontal x Vertical , 200x1280 ) when choosing a custom AOI/framesize.

Before doing anything I recommend you to check out Kinovea, which has alpha-level support for Basler and IDS industrial cameras. They also support the configuration that Basler / IDS drivers provide. I think it might not be possible to set the framesize via the driver "directly", but instead it is needed to change the AOI in the Basler configuration software. This is what Kinovea sees for example:

Basically all the Basler driver reported resolutions seem to be "locked" in and probably cannot be changed without access to the camera configuration, seen here for an IDS camera for example: http://www.kinovea.org/en/forum/viewtopic.php?id=854

I'd appreciate being able to set any frame size, as in the manufacturer SDK / Viewer.

You are correct that CrossMgrVideo caches all photos in memory as bitmaps and stores them on disk as jpegs to conserve space. And, when its does a capture, it writes the photos on a queue, then a secondary thread converts them to jpeg and writes them to the sqlite database. As the conversion and disk writes are slower than the capture rate, the queue grows until the processing catches up. This is why CrossMgrVideo takes more memory during the capture.

Yeah, with further testing though CrossMgrVideo behaves quite weirdly.. When first starting the program the program fills up the RAM once, after which it settles to about 50% RAM usage.

I was a bit surprised that you were able to run CrossMgrVideo at 200 fps. My crappy laptop 8Gig laptop doesn't get near this ;). It is also prone to overheating, which switches it into a slow clock rate.

With proper hardware CrossMgrVideo with an industrial camera should run pretty fast (32 cores etc), I think I was able to actually go between something like 100 to 300fps. The framerate seemed to be very variable. Basically I was recording for 5 seconds and got 700-900 frames, so not quite a stable 200fps. You can even see the variability in the framerate in the attached screenshots.

Ofcourse it also takes about 10x the time for CrossMgrVideo to become responsive again after capture has finished. This is lesser of an issue in a road race, but of course would need radical improvements for reliable use in a lap or track race. Some concurrency is thus needed. It would probably be wise to set different buffers for viewing and recording, so that on or the other doesn't eat up all the RAM available.

GeniCam appears to handle large resolution and fast frame rates easily - much better than the Microsoft USB drivers. It also supports USB and GigE with a common interface. GigE cameras are more flexible than USB due to the longer cable.

With the performance modern computers can have, I'd like to see full frame (not line scan) cameras being used for this. They also seem to be cheaper overall as machine vision cameras from major manufacturers like Basler, IDS and Ximea. And what I'm constantly trying to get to is having dual functionality, where a camera that shoots a full frame can be used as a linescan camera by just limiting the AOI.

Also note that while Ethernet cables are much easier to use, USB3 and especially USB3.1 are much faster at 5Gbit/s and 10Gbit/s. Even the camera I'm using seems to be limited by the bandwidth (at 1920x1200) and not the sensor read speed. The fastest area scan cameras are therefore USB3 - too. For this reason I see no point in using the ethernet cameras. Both should work with the existing standards of course, so adding support for both should be trivial.

Of course if this was a consumer device it would have a video encoder, but that would most likely increase the costs by a significant margin. I like the way it currently is and would focus on having software (and pc hardware) support for the cameras. For linescan cameras, which I would also like to test with CrossMgrVideo, Ethernet is plenty enough (since they capture only 1xxx by 1-3px).

Also, the GeniCam supported formats all seem to be binary. Without direct jpeg access from the camera, the CrossMgrVideo write queue will remain an issue (the higher the frame rate, the worse it will get).

My understanding is that the cameras only output in a RAW format (Bayer RG8, Bayer RG12 & Bayer RG12p), and don't have any type of encoder. The camera that I have is 29.3 mm x 29 mm x 29 mm in size, so there wouldn't be much room for anything else than a DSP and a USB controller...

The performance of video cameras continues to improve, and I expect to see low cost cameras with frame rates rivaling scan-line cameras in the near future.

I wouldn't get my hopes up on this since many smartphones have had slow motion capabilities for many years now. Usually, on Android for example, you can only use the manufacturer provided app (drivers) to record at >30/60fps. I haven't been able to stream at more than 30fps from my Oneplus 3T using 3rd party apps for example.

Also a major advantage of industrial cameras is the global shutter, which isn't common in anything destined for consumers.

So, I will look at the GeniCam interface. Unfortunately, buying a GeniCam compliant camera to test with is out of the budget for now.

I have these cameras on loan for a couple of weeks, and If you want, I can setup a virtual machine or something for you to test them out via a remote connection! I will have to check the performance first, though it shouldn't be much worse than without virtualization.

[rkantos]

Also, I recommend you to (or anyone) to check out the Basler frame rate calculator, which further outlines the advantages of USB3 in high speed applications. https://www.baslerweb.com/en/products/tools/frame-rate-calculator/

Btw... There is a lot of support for Basler and IDS cameras in Kinovea that I've now learned. Kinovea seems to use the Basler SDK directly. I thought their source might of help, though it's implementation is mostly based on Microsoft libraries and frameworks:

http://www.kinovea.org/wiki/doku.php/infosfordeveloppers https://bitbucket.org/kinovea/kinovea/overview

[rkantos]

Would it be possible to make the underlying ffmpeg use hardware encoders and decoders too? Almost every computer has a nice graphics card that can work wonders when encoding images, videos etc. Even QuickSync found on any Intel cpu with a GPU is pretty good at encoding jpgs. Using any Nvidia GPU (Nvenc) should work wonders when going to 1000s of fps!

Currently it seems cpu encoding and disk write performance is the largest issues.

Btw.. Is there a way to save the database file to a RAMdisk?

https://trac.ffmpeg.org/wiki/HWAccelIntro

[rkantos]

Yeah. This will definitely work. It already does function, but just isn’t too practical. It does need a few new features to be fully functional. These should be trivial enough to add.

• Custom location for the recording database (so that a RAMDisk or a secondary NVMe storage etc can be used)
• Another way to try to solve the same issue (which is bandwidth) is to have CrossMgrVideo cache RAW from the camera to the memory while writing the MJPEG to the memory as well. After this it should save to disk. This seems to be how Basler Pylon Viewer recording feature works.
• Custom framesize. Only really the number needs to be discernible from a single picture. This means that I could record at 1920x200 and have the camera rotated in relation to the finish line. I got an NVMe -drive and was able to capture nearly all frames @ 320x240 @ ~736fps (I captured ~720 frames). However with larger framesizes not everything from the output of the camera is captured, because the frames are seemingly dropped, since they are not encoded in time. at 1280x720 @ ~270fps I captured only about 100-150fps. Writing in RAM should fix this problem. (either a RAMDisk or a program level implementation)

Image (two 1s captures and 1x5s capture. ~720 to 732fps compared to 736fps from the camera’s output.) (the camera was shooting mostly black, thus why probably the encoder was able to keep up)

Optional:

• Add full linescan support. This will obviously only work if absolutely every frame will be captured. Thus everything will probably need to be written to RAM. This also requires the custom framesize and support for rotating the camera input Then also the whole “image” stream needs to be zoomable, because the capture will look like what a finish line camera capture looks like. There is no point zooming the individual lines of pixels :)
• Support for 2nd lower framerate camera that can be synced with the images

[rkantos]

Just adding it here so I don’t forget.. Capturing at ~700fps or whatever the framerate is that makes the program hang for a moment. This probably is not going to be feasible in the near future without a 16 core or even a 32 core Ryzen cpu.. (still cheaper than a finish line camera though..). Therefore it is a prequisite to have CrossMgrVideo be able to capture much less image information (with a smaller AOI being the industrial camera term. Full line scan (say 1920 by 1 pixels) support either with an area scan camera or even with a line scan camera will most likely not be possible with just the current version of reading a camera. Professional finish line -cameras have an internal memory, and therefore will not drop frames. Skipping anything more than a couple frames would make the picture unreadable, because the vertical resolution consists of every frame. Therefore a camera without caching or similar features will most likely require to capture at least the race bib number’s worth of vertical resolution. This way skipping one frame occasionally should not lead to major problems.

Capturing is also difficult, because filling up the memory buffer probably just makes CrossMgrVideo crash (I have’t tested this yet). Ideally CrossMgrVideo should support a hotkey where a button could be kept pressed down when capturing should happen. Also toggling the capture on/off should be possible.

Here is a sample from a recent race I was timing:

You can see that the only thing really required to make this view match that of Finish line cameras is to make the view containing all the images zoomable, and of course, capture a few more frames (at a lower resolution). What you can also see from the image that the capture rate definitely was not constant, as it never is. This was one of the captures where I got the most frames when already having run one capture. This totaled to 649 frames in 5 seconds, meaning 129fps with a target framerate of 274fps. I think the framedropping could be avoided already by just saving both the raw capture and subsequent encoded MJPEG to RAM first, and then writing it to the disk. With this method, the Basler SDK included Pylon Viewer does not drop any frames!

[rkantos]

This is what I managed with batch scripts and processing with ImageMagick!

Short description of steps:

• Turn camera on it’s side to maximize resolution and framerate. The Basler camera (or the Sony sensor rather) reads the fastest when vertical resolution is reduced.
• Record .tiff images in Pylon Viewer (HxV 2x1928px )
• Use a batch script with ImageMagick’s montage command to turn the images 90 / 270 degrees (also mirror depending on direction of travel…)
• Use a batch script with ImageMagick’s montage command to stich the images together

After this you get the end result. There wouldn’t be much work required for CrossMgrVideo to make it function like this! The viewer part would only really require a zoom and a scroll functionality to be able to make out the numbers.

With current batch scripting method this takes about 6 minutes on a dual core cpu for 10 seconds of 1000fps…

[rkantos]

Here are some results that I’ve made with the camera I had! It is possible to get a camera that has similar performance (2x1928px @ >1000fps) for much less than the acA1920-155uc. I managed to write some kind of batch/autohotkey script for Windows, that handles recording from Pylon Viewer and then quickly transforms and appends the images to a “linescan” image. With the help of @MarkSetchell @ Stackoverflow I was able to get the image formation part down to seconds, instead of minutes.

https://stackoverflow.com/a/52610569/5776626

First one taken with a acA1920-150um, which has a different FOV on the same 8mm lens that I was using because of different sensor size. It is Difficult to judge performance between the 150um (monochrome) and 155uc (color).

[JonRosenSystems]

Super! Thanks for sharing. I have also been working on the same project with these parts: Basler spl-2048km (2k line scan with 39khz frequency) with camera link interface connected to a PCI express card from EPIXinc.com. EPIX has their own software, I've yet to get the software setup and running so you are further ahead. On Friday, October 05, 2018 10:50 PM, rkantos wrote:

Date: Fri, 05 Oct 2018 19:50:36 -0700 From: rkantos To: esitarski/CrossMgr CrossMgr@noreply.github.com cc: JonRosenSystems jrosen@jonrosensystems.com, Manual manual@noreply.github.com Subject: Re: [esitarski/CrossMgr] Support for high speed area and linear scan industrial cameras (#11)

Here are some results that I’ve made with the camera I had! It is possible to get a camera that has similar performance (2x1928px @ >1000fps) for much less than the acA1920-155uc. I managed to write some kind of batch/autohotkey script for Windows, that handles recording from Pylon Viewer and then quickly transforms and appends the images to a “linescan” image. With the help of @MarkSetchell @ Stackoverflow I was able to get the image formation part down to seconds, instead of minutes.

https://stackoverflow.com/a/52610569/5776626

First one taken with a acA1920-150um, which has a different FOV on the same 8mm lens that I was using because of different sensor size. Difficult to judge performance — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread. On Friday, October 05, 2018 10:50 PM, rkantos wrote:

Date: Fri, 05 Oct 2018 19:50:36 -0700 From: rkantos To: esitarski/CrossMgr CrossMgr@noreply.github.com cc: JonRosenSystems jrosen@jonrosensystems.com, Manual manual@noreply.github.com Subject: Re: [esitarski/CrossMgr] Support for high speed area and linear scan industrial cameras (#11)

Here are some results that I’ve made with the camera I had! It is possible to get a camera that has similar performance (2x1928px @ >1000fps) for much less than the acA1920-155uc. I managed to write some kind of batch/autohotkey script for Windows, that handles recording from Pylon Viewer and then quickly transforms and appends the images to a “linescan” image. With the help of @MarkSetchell @ Stackoverflow I was able to get the image formation part down to seconds, instead of minutes.

https://stackoverflow.com/a/52610569/5776626

First one taken with a acA1920-150um, which has a different FOV on the same 8mm lens that I was using because of different sensor size. Difficult to judge performance

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/esitarski/CrossMgr/issues/11#issuecomment-427540326

[rkantos]

Ah yes,

This is most likely what @esitarski needs for Basler & IDS camera support (the most readily available cameras, in Europe at least.)

https://pypi.org/project/pyueye/

https://github.com/basler/pypylon

Of course most of GigE stuff is probably possible to be done through the generic GenICam python libraries, but for IDS and Basler Area scan cameras, I think using the frameworks above is necessary.

[esitarski]

I released a new version of CrossMgrVideo that allows you to change the folder for the .sqlite file (in the Manage Database dialog). This allows you to put it on a RamDisk for better performance. I tried to find some benchmarks for a speed improvement., but I could not find anything reliable. Let me know how much faster it is to open a sequence and if the delay after capture is shorter.

On Sat, Oct 6, 2018 at 2:42 PM rkantos notifications@github.com wrote:

Ah yes,

This is most likely what @esitarski https://github.com/esitarski needs for Basler & IDS camera support (the most readily available cameras, in Europe at least.)

https://pypi.org/project/pyueye/

https://github.com/basler/pypylon

Of course most of GigE stuff is probably possible to be done through the generic GenICam python libraries, but for IDS and Basler Area scan cameras, I think using the frameworks above is necessary.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/esitarski/CrossMgr/issues/11#issuecomment-427597143, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJrqWEqoQbFrhTNytYHKbC9akyFkP5iks5uiPmkgaJpZM4WHWOI .

--

Edward Sitarski

[esitarski]

You can see that the only thing really required to make this view match that of Finish line cameras is to make the view containing all the images zoomable...

Your screen shot shows the finish strip. When you move the cursor, CrossMgrVideo shows the current frame in the little photo on the right. One you have found a frame of interest, have you tried doing a right-click? This will open a zoom in dialog. Inside that dialog, you can drag-and-drop a rectangle and zoom in further on any portion of the photo. If you roll the mouse wheel, you will advance and retreat one frame at a time while maintaining the zoom window. Does this meet your requirement for more zoom?

On Sun, Sep 23, 2018 at 6:29 PM rkantos notifications@github.com wrote:

Just adding it here so I don’t forget.. Capturing at ~700fps or whatever the framerate is that makes the program hang for a moment. This probably is not going to be feasible in the near future without a 16 core or even a 32 core Ryzen cpu.. (still cheaper than a finish line camera though..). Therefore it is a prequisite to have CrossMgrVideo be able to capture much less image information (with a smaller AOI being the industrial camera term. Full line scan (say 1920 by 1 pixels) support either with an area scan camera or even with a line scan camera will most likely not be possible with just the current version of reading a camera. Professional finish line -cameras have an internal memory, and therefore will not drop frames. Skipping anything more than a couple frames would make the picture unreadable, because the vertical resolution consists of every frame. Therefore a camera without caching or similar features will most likely require to capture at least the race bib number’s worth of vertical resolution. This way skipping one frame occasionally should not lead to major problems.

Capturing is also difficult, because filling up the memory buffer probably just makes CrossMgrVideo crash (I have’t tested this yet). Ideally CrossMgrVideo should support a hotkey where a button could be kept pressed down when capturing should happen. Also toggling the capture on/off should be possible.

Here is a sample from a recent race I was timing:

[image: image] https://user-images.githubusercontent.com/16664350/45933570-5d891800-bf98-11e8-9994-0735b103b2a8.png

You can see that the only thing really required to make this view match that of Finish line cameras is to make the view containing all the images zoomable, and of course, capture a few more frames (at a lower resolution). What you can also see from the image that the capture rate definitely was not constant, as it never is. This was one of the captures where I got the most frames when already having run one capture. This totaled to 649 frames in 5 seconds, meaning 129fps with a target framerate of 274fps. I think the framedropping could be avoided already by just saving both the raw capture and subsequent encoded MJPEG to RAM first, and then writing it to the disk. With this method, the Basler SDK included Pylon Viewer does not drop any frames!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/esitarski/CrossMgr/issues/11#issuecomment-423852839, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJrqb89yqJq2F_MDraeV3kq4B0PeHglks5ueAtbgaJpZM4WHWOI .

--

Edward Sitarski

[rkantos]

I released a new version of CrossMgrVideo that allows you to change the folder for the .sqlite file (in the Manage Database dialog). This allows you to put it on a RamDisk for better performance. I tried to find some benchmarks for a speed improvement., but I could not find anything reliable. Let me know how much faster it is to open a sequence and if the delay after capture is shorter.

Thanks! I’ll try the RAMDisk. Could you also add the custom size for the frames?

Your screen shot shows the finish strip. When you move the cursor, CrossMgrVideo shows the current frame in the little photo on the right. One you have found a frame of interest, have you tried doing a right-click? This will open a zoom in dialog. Inside that dialog, you can drag-and-drop a rectangle and zoom in further on any portion of the photo. If you roll the mouse wheel, you will advance and retreat one frame at a time while maintaining the zoom window. Does this meet your requirement for more zoom?

I recognize and have used this feature. However what I’m thinking for a finish line image viewing, the whole “strip” is the image, consisting of thousands of images few pixels wide (depending on camera, line scan 2px, mono area scan 1px etc) As I said, preliminary support with 200px wide images could also work, then CrossMgrVideo would not need to make a “strip” from the line scans and you would be able to discern individual numbers from a single image. For this the ability to rotate the input from the camera is required.

[esitarski]

The download is available here https://sites.google.com/site/crossmgrsoftware/downloads. Scroll down to CrossMgrVideo and choose version 2.30.27.

On Sat, Oct 6, 2018 at 7:26 PM rkantos notifications@github.com wrote:

I released a new version of CrossMgrVideo that allows you to change the folder for the .sqlite file (in the Manage Database dialog).

Where can I get this download? I cannot see a new version on the website?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/esitarski/CrossMgr/issues/11#issuecomment-427613375, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJrqeq5VXoQYym7VUQwe2ke2H0k75TTks5uiTwfgaJpZM4WHWOI .

--

Edward Sitarski

[rkantos]

Here are things I managed to literally “stitch” together: https://www.youtube.com/watch?v=yMfrYACGzgA&index=1&list=PLgq9ECzoG1QR_UR8c9vYhLEPSl-zEpFyL

Also included is a video of CrossMgrVideo working @ >250fps.

[rkantos]

I was able to get a nice deal on an IDS industrial camera from eBay.. The only difference to the Basler camera I had for testing previously is that it doesn’t include USB3Vision support, and thus it doesn’t work with things like Aravis or Qarv :/

@esitarski : Do you still think it would be feasible to use the pyueye and pypylon libraries to get support for the cameras instead or in addition to the GenICam library? I am able to provide a full testing setup with the IDS-camera via remote desktop for however long is necessary with either Linux or Windows! I am also considering donating a camera - too. Ethernet (GenICam) cameras are readily available, and the versions with inferior resolution are not even that expensive.. However as stated before, especially when trying to capture higher framerates, the 1Gbit/s bandwidth can still be an issue when trying to reach 1000fps (which results to 1ms accuracy). There are many cameras that do just under 1000fps in their GigE variant, but with USB3 go to over 3000fps. Of course for development purposes and even relative timing this can be sufficient. There are GigE cameras with 800x600 resolution on eBay and elsewhere that can readily be had for ~100$ shipped. They should be able to reach 1000fps levels at 800x4 / 800x2 resolution.