search

ComputationalRadiationPhysics / imresh

Shrink-Wrap Phase Reconstruction Algorithm
MIT License
3 stars 2 forks source link

False results when calling shrink wrap multiple times #21

Closed Ferruck closed 8 years ago

Ferruck commented 8 years ago

When calling the algorithm multiple times at once like in the following

for( int i = 1; i < 30; i++)
{
    imresh::io::addTask( file.first, file.second, imresh::io::writeOutFuncs::writeOutPNG, "imresh_" + std::to_string( i ) + "_cycles.png", i );
}

the results get worse with each loop. After a few loops only a black image is returned (have a look at the attached images, sorry for the inversed order). Also the algorithm's output switches to [Error -nan/1e-05] [Cycle 0/2] for each loop.

Fine tuning of the shrink wrap parameters have not solved this issue for me.

It seems like the different algorithm calls influence each other.

imresh_29_cycles imresh_28_cycles imresh_27_cycles imresh_26_cycles imresh_25_cycles imresh_24_cycles imresh_23_cycles imresh_22_cycles imresh_21_cycles imresh_20_cycles imresh_19_cycles imresh_18_cycles imresh_17_cycles imresh_16_cycles imresh_15_cycles imresh_14_cycles imresh_13_cycles imresh_12_cycles imresh_11_cycles imresh_10_cycles imresh_9_cycles imresh_8_cycles imresh_7_cycles imresh_6_cycles imresh_5_cycles imresh_4_cycles imresh_3_cycles imresh_2_cycles imresh_1_cycles

bussmann commented 8 years ago

I didn't look at the source, but look for memory reuse, global variables and problems with streaming / synchronization.

mxmlnkn commented 8 years ago

If the first argument of addTask is _h_mem, so file.first in this case, then aren't you calling shrinkWrap with the same pointer to rIntensity multiple times? Note that rIntensity is both input and output host memory, If you are calling it 30 times with the same pointer then the first finished thread overwrites input values (also needed inside the cycle) of other threads. That's my 10-minute-guess, would have to look and test it, if what I'm saying is correct.

Ferruck commented 8 years ago

I fear that you're right, @mxmlnkn . I'll test that right now and if it's right I'm incredibly sorry for that dumb fault.

mxmlnkn commented 8 years ago

Don't sweat it. The documentation is a bit incomplete and has some inconsistencies. In the first place functions mentioned in .h shouldn't be documented in their bodies like I did with cudaShrinkWrap.

Ferruck commented 8 years ago

Indeed that was the error. Sorry for that. It's not your fault as I knew that the pointer needs to be renewed, just forgot it yesterday. I guess I was a little bit tired.

I now get the independant results I wanted, but the look all nearly the same, but thats another question.

imresh

mxmlnkn commented 8 years ago

these don't like results at all, I mean shouldn't you want to get some structure in return? I.e. what kind of input-data did you use?