anchor.diff:  ....
   
   `resample_dim` is how you resample the image before storing in a vector that will be used for the hashing, thus, dimensions of resampling before hashing. The bigger the dimensions, smaller the size of the vector. 
  -There is not saving of storage in the engine, but it's much faster to hash a small vector, for both indexing and querying. Also in terms of neurovault's storage is better to have smaller reduced representations if we are using them just  for comparison. From 4mm to 16mm the diff is over 10x faster.
  +There is not saving of storage in the engine, but it's much faster to hash a small vector, for both indexing and querying. Also in terms of neurovault's storage is better to have smaller reduced representations if we are using them just  for comparison. From 4mm to 16mm the diff is over 10x faster, 
  +in link:https://github.com/NeuroVault/NeuroVault/pull/517#issuecomment-227447259[this] comment I made a summarize of the speed tradeoff:
  +
  +
   
   `subjects` is a static parameter. 
   
  
positive.code: 
  Now, we must do an effort to compare visually the results. The first item is the same, that is clear http://neurovault.org/images/10901. The second from the actual and the third of the Engine are also the same, ok, not bad.
  
  Now, let's go to the PDF. From my point of view, from the 3rd result on, the maps are nothing but similar wrt to the query...
  
  Let's see what the Engine is giving as response (I've to copy and paste the results, as we still don't have a find_similar() view for the engine):
  
  - The second one, 759 is not even in the first 100 of the actual implementation. In my local it is this one:
  https://mail.google.com/mail/u/0/?ui=2&ik=dbccbd2714&view=fimg&th=155e88afc9ef680f&attid=0.0.1&disp=emb&realattid=ii_155e8811f7a1581c&attbid=ANGjdJ8g0-0_iOenFRKb9Y8HpJS2G-QGI05S_e0cxNXYIsYUo4oeArbm8NkNkKK6WffKXwg8-tcshYlZeM5AVTRufkwqRAOhHbebI77fn6Tow2CX2S4P9amgjmauBBY&sz=w624-h258&ats=1468485407026&rm=155e88afc9ef680f&zw&atsh=1
  
  
  which seems similar to #74. 
  
  this is #719, the 8th one for the Engine. I took the one that looked more similar from the first 10... (maybe this was advantageous, but it is to show how the engine keeps showing similar images in comparison to the actual implementation, which is giving results based on correlations of 0.22 from the 5th result on and they don't seem to me very "similar"). 
  
  https://mail.google.com/mail/u/0/?ui=2&ik=dbccbd2714&view=fimg&th=155e88afc9ef680f&attid=0.0.2&disp=emb&realattid=ii_155e88610cffcd55&attbid=ANGjdJ_F65vhOBKigVpEDptWZa6qr2AL-W2aq-4YSQLuodslRQl2vX9JGCCNm3rkn0U8-9Ze7go-IcnF5QIy2XqZAyNLoQvQgoZWhU5ZsoKKdymGFsA0Gc22rBCzWFo&sz=w626-h264&ats=1468485407026&rm=155e88afc9ef680f&zw&atsh=1
  
  First of all, sorry about not writing last week, I was super-tired plus there was not much to tell about OHBM; I had a fantastic week, I met both Cameron and Chris in person and a bunch of well known neuroscience developers as well. Also, I had the opportunitty of learning a lot, several interesting posters and hands on in the Hackathon; I will hopefully come back to OHBM 2017, it was a great time. 
  
  ## Comparison framework
  
  So, back to work, this week I've been building a framework to test different combinations of parameters and dimensionality reductions and treatment. My idea so far is to test different combinations of hash number, bit number, distance, resample dimension and Z scored data by now. This leads to a high possible number of combinations, so I will let this calculations for next week (I'm out of the lab atm, and my laptop is not powerful enough). Also, I will load as much maps in my local Neurovault since we decided to not overload the production server with JSON queries that need several hundreds of lines and this will take a bit of time. 
  
  The framework iterates over the whole possibilities, loads specific data and builds a different Engine each time. Loads the full dataset in the Engine and queries one by one all the possible maps. Then, these queries are evaluated against the actual results (previously generated and saved) with DCG (see previous weeks) and saved to report a mean DCG after the whole process. As an example, I've run once the framework with different resample dimensions and the rest of the parameters fixed:
  
  ----
  DCG mean score for  [4, 4, 4]  :  1.76347265478
  DCG mean score for  [6, 6, 6]  :  1.85349872876
  DCG mean score for  [8, 8, 8]  :  1.85167174514
  DCG mean score for  [10, 10, 10]  :  1.80284846337
  DCG mean score for  [12, 12, 12]  :  1.72983034835
  DCG mean score for  [14, 14, 14]  :  1.78070238621
  DCG mean score for  [16, 16, 16]  :  1.8917845196
  ----
  
  The higher the DCG score, the better the result. It seems that a reduction to [6, 6, 6] is a good solution, but also we can get great results by using [16, 16, 16], so this seems to have no direct effect on the performance. 
  
  ### Problems
  
  I've noticed that for a small amount of images, the queries do not give back  100 images (since the number of buckets do not allow it). This is probably going to bias the results. I will think about it, for now, I can only say that it could be solved making an effort and increasing the dataset or normalizing the DCG results by the number of responses for the query. 
negative.code: 4.- Saves and outputs results (mean results for each of the combinations).
  
  
  ## Conclusions and actions
  
  - It is not enough to calculate which combination has the highest DCG, we need also the error between the real_score and the engine_score. I am calculating both atm.
  
  real = the actual implementation results (correlation values)
  engine = the ones I get from Nearpy
  