Hello everyone!
We are a group of female Computer Science students working on our graduation project.
We are having difficulty finding suitable datasets to train a YOLO model.
We found a dataset called **ImageCLEF 2021 DrawnUI Wireframe Datase https://www.aicrowd.com/challenges/imageclef-2021-drawnui-wireframe?utm_source=chatgpt.com**
but unfortunately, it is no longer available for download
**Does anyone have access to this dataset or know how we can obtain it?**
We need it for research purposes only.
Thank you so much to anyone who can help us! ❤️

Disclosure: I'm developing Screph, the application shown in this demo.

This example connects an editable computer-vision pipeline to a CNC job preview. It separates the work surface, five rotated wooden workpieces, clamps and excluded regions, then uses the detected positions to transform existing toolpaths. The operator reviews the overlays before approving the prepared job.

The demonstration uses color segmentation. Intermediate masks are exposed in the interface so detection can be inspected and adjusted. A differently colored knot illustrates an excluded region; this is an example-specific rule, not a general wood-defect detector. Camera calibration and table-plane calibration are separate steps, and stock height is a user setting.

The recording uses a synthetic scene and an internal machining simulator. It demonstrates the software workflow, not measured real-world accuracy or proven robustness under changing lighting, dust or occlusion. Narration and some scene assets are AI-assisted.

I'm interested in feedback on the diagnostic interface: which intermediate results would you want visible before trusting the pose estimate on a real camera feed?

Project: https://screph.com/en/

Hi everyone! I was looking at optical file transfer and saw that Decimen was rather ineffective. Firstly, it's QR-based system really seemed to be designed for paper, where binary design is necessary to prevent ink smudging. On a screen, binary is ineffecient, although luminance makes sense. I looked at a lot of research papers and eventually found this:I saw that OFDM was the logical improvement off QR codes, as it used actual signal processing and luminance instead of binary black-and-white QR. So I decided to base my system off FOCUS. For fast decoding, I also wanted it to be GPU based rather than CPU based, and to deal with frame desync well.

https://vs.inf.ethz.ch/publ/papers/soeroesg-mobisys2016-Focus.pdf After that, I stripped the FOCUS finders (the original finders were ugly and wasted a lot of space) and came up with a custom, compact ring. the ring has around 15 bits of information distributed via Reed Solomon along the giant ring. A GPU can easily decode the ring's RS it by brute forcing the maximum likelihood of each of the 32,768 codewords.

To balance between range and maximizing speed, i created 4 different ring sizes; 32, 64, 128, and 256. Initially I wanted to stick with the browser; however, the browser is woefully inefficient in webcam tuning. After maxing the settings, we were still at 700 KB/s; better than Decimen but hardly a knockout blow. I couldn't switch to 60fps without it oscillating wildly between 1.3 MB/s to 0 MB/s when out of phase. So I decided to focus on a native android instead. LIZARD is a format; decoders can choose how to decode it.

A weak web decoder doesn't prevent me from making a strong native decoder; the format is the same, while a fountain code called Wirehair allows slow and fast speeds to both exist. Initially, Claude tried to port the OpenCV based finder to Vulkan. Branchy work is not great on a GPU, which struggles with warp divergence, so I scrapped that. However, AI inference is perfect for a GPU. As I had an RTX 4090, I asked it to make a generator, open pytorch, and train a custom, 50k parameter AI finder that uses the grayscale image and finds four corners. The CPU based OpenCV finder helped create training frames solutions for the GPU, which was given high levels of noise and perspective distortion in order to make it harder to detect than phones. I kept training it till the GPU version defeated the CPU in finding accuracy. After a few hours, had fully trained a custom 3-layer CNN that found the code easily in 1.5 ms on the GPU.

Next, I faced a massive issue: camera/frame desync. This was the bane of optical camera communication, with many resarch papers trying to defeat this with barcodes. The difference between my code and a QR: half of a FOCUS image can decode, meaning that if part of another frame was captures, some of it could decode. Additionally, android's native Camera2 API allows you to defeat this problem completely. it allows you to control the delays between frames. As a result, I decided to embed pilot signals in the image. Every four frames, it cycles through these four pilots.

0 0
1 0
0 1
1 1

This created a way to estimate how much of the last frame and future frame was on it. As it had two variables and two unknown frames, it was solvable; as a result, the camera knew how far off it was each frame. Then, it was able to adjust the time accordingly, keeping the rates stable at 60FPS. Voila! I had solved the hardest problem in OCC.

Speed: 0.7→1.4-1.6 MB/s

i returned an idea that I scrapped on web due to lag; 2:1 multiplexing. there is no reason why 2 square codes wouldn't store more; 1920x960 is far better than 1080x1080 in size. The change i did that made it viable; I did not try for a complex 2:1 mode, but simply multiplexed two frames side by side; two 960x960 squares. At this point the improvement of LIZARD went smoothly.

Speed: 1.4-1.6→2.1 MB/s

There were three final levers, but they were mundane. Firstly, I disabled the ISP edge enhancement and other cosmetic optimizations that were terrible for keeping signal. Then, i made the error correction levels higher for outer frequencies and lower for inner frequencies. I also added another LDPC rate. After that, I replaced the 96-module ring with the 256-module ring. That massively increased the area of signal. I used random old school monitors and they still got a similar rate. What phone did I use? S26 ultra. 1.5x zoom . 105 degree lens. 1080p, 60fps. it seems like the lens settings were far more influential than any monitor i used.I hope you liked my system! lmk what your thoughts are.

Speed: 2.1→4.1 MB/s

The courtyard plaque in Super Mario 64 is a single 32×32 RGBA16 texture (5 bits per channel, so 32 grey levels). Its two lines of text are 3-5 px tall. People have argued for ~30 years about what it says ("L is real 2401" is the well-known rumor), mostly by eyeballing or running it through upscalers.

I treated it as an inverse problem instead. A forward model of how a 1996 artist would have made it:

1. render a candidate text in a real font on a canvas (canvas size, font size, tracking, word spacing are free)
2. downsample to 32×32 (box / bilinear / bicubic tested)
3. Gaussian blur + gamma on the coverage
4. composite onto the stone background: texture = stone + L · coverage^γ

Then I search over fonts × process parameters × texts and score each by weighted SSE against the real texture.

Some details:

• Stone: estimated from the text-free pixels and inpainted under the letters with a Gaussian process. The pixel variance from the inpainting feeds into the weights.
• Calibration: the scoring was tested on synthetic plaques with known text, and every result is compared against a noise floor.
• Fonts: ~530 fonts from the era; best is Adobe Palatino Bold Italic (1990 Type 1). As a control, I ran 4,583 modern Google Fonts styles through the same three-stage search. The best modern font scores 905 vs 789, and every Palatino variant from the era beats all of them.
• Text: "Eternal Star / We hope so". For line 1, I scored every first word: a beam search over letter strings (4-10 letters, no dictionary) plus a 245k-word vocabulary, 1.24M strings in total. "Eternal" ranks #1 and the blind beam finds it on its own. Line 2 comes from a blind DP over 17.7k words.
• Rival reading: "L is real 2401" scores ~2,031 vs 789 on line 1, even with its own best process parameters.

Where I'd most like input:

• Identifiability: at this resolution, strings with the same letter shapes ("Stoi" vs "Star") score almost the same. The pixels fix the shapes and the language prior picks the word. Is there a principled way to report this, e.g. a posterior over strings instead of a ranking?
• Metric: weighted SSE with a GP-based variance. Would you use something else for 5-bit data with structured background noise?
• Stone: the background comes from a 90s stock photo (Sozaijiten SC003, brushed steel). Registering the text-free pixels against 1024 px web copies (masked NCC with plane removal, rotation/scale/mirror search) gives no unique lock: best 0.51 vs a mirrored control at 0.41. Is there a better way to register a tiny, heavily downsampled crop of a nearly self-similar texture?

Code, all result files and a 50-page report: https://github.com/supermochi64/sm64-plaque-decode

GIFs of the real texture vs. the model: https://github.com/supermochi64/sm64-plaque-decode#see-it-move

If its allowed by the forum rules, I can pay for the hours.

I need someone to build me a computer vision model that can
- Accurately detect edges of some metal components against a plain white background
- Develop a model to approximate dimensions.

Can explain further details in chat. I am mechanical engineer and while I have the vision and the idea, I lack the ML/AI skills so need some help here.

Jev (the TypeSafe model that returns probabilities instead of text) got image input last week, so I ran it on 48 labeled COCO photos, two model versions, two runs each. Cost was about 4 cents.

Yes/no questions were better than I expected: 98 to 99 percent right, and the confidence actually tracks accuracy.

The part that bit me is Box. It never says "not found". I asked for a cat in every photo that had no cat, and about a quarter of the boxes landed on whatever animal was there. Asking "is there a cat?" in the same request and ignoring the box when that was low fixed all 96 cases, and only dropped one real box.

Also, my favorite miss: a photo labeled "bus" where the biggest thing in frame is a traffic light with a lit horse and rider. Jev said horse at 0.96. Rewording to "living horse" got 0.03.

One warning if you use it: thresholds I tuned on 1.13 sent 3x more photos to review on 1.14. Pin the version.

Write-up with the raw answers you can click through: https://aiengineeringfromscratch.com/blog/typesafe-870m-can-jev-see