The paper states “We expect that techniques that explicitly optimize the estimation will make that normalization unnecessary”, but it seems possible to implement normalization as a postprocessing step for track 2, following the example of the score normalization script. Here’s a sketch:
The distance between a query and a reference image is
d_qr = sqrt(sum((x_qi - x_ri)^2))
If the descriptors have norm 1,
d_qr = sqrt(2 - 2x_q.x_r)
If we add 1 new dimension and set it to the per query offset for query vectors and to 0 for reference vectors,
d_qr = sqrt(2 - 2x_q.x_r + x_qn^2) = sqrt(2 - 2*(x_q.x_r - x_qn^2/2))
It would be good to know if implicit score normalization is allowed for track 2 and if so, to extend the script functionality to produce output for track 2
Hi greenfieldvision. Apologies for the delay in responding.
I’m not sure I totally understand the question, so feel free to clarify if what follows does not help.
You will want to keep in mind the competition rules related to treating each reference image independently. See this section of the Rules if you are not already familiar with it:
…the used approach should have an equivalent result if all of the reference images are provided at once, or if they are provided in chunks over time. We restrict the focus here, and only allow approaches that treat each new image of the reference set independently and without any interaction with other reference images.
Any normalization you do should therefore depend only on each individual vector. The training set may be a useful resource if you need to compute fixed parameters for any normalization steps.
I hope this helps, but I may not be fully understanding your question. Feel free to clarify if needed.
Thanks dd-mike. The question was not about whether other query or other reference images can be used when computing embeddings, but about normalization for track 2. If you look at the score normalization script, it uses training images to do normalization, as per the equation 2 in the paper (https://arxiv.org/pdf/2106.09672.pdf). However, this script only produces track 1 output and I was wondering if it’s acceptable to extend this functionality to track 2. I will take this
