Negative search range in first pass, fails?

[gabyx]

When I use a negative search range [-2 -1 -2 2]. in the x direction, because my flow has only negative x translation in first pass (where ther is no image advection used) ACCIV terminates with "pass failed" and it says that there are no tie points found and the pass fails...?

output

Using flat geometry Do pass test/pass1 beginning pass parameters read created work directory grid read image times read maximum time separating valid image pairs: 0.001 correlating images image pair 0 1 separation time: 0.001000 range scaling: 1.000000 search range [-2 -1 -2 2] 10% 20% 30% 40% 50% 60% 70% 80% 90% No tie points were found. images correlated Pass failed!

[xylar]

@gabyx , hmm. In principle, that setup should work. There may be a bug I should fix, or maybe the search range just isn't big enough? Could you put the exact configuration you used for that pass on GitHub somewhere so I can try it out myself?

[gabyx]

Hi :-) again,

I ve finally uploaded the test folder:

https://github.com/gabyx/ChuteExperiments/tree/3a2655e76e735c877f446979c6ebe3efb0b08755/scripts/testACCIV

It should work out of the box by executing ./passScript.sh (customice the acciv executable path in this file)

The 3 passes work right now. But if you change it to negative in this file https://github.com/gabyx/ChuteExperiments/blob/3a2655e76e735c877f446979c6ebe3efb0b08755/scripts/testACCIV/test/pass1/parameters.ascii

Then it wont work, strangely, ACCIV also by default sets any zero search range to +/- 1. Is that indented? So we cant limit the search range to only a x-range.

[xylar]

Hi @gabyx,

I'm downloading the latest changes to origin/master right now. I'll take a look as soon as it's done.

In the mean time, your question:

strangely, ACCIV also by default sets any zero search range to +/- 1. Is that indented? So we cant limit the search range to only a x-range.

Yes, that's right. It isn't generally useful to set the search range to have zero size because there are always variations (though maybe less than a pixel) in each direction. That is certainly true in your flow. CIV methods work by searching for the minimum in a 2D function that is first sampled over the search range and then is optimized to sub-grid-scale by interpolating image intensities shifted by fractions of a pixel. The process is designed fora 2D field and would have to treat a 1D field as a special case. Since I never had a case where I wanted a 1D field, I didn't support that case. I frankly don't think that restricting ACCIV to 1D is the right solution for your problem either.

One think that might give you better results with ACCIV, though, would be to look at images separated by longer times. This will give you a velocity field that is averaged over the longer time, but it will also tend to be more accurate. If you think the velocity is relatively constant over several frames, I would use images that are 5 frames apart or something like that and see if the results are better. Obviously, you'll need to increase the search range appropriately.

[gabyx]

Thanks :-)

I am little confused, because one can really think of anykind of combination of frames in a range of +-5 frames around a time point lets say t = 0.001 , so I could do the following, while decreasing the corr. box size

**pass 1** :
   frame A t=0.000
   frame B t=0.001
   frame C t=0.002

**pass 2**: (advect from pass 1)
   frame A t=0.000
   frame B t=0.001
   frame C t=0.002

**pass 3**: (advect from pass 2)
   frame A t=0.000
   frame B t=0.001
   frame C t=0.002

or I could do something like:

**day1**  :
  pass 1:
      frame A t=0.000
      frame B t=0.001
   pass 2 (advect from day1/pass1):
      frame A t=0.000
       frame B t=0.001

**day2**  :
  pass 1:
     frame B t=0.001
     frame C t=0.002
  pass 2: (advect from day2/pass 1)
     frame B t=0.001
     frame C t=0.002

**day 3**: (advect from pass 2)
  pass 1:
     earlierImageIndices = [A, B]
     laterImageIndices = [B, C]
     inEarlierVelocityFileName   = day1/pass2 ...
     outEarlierVelocityFileName = day2/pass2 ...

Is there any difference, (whats the difference between day3/pass1 , which uses some earlier/later settings and the normal passes like day1/pass1 or day1/pass2 ?

Thanks a lot for your effort!

[xylar]

First off, there is definitely a bug in the computation of the search range when +-1 is not part of the range. I'm working on that right now.

[gabyx]

No worries, thanks for fixing it :-), at least there are no memory leaks (did not check, but it seems pretty reliable ;) or segfaults :-)

[xylar]

Now to your second comment/questions.

I can see why the multiple passes vs. multiple "days" might be confusing. The paper I wrote discusses the difference between images separated by "short" times and "long times". Images separated by "short" times can be correlated with each other without any trouble. The velocity field doesn't have any strong shearing, rotation or divergence over short times that will make features hard to follow. Over "long" times, CIV on its own will have a hard time finding correlations without some help from advection. So in order to correlate images separated by "long" times, you have to first get a guess at the velocity field from images seprated by "short" times and use that to advect the images separated by "long" times to a common point in time.

All those tricks are likely more trouble than they're worth for your problem. My guess is that frames separated by less than 10 ms (maybe even more) are going to be easy to correlate. So you should not worry too much about the concept of days. You can just try out using 2, 3, 4, 5, ... consecutive images together and figure out a multiple pass setup that works well. Let's say you find that 5 images gives you the best results. Then you can just do the same procedure with images 2-6 that you just did with 1-5 and you will get a velocity field that's appropriate for 1 frame later (but averaged over 5 frames).

If that doesn't make sense, I can see if I can set up an example.

[gabyx]

That makes perfect sense :-) thanks

[xylar]

Okay, I just pushed an update to the ACCIV repository so the search range now works properly when it's only negative.

Note that for subsequent passes the search range is in the advected images, so it should always be centered around 0 even when the search range for in the original pass is not. I think you probably want to change the x search range to be between -1 and 1 for subsequent passes, even though the velocity comes out in the range of -2 to 0 or so.

Also, you might have better results with the subsequent passes if you increase the smoothing in the smooth fit to eliminate more of the noise. I tried smoothFitMinControlPointScatteredNeighbors = 100 for pass 2 and smoothFitMinControlPointScatteredNeighbors = 400 for pass 3 with good results. (You will need to add these parameters to your individual parameters.ascii since it is only in the defaultParameters.ascii for now.) However, I don't think you're getting much improvement beyond the pass 1 results even with a smaller correlation window because the results are just too noisy.

One way to get a more accurate velocity field would be to use the first 5 frames instead of just the first 2. Then you can make the search range bigger and the results from all the image pairs will be averaged together. Each pass will be slower, though, and the results will be more smoothed in time. You'll have to decide what works best for you.

[gabyx]

Greate, thanks alot for the usefull update! I will try your consideration tomorrow! :-)