<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Qwen3-VL Technical Report · HackerPapers discussions</title><link>https://hackerpaper.kaipfister.de/p/2511.21631/</link><description>Collected HN comments and submissions linking this paper.</description><language>en</language><lastBuildDate>Mon, 02 Nov 2026 11:16:22 GMT</lastBuildDate><atom:link href="https://hackerpaper.kaipfister.de/p/2511.21631/feed.xml" rel="self" type="application/rss+xml" /><item><title>Qwen3-VL Technical Report — mentioned by IanCal</title><link>https://news.ycombinator.com/item?id=46135047</link><guid isPermaLink="false">urn:hackerpapers:mention:2511.21631:46135047</guid><pubDate>Wed, 03 Dec 2025 14:44:35 GMT</pubDate><description>&lt;p&gt;That rather depends on exactly how this is done, although it&amp;#x27;s a useful upper bound for many tasks either way. You could say the same for images and yet due to the way some work they straight up cannot see in certain ways. This could describe adding a frame of nonsense into an existing video. It also could describe finding a semantically useful thing in an actual video, where the exact location is randomised by looking at different time crops of the video. For example, finding a book on a desk in a video that&amp;#x27;s only there in a panning shot, and you then see if it can find it in a 10s cut, 20s…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/2511.21631/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.CV</category></item></channel></rss>
