picobyte
commented
11 months ago The main reason is, with the current setup the precision of weights stored and read from the db.json are variable - dependent on floating point arithmetic. By storing in a fixed number of bits, the precision becomes fixed; constant. I'm not exactly sure what kind of precision is feasible for the weights of interrogated tags, if there's anything consistent about it at all. If someone knows, we could adjust the SHIFT_WIDTH. Currently there is more than 3 digits precision.
This one is going to be a bit complex. but might be useful if you want to understand how the %@#! this all works.
Currently stored are for the tags / ratings, per label (of tag/rating) a list of interrogation-file index + weight.
This is a float and works because the weight is between 1 and 0 (explicitly clamped, excluding 0) and the index is an incremental integer per file-interrogation. This incremental index is to an array that contains records including the interrogation ID and filename specification.
This issue is to propose the following change: The weight is a fraction but could be written as an 1 / number, and tehn this number can be stored in the low bits, and the interrogation-file index in the high bits, hence. float -> int. However even better might be to first convert the weight fraction to a promille, then promille / number, so that the weight that can be retrieved from this storage value still has three digits precision (correct?).
The variable that collects this storage value is QData.weighed and the origin can be from an interrogation, or from the database stored on disk, namely db.json inside the image directory (to avoid a second image interrogation for an interrogator that was already done). Its storage occurs here and a few lines below
the function that demultiplexes the value again is get_i_wt() called in single_data and finalize_batch, in the same file.
The filters you select in the ui apply to these index-weights, creating a subset, which is then displayed on the right as output.