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

minor suggestions for code improvement #122

Open
mitjap opened this issue Nov 28, 2020 · 5 comments
Open

minor suggestions for code improvement #122

mitjap opened this issue Nov 28, 2020 · 5 comments

Comments

@mitjap
Copy link
Contributor

mitjap commented Nov 28, 2020

Shouldn't this check bi inside of ModeFunctions<Config::OpenCV>::refine function?

if (iter >= MAX_ITERATIONS) {

There is already a comment in place suggesting this:

// Or we quit the loop by exceeding the limit, and reject the point anyway.

Hope I'm not nitpicking here :) Just trying to make code be more readable. I'm also aware this should probably just be PR but I don't really have time to test and verify this claim.

@mitjap
Copy link
Contributor Author

mitjap commented Nov 29, 2020

return ( fabsf( val ) >= 0.8f * 2.0f * d_consts.threshold );

return ( fabsf( val ) >= 1.6f * d_consts.threshold );

if( fabsf(contr) < scalbnf( d_consts.threshold, 1 ) )

I also don't think this 2.0f factor should be here. I understand that it is here just to negate some multiplication 0.5f which is made in Config::getPeakThreshold.
return ( _threshold * 0.5f * 255.0f / levels );

Looking at commit history this was made to adapt algorithm to OpenCV behaviour so it is reasonable to put this multiplication in ModeFunctions<Config::OpenCV>::first_contrast_ok and remove it elsewhere.

@mitjap
Copy link
Contributor Author

mitjap commented Nov 29, 2020

Is there a reason that values values in textures are multiplied by 255.0f? Float values are usually in range [0-1]. I don't see any reason for doing so and I think can be removed.

surf2DLayeredwrite( out * 255.0f, dst_data, write_x*4, write_y, 0, cudaBoundaryModeZero );

surf2DLayeredwrite( out * 255.0f, dst_data, write_x*4, write_y, level, cudaBoundaryModeZero );

return ( _threshold * 0.5f * 255.0f / levels );

fval *= 255.0f; // don't forget to upscale

/// default threshold 0.04 / (_levels-3.0) / 2.0f * 255

@mitjap
Copy link
Contributor Author

mitjap commented Nov 29, 2020

I think there might be an error in some cases.

In case where algorithm reaches MAX_ITERATIONS then variable n might have been modified in ModeFunctions<>::refine by -1 or +1 if d is >0.6. Later on n is again modified by d even though part of d was already taken into account in refine.

n.x += t.x;

const float xn = n.x + d.x;

To fix this issue something like this should be added to refine function for PopSift and VLFeat modes.

d.x -= t.x;
d.y -= t.y;
d.z -= t.z;

OpenCVmode should have something like this:

d.x -= roundf( d.x );
d.y -= roundf( d.y );
d.z -= roundf( d.z );

@mitjap mitjap changed the title minor suggestion for code improvement minor suggestions for code improvement Nov 29, 2020
@griwodz
Copy link
Member

griwodz commented Nov 29, 2020

@mitjap Sorry that I'm silent - end of semester, examining, grading, admission of new students etc.
I'm glad that someone is giving the code a thorough review!

@stale
Copy link

stale bot commented Jun 2, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Jun 2, 2021
@simogasp simogasp added this to the v1.0.0 milestone Jun 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants