Fix bug while encoding Fourier features in finetune/finetune_region.py

[manugaurdl]

Bug

Data mismatch error in torch/region/fourier_features with input tensor being FP16 and frequency matrix beign BF16

Error trace

File "/home/manugaur/moondream/moondream/finetune/finetune_region.py", line 179, in main
    encode_coordinate(bb[0].unsqueeze(0), model.region),
  File "/home/manugaur/moondream/moondream/torch/region.py", line 43, in encode_coordinate
    return w.coord_encoder(fourier_features(coord, w.coord_features))
  File "/home/manugaur/moondream/moondream/torch/region.py", line 28, in fourier_features
    f = 2 * math.pi * x @ w
  File "/home/manugaur/vlm_obj_det/.venv/lib/python3.10/site-packages/torch/utils/_device.py", line 103, in __torch_function__
    return func(*args, **kwargs)
RuntimeError: expected mat1 and mat2 to have the same dtype, but got: c10::Half != c10::BFloat16```

Patch

encode_coordinate(bb[0].to(model.region.coord_features.dtype).unsqueeze(0), model.region),
encode_coordinate(bb[1].to(model.region.coord_features.dtype).unsqueeze(0), model.region),
encode_size(bb[2:4].to(model.region.coord_features.dtype).unsqueeze(0), model.region).squeeze(0),

[ErenAta16]

The dtype/shape fix that matches the PR title looks right in isolation: encode_coordinate/encode_size need their input cast to model.region.coord_features.dtype before the lookup (the bboxes coming out of the dataloader are plain float32, the region head's buffers aren't), and encode_size needing a batched (1, 2) input with a .squeeze(0) after instead of a bare (2,) tensor tracks with it being written for a batch dimension internally. That part is a real, narrow fix.

Flagging something more urgent first, though: finetune_region.py's main() calls

ds = download_dataset("4BDHggHM6vkVOoK3g0s3", "objectdetvlm", "water-meter-jbktv-7vz5k-fsod-ftoz-qii9s", 1)

download_dataset's signature is (api_key, workspace, project_name, version_num), so that first string is a live Roboflow API key committed directly into the diff. It's already public now that this PR is open. Worth rotating that key on the Roboflow side regardless of what happens to this PR, a force-push or edit here won't undo the exposure once it's been pushed to a public remote.

Separately from the security issue, this PR also bundles the actual bugfix together with a fairly large, personal training-script rewrite: a new Roboflow.py dataset loader, an mAP.py eval module, a notebook, .gitignore entries for a specific dataset folder and a hardcoded absolute path (/home/manugaur/moondream/models/model.safetensors), plus assorted commented-out code and TODOs. None of that is wrong to have in your own fork, but merged as-is it ships a personal, one-off training setup (and now a leaked key) into the shared repo's history. Might be worth splitting: the coordinate-dtype fix as its own small PR, and the Roboflow/eval tooling as a separate, genericized contribution (env var for the API key, configurable paths) if that's meant for others to use too.