Oof 800 by 800 kills a lot of use cases
replyMight still be fine. The most recent crop of vLLMs proactively use whichever programs are available on the system (e.g. ImageMagick or PIL) to "zoom in" by cropping subimages if they can't quite make out the details.
replyDownsizing a higher res image to lower res means the zoom will be blurry.
replyThey’re not talking about zooming, hence the quotes.
replyThey process the original image file with Python on the local device. (And I've seen the web chats do this with their "computer use" features too.)
replyThe really wild one is even blind models will do this and they'll try to run stats on the pixels to figure out what it looks like... the even wilder thing is that it kind of works!
If the API accepts only 800 by 800, the aegument youre making is "fix it in the harness".
replyI don't think the n by n subgrid fixes this the way most harnesses do, as it'll fail to count things if you have more overlap and fail relatiomships if you have less
For most use cases you can fix that in the harness. Just give the model a tool to request a crop of specific coordinates of any image it has in its context. Call the tool "zoom" and it should be intuitive for the model
replyMaybe there are some use cases where you need high detail everywhere at once, but for OCR of small text and the like a zoom ability should be sufficient
For really dumb models I've also had success automatically cropping it into a grid of N images with the max size, then processing each cell individually, then once all been processed, do one final call with resized image + all other context previously generated per cell. Basically a workaround to the image dimension restrictions without loosing fidelity. Works well with even dumb 7B models.
replyCan't remember if I stole this idea from some existing public harness though, can't remember. If someone knows of public harnesses that do this already, please share them :)
Does this not loose context? Especially e.g. in fonts where the character pairs 0O 1I 1l Il may be difficult to differentiate?
replyThat's what the grid crop should handle. The detail is retained at that level, and then everything is logically stitched together again using the lower-res-full-image as reference. That's going to be 2x token usage at minimum though.
replyIt might also be due to its experimental status. Wouldn't surprise me if the GA version allows for larger input. Either that or the eventual pro version.
replywhat are these use cases?
replyAnything where there are symbols representing in space (e.g. schematics). Thats pretty broad
replyflash vs fine details. Pick one.
replyGemini "flash" models have an option for media resolution, including a high resolution option for screenshots.
replyAt what price point?
reply[flagged]
reply