On Wed, 23 Aug 2006, Michael Hennebry wrote: > On Tue, 22 Aug 2006, m. allan noah wrote: > >> On Tue, 22 Aug 2006, Ren? Rebe wrote: >> >>> Well that stinks as you lose a lot of detail with the lossy jpeg >>> decompression. >> >> even worse, if you are running the thing over the net backend, you convert >> to huge bitmap just before you transfer it over the network! >> >>> >>> Maybe let's add the JPEG frame type rather soon (even in SANE 1) and let's >>> add an IR (infra red) frame specification on the way as good film scanner >>> deliver for dust and the-like removal. > > Perhaps with carefully crafted code, > decompression compression could be made an identity operation. > If not, perhaps it could be made idempotent.
elaborate > >> SANE2 could require that the frontend support jpeg, and that could become >> the default for the 'format' option. > > Not having a default would better than making it a lossy compression method. > > If one is going to do compression, perhaps it would be good > to have a non-loosy method as one of the options. agreed. zlib ok? allan -- "so don't tell us it can't be done, putting down what you don't know. money isn't our god, integrity will free our souls" - Max Cavalera From [email protected] Wed Aug 23 19:20:50 2006 From: [email protected] (Michael Hennebry) Date: Wed Aug 23 19:20:57 2006 Subject: [sane-devel] Image Compression doesn't support in SANE protocal In-Reply-To: <[email protected]> Message-ID: <[email protected]> On Wed, 23 Aug 2006, m. allan noah wrote: > On Wed, 23 Aug 2006, Michael Hennebry wrote: > > > On Tue, 22 Aug 2006, m. allan noah wrote: > > > >> On Tue, 22 Aug 2006, Ren? Rebe wrote: > >> > >>> Well that stinks as you lose a lot of detail with the lossy jpeg > >>> decompression. > >> > >> even worse, if you are running the thing over the net backend, you convert > >> to huge bitmap just before you transfer it over the network! > >> > >>> > >>> Maybe let's add the JPEG frame type rather soon (even in SANE 1) and let's > >>> add an IR (infra red) frame specification on the way as good film scanner > >>> deliver for dust and the-like removal. > > > > Perhaps with carefully crafted code, > > decompression compression could be made an identity operation. i.e. compression(decompression(x))=x > > If not, perhaps it could be made idempotent. i.e compression(decompression(compression(decompression(x))))= compression(decompression(x)) > > elaborate The idea is to put a useful bound on the amount of damage done by repeated decompressions and compressions. The jpeg compression algorithms are not invertable. For every jpeg compression algorithm, there are distinct X and Y such that compression(X)=compression(Y). The same might be true for decompression, but I'm not sure. > > If one is going to do compression, perhaps it would be good > > to have a non-loosy method as one of the options. > > agreed. zlib ok? ok. -- Mike [email protected] "it stands to reason that they weren't always called the ancients." -- Daniel Jackson
