Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implemented AcquisitionFrameCount on Fake-camera #699

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

LorenzoBalducci96
Copy link

The first frame is immediately taken, but maybe is correct to wait the framePeriod also on the first frame?

Copy link
Contributor

@EmmanuelP EmmanuelP left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi,

Thanks for your work on this feature. It could go in, but there is several things to fix first.

In addition to the other comments, there is also this 2 points:

FrameCount should only taken into account if AcquisitionMode is MultiFrame.

I'm not sure, but it looks like the counter is not reset at every AcquisitionStart.

Comment on lines +6 to +253
# NuGet Packages
*.nupkg
# The packages folder can be ignored because of Package Restore
**/packages/*
# except build/, which is used as an MSBuild target.
!**/packages/build/
# Uncomment if necessary however generally it will be regenerated when needed
#!**/packages/repositories.config
# NuGet v3's project.json files produces more ignoreable files
*.nuget.props
*.nuget.targets

# Microsoft Azure Build Output
csx/
*.build.csdef

# Microsoft Azure Emulator
ecf/
rcf/

# Windows Store app package directories and files
AppPackages/
BundleArtifacts/
Package.StoreAssociation.xml
_pkginfo.txt

# Visual Studio cache files
# files ending in .cache can be ignored
*.[Cc]ache
# but keep track of directories ending in .cache
!*.[Cc]ache/

# Others
ClientBin/
~$*
*~
*.dbmdl
*.dbproj.schemaview
*.pfx
*.publishsettings
node_modules/
orleans.codegen.cs

# Since there are multiple workflows, uncomment next line to ignore bower_components
# (https://github.com/github/gitignore/pull/1529#issuecomment-104372622)
#bower_components/

# RIA/Silverlight projects
Generated_Code/

# Backup & report files from converting an old project file
# to a newer Visual Studio version. Backup files are not needed,
# because we have git ;-)
_UpgradeReport_Files/
Backup*/
UpgradeLog*.XML
UpgradeLog*.htm

# SQL Server files
*.mdf
*.ldf

# Business Intelligence projects
*.rdl.data
*.bim.layout
*.bim_*.settings

# Microsoft Fakes
FakesAssemblies/

# GhostDoc plugin setting file
*.GhostDoc.xml

# Node.js Tools for Visual Studio
.ntvs_analysis.dat

# Visual Studio 6 build log
*.plg

# Visual Studio 6 workspace options file
*.opt

# Visual Studio LightSwitch build output
**/*.HTMLClient/GeneratedArtifacts
**/*.DesktopClient/GeneratedArtifacts
**/*.DesktopClient/ModelManifest.xml
**/*.Server/GeneratedArtifacts
**/*.Server/ModelManifest.xml
_Pvt_Extensions

# Paket dependency manager
.paket/paket.exe
paket-files/

# FAKE - F# Make
.fake/

# JetBrains Rider
.idea/
*.sln.iml
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please don't include unrelated changes.

@@ -1074,6 +1105,7 @@ arv_fake_camera_init (ArvFakeCamera *fake_camera)

fake_camera->priv->trigger_frequency = 25.0;
fake_camera->priv->frame_id = 65400; /* Trigger circular counter bugs sooner */
fake_camera->priv->frameSeqCount = 65535;//max possible value by default for acquisition count
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

don't use C++ style comments

@@ -265,7 +265,6 @@ _thread (void *user_data)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like there is no real change in this file.

Comment on lines +928 to 940
guint64
arv_fake_camera_get_frame_period(ArvFakeCamera* camera)
{
return _get_register (camera, ARV_FAKE_CAMERA_REGISTER_ACQUISITION_FRAME_PERIOD_US);
}

int
arv_fake_camera_get_acquisition_frame_count (ArvFakeCamera *camera)
{
return _get_register (camera, ARV_FAKE_CAMERA_ACQUISITION_FRAME_COUNT);
}

void
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These functions are never used.

@@ -72,6 +72,7 @@ typedef struct {

guint32 frame_id;
double trigger_frequency;
int frameSeqCount;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be multi_frame_count instead of frameSeqCount.

Comment on lines +342 to +347
<Max>65535</Max>
</Integer>

<IntReg Name="AcquisitionFrameCountRegister" NameSpace="Custom">
<Address>0x310</Address>
<Length>4</Length>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use a 64bit integer, 65535 seems to small.

@EmmanuelP
Copy link
Contributor

Fake camera should stick to the behavior describe in the Genicam SNFC document: https://www.emva.org/wp-content/uploads/GenICam_SFNC_v2_7.pdf

@LorenzoBalducci96
Copy link
Author

Hi thanks for the interest.

From the Genicam SNFC document I read: "AcquisitionFrameRate controls the rate at which the Frames are captured when TriggerMode is Off.".
So it seems that this parameter must be taken into account when not using triggered mode acquisition. (so I guess it defines the framerate when acquisitionMode is continous). So it should be correct to not take into account the framerate when sending multiFrames in triggered mode and send frames immediately as soon as are available in the fake-camera?.
However in basler aca1920-50gm/c you can set the AcquisitionFrameRateAbs parameter when acquiring multiFrame in triggered mode and it will define the framerate of the frames acquired after a trigger.
Maybe basler cameras are slightly out of specification?

"the counter is not reset at every AcquisitionStart"
in arv_fake_camera_check_and_acknowledge_software_trigger when the trigger is acknoledged the frameCount is reset to 1 and is increased every new frame. Since the frameCount is smaller than AcquisitionFrameCount register the arv_fake_camera_check_and_acknowledge_software_trigger still returns true meaning that a new frame must be taken (the trigger was already acknoledged at first frame). Once the acquisitionFrameCount is reached, the frameCount is set to 65535 in order to be bigger than any other acquisitionFrameCount that could be set before the next trigger causes the reset of the frameCount.
Do you propose a better solution?

every other notes are for shure reasonable for the next commit.

@EmmanuelP
Copy link
Contributor

From the Genicam SNFC document I read: "AcquisitionFrameRate controls the rate at which the Frames are captured when TriggerMode is Off.". So it seems that this parameter must be taken into account when not using triggered mode acquisition. (so I guess it defines the framerate when acquisitionMode is continous). So it should be correct to not take into account the framerate when sending multiFrames in triggered mode and send frames immediately as soon as are available in the fake-camera?.

Yes.

However in basler aca1920-50gm/c you can set the AcquisitionFrameRateAbs parameter when acquiring multiFrame in triggered mode and it will define the framerate of the frames acquired after a trigger. Maybe basler cameras are slightly out of specification?

Most camera manufacturers don't strictly stick to the SNFC, mostly because they started the work on their firmware and SDK before the SNFC even exists.

"the counter is not reset at every AcquisitionStart" in arv_fake_camera_check_and_acknowledge_software_trigger when the trigger is acknoledged the frameCount is reset to 1 and is increased every new frame. Since the frameCount is smaller than AcquisitionFrameCount register the arv_fake_camera_check_and_acknowledge_software_trigger still returns true meaning that a new frame must be taken (the trigger was already acknoledged at first frame). Once the acquisitionFrameCount is reached, the frameCount is set to 65535 in order to be bigger than any other acquisitionFrameCount that could be set before the next trigger causes the reset of the frameCount. Do you propose a better solution?

There is no reason to couple AcquisitionFrameCount and TriggerSoftware, they are unrelated. AcquisitionFrameCount is here to set the number of acuiqred frames when AcuisitionMode is set to MultiFrame, wether the camera is free running or triggered.

@EmmanuelP EmmanuelP marked this pull request as draft August 22, 2022 09:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants