Selective binarization and re-encoding program for use with KoReader - Page 4

LegeApps · 08-12-2026, 01:33 AM

I am fine with a move but it has a lot to do with KoReader, because standard Kobo software doesn't support DjVu and has issues with JBIG2. So the program is explicitly designed to work with KoReader which supports those formats, and more, well.

And the commit you showed does not do the same thing as my program. it's in the name; it isolates the SMask. Many raster scans aren't masked at all so there is nothing to isolate, that's why they need to be rendered, or the images otherwise extracted. Rendering is faster. It also does not and cannot support layout detection to prevent images from being thresholded.

It is a good feature and I support it but it is not the same thing.

edit - i am implementing this in Lege now. it wasn't possible before i had control of the renderer. internet archive MRC type scans will retain their original text layers. removed some stuff i said about thresholding; this method doesn't threshold at all. it just uses the jbig2 smask layer, clean and easy for a subset of scanned book types (not all).

LegeApps · 08-12-2026, 03:32 AM

https://drive.google.com/file/d/1-Jy...ew?usp=sharing

That is a book I have been using for testing for the past year..it's an MRC encoded book from Internet Archive. 35 MB but it is JP2/JBIG2 mask. JP2 is an extremely heavy format. it takes 200ms for an optimized decoder on a core i7 to decode. On an e-ink reader, no chance of decoding in under a second. It takes 45 seconds to load the first page on my Kobo Clara BW using the latest version of KoReader.

https://drive.google.com/file/d/1gD7...ew?usp=sharing
This is a DjVu of the same book processed by my program. it's 17mb and only because i used high quality and high resolution output; it could be half as large with the right settings. it opens in under 200ms. page turns in under the same. it is optimized for the device. the device doesn't have to choke on a per page temporary adjustment, taking 30+ seconds each time.

Now do you all see the utility of the program? It is doing something on the desktop that an e-ink reader simply is not designed to do. E-ink readers are designed for text reading, and have to be hacked to handle complex image formats, and they still don't do them well. my program fills all those gaps, especially with the dithering option.

shuvashish76 · Today, 03:30 AM

Quote:

Originally Posted by LegeApps

my renderer that I made with LLMs (I heavily researched and planned everything though).

Would have been better to archive the repo and continue on proprietary releases for future versions.
If anyone interested the last known AGPL code is available at https://github.com/cowvet195/Lege For cases like this requested at https://archive.softwareheritage.org/save/ at-least for this source archive.

ThankYou for your opensource contributions.

Quote:

Originally Posted by LegeApps

Everything works fast and automatic, unlike ScanTailor et al. Opensource.

If possible edit the original post.

08-12-2026, 01:33 AM	#46
LegeApps Member Posts: 21 Karma: 10 Join Date: Jun 2026 Device: Kobo Clara BW	I am fine with a move but it has a lot to do with KoReader, because standard Kobo software doesn't support DjVu and has issues with JBIG2. So the program is explicitly designed to work with KoReader which supports those formats, and more, well. And the commit you showed does not do the same thing as my program. it's in the name; it isolates the SMask. Many raster scans aren't masked at all so there is nothing to isolate, that's why they need to be rendered, or the images otherwise extracted. Rendering is faster. It also does not and cannot support layout detection to prevent images from being thresholded. It is a good feature and I support it but it is not the same thing. edit - i am implementing this in Lege now. it wasn't possible before i had control of the renderer. internet archive MRC type scans will retain their original text layers. removed some stuff i said about thresholding; this method doesn't threshold at all. it just uses the jbig2 smask layer, clean and easy for a subset of scanned book types (not all). Last edited by LegeApps; 08-12-2026 at 01:52 AM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Selective connections to Web	rmanlee	Library Management	4	02-02-2014 03:04 AM
Selective paragraph indent	Leonatus	Writer2ePub	8	10-31-2013 04:22 PM
Selective preprocess_regexps	dasp	Recipes	3	12-06-2011 08:52 AM
Selective format conversion?	drmathprog	Library Management	2	04-19-2011 08:43 AM
Selective exclusion of Hyperlinks	SteffenH	Sony Reader	4	10-03-2007 06:51 AM

08-12-2026, 03:32 AM	#47
LegeApps Member Posts: 21 Karma: 10 Join Date: Jun 2026 Device: Kobo Clara BW	https://drive.google.com/file/d/1-Jy...ew?usp=sharing That is a book I have been using for testing for the past year..it's an MRC encoded book from Internet Archive. 35 MB but it is JP2/JBIG2 mask. JP2 is an extremely heavy format. it takes 200ms for an optimized decoder on a core i7 to decode. On an e-ink reader, no chance of decoding in under a second. It takes 45 seconds to load the first page on my Kobo Clara BW using the latest version of KoReader. https://drive.google.com/file/d/1gD7...ew?usp=sharing This is a DjVu of the same book processed by my program. it's 17mb and only because i used high quality and high resolution output; it could be half as large with the right settings. it opens in under 200ms. page turns in under the same. it is optimized for the device. the device doesn't have to choke on a per page temporary adjustment, taking 30+ seconds each time. Now do you all see the utility of the program? It is doing something on the desktop that an e-ink reader simply is not designed to do. E-ink readers are designed for text reading, and have to be hacked to handle complex image formats, and they still don't do them well. my program fills all those gaps, especially with the dithering option.