<div dir="ltr"><div dir="ltr"><span style="background-color:transparent">On Thu, Jul 23, 2026 at 5:31 PM Alexander Pevzner <<a href="mailto:pzz@apevzner.com">pzz@apevzner.com</a>> wrote:</span></div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 7/23/26 2:20 AM, Benjamin Gordon wrote:<br>
> If there's the possibility of re-opening the standard, I for one would <br>
> like to consider a more general handling of frame formats.  All the <br>
> scanners that support eSCL these days can return JPEG directly, and some <br>
> of them can even return a whole PDF at once.  It would be great for the <br>
> frontend to be able to negotiate some sort of passthrough mode instead <br>
> of decoding these and then re-encoding in the frontend.<br>
I would prefer to have an option that allows to negotiate returned <br>
format in terms of MIME types (with some MIME type reserved to the <br>
standard SANE frame format).<br></blockquote><div><br></div><div>Agreed, and that's also what I had in mind.  For example, if we reserved "-sane-*" for this type of negotiation (which wouldn't conflict with existing options because a leading dash is currently illegal), then there could be a -sane-image-formats-supported option containing a list of MIME types that the backend could return.  The default would have to be some entry that corresponded to the existing frame formats.  Then any frontend that didn't know about this option would get the same data it's expecting now and any backend that didn't offer this option would implicitly tell the frontend to expect the traditional formats.  There's definitely details to be worked out, but I think this type of scheme would allow a lot of extensions without an ABI break and without forcing either side to upgrade.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Please notice, sane_get_parameters cannot be implemented (or should just <br>
return requested, not the actual image parameters) if this option is <br>
active, because sane_get_parameters may require at least partial <br>
decoding of the image, returned by the scanner.<br></blockquote><div><br></div><div>Agreed again, but this sort of behavior change would be OK as long as both sides have opted in through that initial negotiation.</div><div><br></div><div>Thanks,</div><div>Benjamin</div></div></div>