search

darrenlafreniere / lafarren-image-completer

Implementation of the research titled: "Image Completion Using Efficient Belief Propagation via Priority Scheduling and Dynamic Pruning"
http://www.lafarren.com/image-completer/
GNU General Public License v3.0
32 stars 18 forks source link

Settings dependent on latticeGapX or latticeGapY aren't re-evaluated when a custom gap size is set #75

Closed daviddoria closed 13 years ago

daviddoria commented 13 years ago

If I run with -sh 11 -sw 11, with a small source pixel region I get errors. However, if I set

out.latticeGapX = 11;
out.latticeGapY = 11;

in LfnIcSettings.cpp, it works properly. This led me to believe that the settings were not actually getting set, and upon closer inspection, they are indeed not.

This is related to issue #73.

darrenlafreniere commented 13 years ago

When I set a breakpoint in AppData::AppData(), on the call to ApplyCommandLineOptionsToSettings(), and step into that method, I see the previously extracted sw and sh options copied into the settings object fine. Also, setting a breakpoint later in LfnIc::Complete shows that the settings.latticeGapX and latticeGapY members are properly set.

Do you have any more details from your debugging work? Is this in a clone from the master branch without any modifications?

daviddoria commented 13 years ago

Ok, so I was looking at the wrong time. I added this in Main.cpp if (options.ShouldRunImageCompletion()) { std::cout << "X: " << appData.GetSettings().latticeGapX << std::endl; std::cout << "Y: " << appData.GetSettings().latticeGapY << std::endl;

and it indeed outputs the correct values.

However, where I was looking was in SettingsConstructHelper() (in LfnIcSettings.cpp). It seems like when the Settings object gets constructed that the default values of latticeGapX/Y are used to compute things like ssd0. Then, later, when latticeGapX/Y are changed, but ssd0 and all dependent values are not recalculated. Surely they should be recalculated - am I just missing where that happens?

darrenlafreniere commented 13 years ago

Good catch, fixed in commit 3343caf96d2316cd23c45bec539819e81bfc7d0b.