Re: [sane-devel] Pixma future
Hello, only a side note FYI: On 2020-11-26 12:42, Olaf Meeuwissen wrote: I remember horror stories with stacked CUPS filters rotating pages or doing n-ups repeatedly. In a bad case you could end up with a total rotation being a multiple of 360 degrees, for a net no rotation, and compounding 2-ups so you'd get 16 pages to a sheet :-o Such scaring stories are nicely described by me for your pleasure, see https://en.opensuse.org/SDB:Landscape_Printing "There is no such thing as 'landscape printing'" and https://en.opensuse.org/SDB:Printing_Copies "There is no such thing as 'just printing copies'" SCNR ;-) Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 - 90409 Nuernberg - Germany (HRB 36809, AG Nuernberg) GF: Felix Imendoerffer
Re: [sane-devel] Pixma future
Hi Allan, m. allan noah writes: > On Wed, Nov 25, 2020 at 2:01 AM Alexander Pevzner wrote: >> >> Obviously, this is better not to implement emulation of missed (in >> hardware) features in the drivers, to avoid code duplication and having >> an assortment of independent, often incompatible implementations of the >> similar features. >> > > Nonsense. You can have every driver implement a consistent level of > features, and only have a single implementation of emulated functions. > You just need a library At which point the driver does *not* implement it anymore. It just outsources to an already existing implementation ;-P > like sanei_magic, which is already used by a number of existing > backends to provide software deskew and autocrop functions. It would > be pretty easy to do something similar for binarization. The problem that I perceive is that there is no "well-known" agreed upon library for these kind of image data manipulations. It just seems that every backend does its own thing. When I was working on utsushi[1] at the office, I pretty much outsourced all of the image processing to one of ImageMagick or GraphicsMagick. Your sanei_magic rolls its own. [1]: https://gitlab.com/utsushi/utsushi An additional issue is whether the backend or the frontend should handle the image processing. You most definitely do not want to do it twice. I remember horror stories with stacked CUPS filters rotating pages or doing n-ups repeatedly. In a bad case you could end up with a total rotation being a multiple of 360 degrees, for a net no rotation, and compounding 2-ups so you'd get 16 pages to a sheet :-o Whatever component gets to deal with part of the processing should be able to communicate what parts have been taken care of. If you favour frontends taking care of this, it'd be natural to call it middleware. For backends, calling it a library may make more sense but there is no functional difference, really. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join
Re: [sane-devel] Pixma future
On Wed, Nov 25, 2020 at 2:01 AM Alexander Pevzner wrote: > > Obviously, this is better not to implement emulation of missed (in > hardware) features in the drivers, to avoid code duplication and having > an assortment of independent, often incompatible implementations of the > similar features. > Nonsense. You can have every driver implement a consistent level of features, and only have a single implementation of emulated functions. You just need a library like sanei_magic, which is already used by a number of existing backends to provide software deskew and autocrop functions. It would be pretty easy to do something similar for binarization. allan -- "well, I stand up next to a mountain- and I chop it down with the edge of my hand"
Re: [sane-devel] Pixma future
Hi Andrea, Andrea Croci writes: > [...] I have always wondered why the Windows programs make a 180 kB > pdf of the same page for which xsane made a 7MB file (don't know if it > has changed in the last few years since I'm scanning from command > line). That's probably because those Windows programs embed the images as JPEGs and xsane embeds PNMs. Needless to say, JPEGs suck for text documents. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join
Re: [sane-devel] Pixma future
Hi Andrea, On 11/25/20 12:59 AM, Andrea Croci wrote: 1) I do agree that the backend should merely expose the native capabilities of the hardware. However if you are having one backend for a lot of similar, but not identical, machines, then it may be that some of these machines do offer lineart scanning natively and others don't. I think the backend that covers all these machines should offer the superset of the hardware capabilities, instead of the subset, which would reduce the whole machine family to the smallest set of features offered. I think, the problem comes from the fact, that SANE applications (frontends) directly speaks with SANE hardware drivers (backends) without any middleware layer between them. Obviously, this is better not to implement emulation of missed (in hardware) features in the drivers, to avoid code duplication and having an assortment of independent, often incompatible implementations of the similar features. From another hand, implementing these features in applications is also not a very good idea. xsane, which implements some image enhancement features, like brightness/contrast/gamma correction, is a nice app, but there are other popular scanning apps around, and duplication this code around all of them is not wise, as it is not wise to duplicate this code around hardware drivers. User, of course, would prefer that these functions will be available on all hardware and with any drivers. I think, the best place to implement missed features is the sane-dll. It is (almost always) present between apps and drivers and can do this work. It also opens a way to seamlessly move from SANE 1.0 to SANE 2.0, because sane-dll may provide the required translation layer. -- Wishes, Alexander Pevzner (p...@apevzner.com)
Re: [sane-devel] Pixma future
On 24.11.20 21:00, Ralph Little wrote: One way to deal with that would be for me to add Lineart as a filter to xsane as a postprocess option. Command line users could make the lineart conversion another phase of their workflow, using a tool like imagemagick. I think that a lot of people view this kind of thing as something that the frontend should provide, with the backend merely exposing the native capabilities of the hardware. We have a number of backends doing emulation of functions that the hardware cannot do and they all seem to do it in their own special way, increasing the code size measurably. Which reminds me, I really need to get back to xsane. I'm a terrible one for distraction :( Cheers, Ralph May I just quickly chirp in? I'm not involved in the development of this, but I would like to express my opinion from the point of view of a user, for what it's worth. 1) I do agree that the backend should merely expose the native capabilities of the hardware. However if you are having one backend for a lot of similar, but not identical, machines, then it may be that some of these machines do offer lineart scanning natively and others don't. I think the backend that covers all these machines should offer the superset of the hardware capabilities, instead of the subset, which would reduce the whole machine family to the smallest set of features offered. 2) I may be the only one, but since I got tired of chasing the problem that's keeping xsane from working in my Ubuntu 18.04 computer (it works great in the 20.04), I am forced to scan from command line. I do use another tool like imagemagick to postprocess my scans (convert the .tiff to .pdf) and, when I'm scanning from ADF, even use tiffcp to convert the single tiffs into a multipage tiff before using convert to do the pdf. I have to admit that I don't like it a lot. If on the one hand I agree that the backend should do just the backend, I on the other hand would like to have a tool that does the whole thing for me without having to use three programs. I know this tool should be xsane, but then it should also compress the pdfs better (back when it was working it generated huge pdfs). I have always wondered why the Windows programs make a 180 kB pdf of the same page for which xsane made a 7MB file (don't know if it has changed in the last few years since I'm scanning from command line). Sorry, it was not so quick after all. Cheers, Andrea
Re: [sane-devel] Pixma future
Hi, On Tue, Nov 24, 2020 at 11:13 AM Povilas Kanapickas wrote: > Hi Ralph, > > On 11/23/20 12:33 AM, Ralph Little wrote: > > > > > 1) Are you intending a genesys-style rewrite, perhaps in C++? > > Yes. I plan to extract reusable parts of the genesys backend and use > that from any other backends. > > Even without that, I've found that at least in the case of genesys > backend, a rewrite to C++ fixed a large number of small bugs that > require strong discipline to avoid in C. The largest category were bugs > in error handling and bugs in memory handling. This is I guess not > surprising as both of these are done manually in C. > > I plan to start the rewrite next month, so it would be great if any > fixes could be submitted until then as the codebase may change > substantially. > > OK, I will assemble the actual fixes and drop them into a new branch. Then we can review and merge them. > > 2) What do you think about dropping emulated lineart from the backend > > altogether? That would certainly simplify the backend considerably. > > The same has been done in the genesys backend. I think we need a wrapper > backend that would generate lineart automatically if the downstream > backend does not support that. > > Right now I'm thinking about how this could be implemented. > One way to deal with that would be for me to add Lineart as a filter to xsane as a postprocess option. Command line users could make the lineart conversion another phase of their workflow, using a tool like imagemagick. I think that a lot of people view this kind of thing as something that the frontend should provide, with the backend merely exposing the native capabilities of the hardware. We have a number of backends doing emulation of functions that the hardware cannot do and they all seem to do it in their own special way, increasing the code size measurably. Which reminds me, I really need to get back to xsane. I'm a terrible one for distraction :( Cheers, Ralph
Re: [sane-devel] Pixma future
Hi Povilas, On 11/24/20 10:13 PM, Povilas Kanapickas wrote: The same has been done in the genesys backend. I think we need a wrapper backend that would generate lineart automatically if the downstream backend does not support that. Right now I'm thinking about how this could be implemented. The natural place for it is in the sane-dll backend. -- Wishes, Alexander Pevzner (p...@apevzner.com)
Re: [sane-devel] Pixma future
Hi Ralph, On 11/23/20 12:33 AM, Ralph Little wrote: > Hi Povilas (and the group), > I have been working some changes for pixma on a branch for issue #264, > support for MX492. > It has been quite a long meandering journey and, although I have fixed a > few actual backend bugs, I'm not really happy with the direction that I > have taken and would like to restart with a better idea in mind of where > it is going to go. > > To be honest, I have learned a lot along the way and I would have > preferred to be able to reduce the changes down to much smaller pieces. > > Much of that effort has been sorting out the distinction between > frontend and backend line_size computed values which lay at the source > of much of what doesn't work with the lineart support. > > So, I propose to terminate that branch and start afresh. I could open > new branches and add the definite, smaller real bug fixes that are > practical to review and individually merge. In particular, the > revelations related to the imageClass ADF. > > It occurs to me that you probably have your own plans as to how you > would like to develop the pixma backend and I would be interested in > your views before I start anything major. > > In particular: > > 1) Are you intending a genesys-style rewrite, perhaps in C++? Yes. I plan to extract reusable parts of the genesys backend and use that from any other backends. Even without that, I've found that at least in the case of genesys backend, a rewrite to C++ fixed a large number of small bugs that require strong discipline to avoid in C. The largest category were bugs in error handling and bugs in memory handling. This is I guess not surprising as both of these are done manually in C. I plan to start the rewrite next month, so it would be great if any fixes could be submitted until then as the codebase may change substantially. > 2) What do you think about dropping emulated lineart from the backend > altogether? That would certainly simplify the backend considerably. The same has been done in the genesys backend. I think we need a wrapper backend that would generate lineart automatically if the downstream backend does not support that. Right now I'm thinking about how this could be implemented. Cheers, Povilas
[sane-devel] Pixma future
Hi Povilas (and the group), I have been working some changes for pixma on a branch for issue #264, support for MX492. It has been quite a long meandering journey and, although I have fixed a few actual backend bugs, I'm not really happy with the direction that I have taken and would like to restart with a better idea in mind of where it is going to go. To be honest, I have learned a lot along the way and I would have preferred to be able to reduce the changes down to much smaller pieces. Much of that effort has been sorting out the distinction between frontend and backend line_size computed values which lay at the source of much of what doesn't work with the lineart support. So, I propose to terminate that branch and start afresh. I could open new branches and add the definite, smaller real bug fixes that are practical to review and individually merge. In particular, the revelations related to the imageClass ADF. It occurs to me that you probably have your own plans as to how you would like to develop the pixma backend and I would be interested in your views before I start anything major. In particular: 1) Are you intending a genesys-style rewrite, perhaps in C++? 2) What do you think about dropping emulated lineart from the backend altogether? That would certainly simplify the backend considerably. Cheers, Ralph
