0.9m06 Pt 1 - Tables 2; Shared Graphics; FGbz 1

[maple7-7-7]

Hi Alex,
I have started this new discussion for the newest version of minidjvu-mod.
I have tested your new version on 20 5100x6600 Table pages at 600 dpi and with a 20-page dictionary. any2djvu vs your new minidjvu-mod0.9m6
Results are impressive! The two djvus look the same, but . . .
Any2djvu = 77.2 KB
minidjvu-mod0.9m6 = 48.6 KB (!)
Yours is about 63% the size of the any2djvu version!
This is the kind of compression we had hoped for early on in the project.
Actually even better than that!
Here is a jpg with the file sizes summary:
Left side any2djvu Right side Yours!

Here are the two DjVus as a zip file.
TABLES_any2djvu_vs_mini_0.9m6_djvus.zip

Please explain how you got such an improvement. I know you were predicting possibly better compression. But wow, you really nailed it this time!

Some of your pages are less than half the file size of corresponding any2djvu pages, and the any2djvu's are supposed to be at or close to commercial quality.

Thanks again,
Stephen

[trufanov-nok]

Hi,
It's not surprising as using djvudict I had taken a look on any2djvu resulting dictionary and realized that it doesn't try to encode pieces of the graphic into the shared dictionary, even if they are exactly the same.

Every encoder detects pieces of black on b/w page and decides if it's a letter, just dirt or graphic - basing on their size. Too small objects are removed as a trash if --clean option is enabled. Letters (medium size) are encoded using dictionaries. But graphics (object too big and pieces connected to them) must be encoded losslessly, bcs this can be a part of the illustration. And if you encode it non-losslessly - you'll damage it. Tables and the corners like on your pages are treated as graphic bcs they are big, as encoder don't understand what is drown on the page.

The problem is that in a real scanned images you'll almost never find two pieces of graphic that are pixel-to-pixel equal. And encoders do not bother themselves to detect such possible options of graphic compression. They rely on refinement encoding which applied page by page, not involving shared dictionary (which also may be a space for further compression improvement). But in case of generated images like yours, the pieces of graphics are exactly same across all the pages (while not the same in a scope of a single page, as encoder can't rotate black corners etc. I guess encoding with rotations even not a part of djvu specification). And for such pages it's feasible to try to encode graphics into the shared dictionary, keeping in mind it have to be losslessly classified nevertheless lossy compression is selected by the user.

In other words, minidjvu-mod is now tweaked to achieve better compression for a very rare case: exactly the same graphic objects repeated on a several pages. Which is very unlikely happens for scans, but may be found on generated pages.
That means any further testing results of minidjvu-mod on pages with such a corners will be incorrect, as it has a handicap for such type of pages in comparison to any2djvu.

[maple7-7-7]

Thanks, Alex!
A very interesting, detailed discussion. The Table on pg1 has 19 identical thin horizontal lines, 3 identical horizontal thick lines, 2 identical vertical thin lines, and 3 identical vertical thick lines. Are they all shared on the page or encoded separately? I use Table Templates, such that Table 1 as a framework is used regularly in my research, and so is the more complex Table 2 on pg 2. I wonder what the possibilities are for compression for those. I basically have a maximum same font size for the capital letters in each cell, when each cell is part of any table with 1 to 20 rows. If the number of rows goes beyond 20, I reduce the font size in a correspondingly fitting way. It would be interesting to have a Tables-only encoder, but I know that is more work.
I manually added FGbz color zones to pg 1 and ended up with 26 new zones for the 26 lines. When I used djvuextract and then djvumake to colorize Table 1, I got an FGbz chunk size of 139 bytes, and the information window indicated 27 colors, even though all of the 26 were the same: #blue.
I tried adding the FGbz chunk from making pg1 in djvudigital and in pdf2djvu, but these small chunks (23 bytes and 21 bytes, respectively) did not work rightly. The djvudigital FGbz colored about half of the colorable parts, and the pdf2djvu FGbz chunk did not colorize anything, even though it is listed in the page information window. I tried to think up some other parallel workaround, but have not been able to.
Thanks again.

[rmast]

and the information window indicated 27 colors, even though all of the 26 were the same: #blue.

I saw the same behavior with DjVuSolo 3.1. About 20 colors for a white page that only contains white, grey and blue text.

I had a discussion with Ma Jian of DjVuToy about reducing these colors. He advised Xiaolin Wu or Neuquant as palette algorithm.

I finally succeeded to process the original source color document with first kornelski/mediancut-posterizer and then pngquant, branch wucut to result in the right 8 visually distinguishable colors.

[maple7-7-7]

Thanks, rmast. I know nothing about the programs you discussed or how you processed the document, but I will check out what these programs can do as a possible workaround.
Thanks again.

[trufanov-nok]

The Table on pg1 has 19 identical thin horizontal lines, 3 identical horizontal thick lines, 2 identical vertical thin lines, and 3 identical vertical thick lines. Are they all shared on the page or encoded separately?

Unfortunately, no. Technically the object detection is performed in a regions max. 500x500. So the table is cut into such regions and then connected components is searched in them. Cutting don't take into consideration the objects structure. The pieces are encoded separately. I'm pretty sure that any2djvu has the same object detection mechanism, bcs their dictionary doesn't contain pieces bigger than 500x500. I don't know why this is done. Perhaps if I join lines into one piece I may end up with a box or corner instead of a long line and this will take more disk space to encode bcs it's area is bigger. Don't know. It's probably related to a character encoding limitations of Z-coder used in Djvu for that purpose.

Btw, you may use djvu4shapes project to visually investigate how page is encoded:

https://github.com/jsbien/djview4shapes

It's a DjView4 fork made by a polish linguists. When you open a djvu document in it, you may click on any character in document. It' will be highlighted by yellow. The right panel displays the dictionaries (I guess, Djbz, then Sjbz and all other characters). The character you highlight will be selected in this list. Also characters that are refinement-encoded based on selected character will be highlighted too. The panel on the left that usually contains the document pages and is used for navigation is turned to a filter, that displays only pages that contain same character of the dictionary. PgUp/PgDown keys are used for navigation.

There is some letter usage statistics and context menu to export bitmaps from dictionary.

That's a scientific project made for research and thus it's not user friendly and sometimes is buggy.

[trufanov-nok]

I manually added FGbz color zones to pg 1 and ended up with 26 new zones for the 26 lines. When I used djvuextract and then djvumake to colorize Table 1, I got an FGbz chunk size of 139 bytes, and the information window indicated 27 colors, even though all of the 26 were the same: #blue.

That's right. I guess it displays number of color zones, not different colors. And 27th is a default zone with color #black which was added automatically as you created FGbz chunk. There is a way to change default color of all characters in the page with FGbz.

I tried adding the FGbz chunk from making pg1 in djvudigital and in pdf2djvu, but these small chunks (23 bytes and 21 bytes, respectively) did not work rightly. The djvudigital FGbz colored about half of the colorable parts, and the pdf2djvu FGbz chunk did not colorize anything, even though it is listed in the page information window. I tried to think up some other parallel workaround, but have not been able to.

How exactly you're moving FGbz chunks? Could you provide 2 djvu pages: colored and not. And instruction on how to move FGbz chunk from one to another which end up with a wrong result?

[maple7-7-7]

Thanks, Alex.
I recently did some comparisons with 10pg Emerson text + corners, and your newest version was 24.7 KB vs Solo 28.0 KB. I need to try as you say without corners, just text. Great to hear that the newest version is improved overall and is not branching, and is especially improved for Tables.
Sorry, I keep having trouble finding newest binaries. Link?
Thanks again,
Stephen

[trufanov-nok]

I've checked the chunk binaries and then a DjVu specification. It seems I was wrong - although djvumake allows to set color zones via their coordinates and colors, they are not stored like that. They are stored as a RGB (BGR indeed) colortable and a list of character indexes with their color no in this color table. That means that FGbz chunk can't be moved across the documents as character indexes there will be different. The indexes of a shared dictionary shapes might be the same across the pages encoded with a same encoder, if shared dictionary symbols are just copied and not used as a base for refinement encoding,
Anyway it seems it's too risky to copy chunks instead of just passing "FGbz=#black...." string parameter to djvumake, which will find proper character indexes inside coordinates.
2. Then it's not clear what shown you 27 colors info:

and the information window indicated 27 colors, even though all of the 26 were the same: #blue.

On linux djvudump and djview4 display proper colortable of 2 colors (BGR 00,00,00 and BGR FF,00,00):

$ djvudump TABLE_DJVUDIGITAL_pg1_600_color_no_dict.djvu
  FORM:DJVM [3836] 
    DIRM [27]         Document directory (bundled, 1 files 1 pages)
    NAVM [63] 
    FORM:DJVU [3716] {p0001.djvu} [P1]
      INFO [10]         DjVu 5100x6600, v24, 600 dpi, gamma=2.2
      Sjbz [3359]       JB2 bilevel data
      FGbz [21]         JB2 colors data, v0, 2 colors
      BG44 [288]        IW4 data #1, 97 slices, v1.2 (b&w), 425x550

[trufanov-nok]

Sorry, I keep having trouble finding newest binaries. Link?

https://github.com/trufanov-nok/minidjvu-mod-gui/releases/tag/0.2.3

I just reuploaded zips bundled with 0.9m06 instead of 0.9m05

Win64: https://github.com/trufanov-nok/minidjvu-mod-gui/releases/download/0.2.3/Win64-minidjvu-mod-gui_0.2.3.zip
Win32: https://github.com/trufanov-nok/minidjvu-mod-gui/releases/download/0.2.3/Win32-minidjvu-mod-gui_0.2.3.zip

[maple7-7-7]

Thanks for the binaries and the link.
The GUI is superconvenient when working with multiple pages.
I was wondering if it would be difficult to add a multi-select feature to the files list in the GUI window. One time I wanted to delete 10 of the 20 files but had to do so individually. Not a big deal, but a maybe.
Yes the FGbz chunks were another mystery to me.
One good thing is that even though the manually added FGbz chunks are about 100 bytes bigger for a fairly simple Table like Table 1, one can use a copy of the manually entered data for all other Table 1 Template-style Tables.
Incidentally, Russia is easily the DjVu capital of the world.
Here in Canada, I talk to people and almost no one has heard of DjVu.
The idea that PDF has any sort of competitor, especially one that often as you say offers "incomparable" improvement would be news to most. I think one problem is many PDFs are low-level and are only a few pages, so we don't get to see DjVu shine when the going gets tough with heavy JPEGs and lots of pages. I liked how DjVu could show thin Table lines accurately on the screen, whereas PDF versions of the same Tables gave inconsistent display thicknesses. That is one of the big reasons I chose DjVu over PDF in the first place.The annotation options in DjVu are amazing, but get ready to spend lots of time setting them up!
I see PDF as no longer a document format, not when you can put videos into one.
I see DjVu as the ultimate document format for what we traditionally call documents.
The format ePUB, with its reflow, takes away the artistry that can be set up with DjVu, which, being bitmaps, is largely a written-in-stone format. Great for archiving. Zipping a DjVu adds the password option.
With so many new PDF editors being more readily available, this also introduces new levels of PDF vulnerability. There is something to be said for type that is not movable. And the fact that DjVu is in bitmap format is great as it takes away the problem of embedded fonts or the use of copyrighted fonts, because we are looking at snapshots of fonts, or the effects of using such fonts, and not using the fonts themselves.
And who nowadays knows that The Rolling Stone Magazine, The New Yorker, and Playboy were all set on DVDs in DjVu format, as DjVu was the only format that could generate a manageable number of DVDs? From an older article on The Rolling Stone Magazine:
"Archive software firm Bondi Digital Publishing is scanning over 115,000 pages from more than 1,000 issues, using a proprietary platform previously used for the New Yorker and currently being deployed for Playboy. Bondi will publish the DVD under an exclusive licensing arrangement with Wenner Media, the closely held parent of Rolling Stone."

Anyway, thanks for all your details once again, Alex.
Stephen

[maple7-7-7]

Hi again, Alex.
I was just re-reading some of your posts here and you were wondering about 27 colors vs 2 colors (djvudump). In case of any confusion, the 27 colors refer to the colorized version of a bitonal pg1 minidjvu-mod 0.9m06 DjVu after manually adding 26 blue color zones. The 2 colors refer to making the same-looking page, using a color PDF converted in DjVuDigital to DjVu. When I extracted the FGbz chunk from this DjVu, and added it to the minidjvu-mod Sjbz + dictionary, the new "hybrid" DjVu still indicated 2 colors for the FGbz chunk, but the colorization was incomplete. I think maybe you have figured this all out at this point.

[rmast]

Hi Steven, When I re-read the thread I saw there was a technical explanation for having really the same color multiple times. The hints I gave were for visually the same color, but slightly different in a scanned source picture, or even in the resulting DjVu when processed with DjVu Solo 3.1, which might contain a 20 color FGBZ. As my focus is on getting the same in a PDF the cost of translating a FGBZ with that many colors can take 2k on a page, so I thought of reducing it to the amount of colors that are really making the difference. Outlook voor Android downloaden<https://aka.ms/ghei36>

…

________________________________ From: maple7-7-7 ***@***.***> Sent: Wednesday, October 13, 2021 1:33:44 AM To: trufanov-nok/minidjvu-mod ***@***.***> Cc: rmast ***@***.***>; Comment ***@***.***> Subject: Re: [trufanov-nok/minidjvu-mod] Version 0.9m6 (Discussion #15) Thanks, rmast. I know nothing about the programs you discussed or how you processed the document, but I will check out what these programs can do as a possible workaround. Thanks again. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#15 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAZPZ5QIW5573SCNGM373M3UGTAVRANCNFSM5FWXD75A>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[maple7-7-7]

Thanks rmast. (and this is for Alex, too)
Yes, with regard to efficiency, your comment about showing the most needed colors is something like the idea of how many K's of pixels will be needed for a video if the human eye cannot see a difference after 6-8 K.
I did a few more attempted workarounds for the FGbz chunk, including encoding using cpaldjvu and extracting the FGbz, and in all cases the result is a "hybrid" DjVu with the FGbz chunk inside, but always still in black and white. I tried extracting the FGbz from an empty Table version of Table 1, and putting the chunk in the character-filled Table, and again still black and white.
So, as Alex later indicated, things with FGbz are not as simple as adding colored sections to any page area, the way we might add an OCR word to a given rectanglar section on a DjVu page. So even though we lose out a bit with the increased FGbz file size and the typed manual adding of color coordinates, we still get the great benefit of a large reduction in overall file size with this tweaked version of minidjvu-mod, with 30-40% better compression for computer-generated Tables than with any2djvu or DjVuSolo3.1.
And there is still room for further improvements. Besides, for most text documents, Tables are likely to be in black and white anyway. I am OK with making efforts to manually colorize multiple lines, because, as stated before, I tend to use Table Templates, and once one round of colorizing manually is done for each Template, then we have created some quickly insertable FGbz chunk data for each Table using that Template.
I also have decided that 5100x6600 at 600dpi is to be the standard setup for Tables, as opposed to a slightly lower resolution, as Alex's tweaking has made the page sizes for these Tables quite manageable. One nice thing about DjVu as a bundle is how you can have different resolutions for adjacent pages, if for instance a Table has many more rows than a standard Table, and requires higher resolution to keep smaller characters looking good.
If one maintains the ratio of pixels/dpi ([2550x]3300 pixels)/(300dpi) = ([5100x]6600 pixels)/(600dpi) etc., then the viewer can show all of these pages consecutively without shrinking or enlarging, as if the pages are using the same parameters. DjVu has challenges, but I like how it also offers pleasant surprises. With a little work and a lot of knowhow, DjVu is remarkably customizable, as shown so clearly with Alex's tweaks here in version 0.9m06.
Thanks again.

[maple7-7-7]

Discussion Titles Adjusted
I have renamed the 3 discussion titles to align better and to briefly describe the themes of each discussion.

[trufanov-nok]

Regarding 27 colors - I've checked djvumake tool sources from DjVuLibre package. They are pretty straightforward - djvumake just writes down all color zones from the command line into colortable without checking if such color is already in the color table. Also then it checks if there is no color without zone in argument "FGbz=" string, and if so - adds black color to the end of the colortable as default zone color.

I've made a patch for DjVuLibre's /tools/djvumake.cpp that make it put only unique colors to the color table and assign right indexes to the zone's content. It also make djvumake to ignore colorzones with same color as the default one. The patch is attached.
djvumake_patch.zip

Linux users might git apply it to the DjVuLibre's sources, rebuild them and test. I have no time to build it for Windows yet.
I'll suggest Leon Bottou to merge this change into official DjVuLibre.

[maple7-7-7]

This is great, Alex, thank you!
But as usual I am clueless as to how to work with a patch in Linux.
I am using Lubuntu 18.10 - 32 bit.
Could you please tell me how to add this patch, but only if it does not take up your time.
If it is going to take a while for you, I can definitely wait until a new build is done sometime.
The good news is that you have something for the FGbz problem.
I do tend to use Win10 for most of my tests, but, as you know, am happy testing in Linux, too.
Thanks again.

[trufanov-nok]

Great, try this one:

0. Get build dependencies:

sudo apt-get install libjpeg-dev libtiff-dev imagemagick

1. Try to build the library as is

cd /tmp
git clone https://github.com/barak/djvulibre.git
cd djvulibre
autoreconf --install
./configure --prefix /usr
make 

In case of configure show errors (missing library dependencies?) - show me the output.
Same in case make fails.

2. Try to build it again with patch (being in /tmp/djvulibre/):

wget https://sourceforge.net/p/djvu/discussion/103286/thread/f41cfdc5ae/b263/attachment/djvumake.diff
git appy djvumake.diff
make

3. Install patched version over the system one (req. admin privileges):

sudo make install

[rmast]

git apply diff Outlook voor Android downloaden<https://aka.ms/ghei36>

…

________________________________ From: Alexander Trufanov ***@***.***> Sent: Thursday, October 14, 2021 8:03:02 PM To: trufanov-nok/minidjvu-mod ***@***.***> Cc: rmast ***@***.***>; Comment ***@***.***> Subject: Re: [trufanov-nok/minidjvu-mod] v0.9m06 - Tables; Shared Graphics (Discussion #15) Great, try this one: 1. Get build dependencies: sudo apt install libjpeg-dev libtiff-dev imagemagick 1. Try to build the library as is cd /tmp git clone https://github.com/barak/djvulibre.git cd djvulibre autoreconf --install ./configure --prefix /usr make In case of configure show errors (missing library dependencies?) - show me the output. Same in case make fails. 1. Try to build it again with patch (being in /tmp/djvulibre/): wget https://sourceforge.net/p/djvu/discussion/103286/thread/f41cfdc5ae/b263/attachment/djvumake.diff git appy djvumake.diff make 1. Install patched version over the system one (req. admin privileges): sudo make install — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#15 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAZPZ5TBQ6AGA6AQKNQ77N3UG4LNNANCNFSM5FWXD75A>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[maple7-7-7]

PATCH TEST RESULTS - FGBZ
Patch successfully installed in Lubuntu 18.10. Thank you Alex and rmast.
Results: Here is a screenshot of the newly colorized TABLE 1 DjVu and the page information window.

So for the FGbz chunk we now have 25 bytes instead of 139 bytes!
And we now have 2 colors instead of 27 colors!
Great work!
Here is a zip file with the various "participants."
DjVu 1 uses an external dictionary,
DjVu 2 uses an internal dictionary.
Also included are the Sjbz chunk and the script used to make the 26 FGbz blue color zones and the two DjVus.

FGBZ PATCH TEST RESULTS.zip

Thanks again!

[maple7-7-7]

Hi Alex,
I ran some more tests with Tables, this time encoding 200 pages of PBMs.
Using a 20pg dictionary, with options -m and Use Prototypes (but not including -A) enabled, and Aggression at 100, your mini0.9m06 gave a file size of 364 KB vs any2djvu about 605 KB. That is about 60% of the size of the any2djvu!
30pg dict = 333 KB
40pg dict = 318 KB
50pg dict = 308 KB
100pg dict = 278 KB
200pg dict = 262 KB
Impressive!
i am having one challenge when I try to use a very large number of files. I tried to do all 903 Emerson PBMs (500dpi) but nothing happened. I tried 500 pages and it ran and gave a positive "ring" at the end, but there was no file on the Desktop where I asked for it. I tinkered around a bit and determined that, at least in this case, when using a 10pg dictionary, the program maxes out at 461 pages. I tried it with a 20pg dictionary setting and it had similar problems. But it did do 462 pages. I did not determine the max for the 20pg dictionary setup. I had loaded the PBMs from the Win10 Documents folder and had set the output for the Desktop.
I have a zip but github is not accepting it. Maybe you could try adding a big number of files and see what is happening.
The 200pg dictionary conversion for the Tables did not take that long, maybe a minute or so. I am using a fairly new desktop computer with a 3400G Ryzen and 16 GB RAM.

Thanks.
Stephen

[trufanov-nok]

Hi, Stephen
You may send files directly to my email: trufanovan@gmail.com
It's written in a sourcecode and not a secret.
Also, if you are using GUI - there is a Log tab, its content would be helpful.
I'll test it by myself on linux with a big number of files tomorrow. The problem might be in a command line size limitation - need to be checked.

[trufanov-nok]

Got your logs.

Can't open file (errno: Too many open files)

That's definitely a system limitation on a number of simultaneously opened files (file handles). Can't reproduce on Linux. Should debug on Windows machine.

[trufanov-nok]

It seems that Windows has two limitations - Not more than ~2048 open files at once, and not more than 32Kb for a command line.
I've rewrited some parts of minidjvu-mod, and now it writes files one by one at the end of processing. So no chance to hit the limit. As for second limitation: if you have 1000 pages you can afford only ~32 characters per filename. So I added a possibility to specify not the filelist in a command line but a path to the directory in minidjvu-mod command line. So now minidjvu-mod -l c:\mybook c:\out.djvu will search for all *.tiff, *.bmp, *.pbm files in this folder. Note: they'll be ordered alphabetically and you can't control the order in this case. Minidjvu-mod GUI doesn't support directory specification yet. Perhaps it's not usefull, will allow to perform the tests. The patched minidjvu-mod is attached. It shall be able to process any number of pages
minidjvu-mod-0.9m06-1k+pages.zip

I guess, I'll add some command line size measurement into GUI and force it to use the Settings file in case it's bigger than 32Kb. With no advanced settings file options control.
.

[maple7-7-7]

Hi Alex!
Thank you for the update and the fixes. The other day I was testing your newest minidjvu-mod and I had a long list of filenames that were probably around 100 characters each, and the program would not process them. It was a lower page total than the 461 I mentioned before. I wasn't actually testing for the effect of filename length, but I did figure it was a filename length problem. The program MiniDjVuPlus, which is really useful for making a DjVu Photo Album, is very sensitive to filename length, and has the same problem with longer lists of longer filenames. That of course is another Windows program. It did not like it when I would have it try to process files in subfolders of subfolders.
Thanks again for your newest version. For myself, I am going to call it v0.9m06b, and make a note of the new improvements. I write down many of your improvements and the results on paper and keep the papers in a physical folder as a quick reference.

[trufanov-nok]

I am going to call it v0.9m06b

I've dropped a new release 0.9m07 with these features:
https://github.com/trufanov-nok/minidjvu-mod/releases/tag/0.9m07

I also have bundled it with minidjvu-mod GUI v 0.2.4: https://github.com/trufanov-nok/minidjvu-mod-gui/releases/tag/0.2.4
In this version there is an option to pass input files list via the settings file instead of the command line. This allows to process any number of images. There is also automatic enforcement of this option if command line size estimation would be more than 32Kb. The settings file is saved in the same folder and filename as output djvu, but with extension .sett. Another change in GUI is that default output dpi is set to 600 instead of 900.

[maple7-7-7]

Hi,
Are you saying on my machine only? Not quite sure what you mean.

[trufanov-nok]

No, it's Windows specific. It just takes a bit longer for me to debug something that can't be reproduced on Linux as I'm using Linux 99.9% of the time. To boot Windows machine I need to power Linux off and change the secondary HDD. Anyway I was going to launch Windows in a next few days. Perhaps I could build DjVuLibre with patched djvumake this time too.

[maple7-7-7]

Sounds doable. Thank you for the clarification. I have an older Linux laptop for internet use, to increase security. i use a newer Win10 desktop workstation with no Internet and only connect for updates when I take it to the Linux room, as more security. You can get much work done when not distracted by notifications and temptations of various types. We need longer blocks of work time.

I have djvudigital on Linux. Except for no djbzs, it has a lot of nice options.
Is this a lossless format? I need a "high-fidelity" conversion.
I have a bunch of tmds (Textmaker) that have many colorized tables in them.
I had always wanted better compression for them and your program rocks this.

I could convert them to b&w first, but then I lose my color schemes as references.
So I prefer to convert them to small bw DjVus and then re-colorize.
In fact, making bw DjVus and then colorizing seems to be better than encoding directly in color.
I saw this, too, with pages that were otherwise likely candidates for cpaldjvu.

Color DjVus at 7 kb/page with cpaldjvu 600dpi reduced to about 3-4 kb/page, and no djbzs.

A batch workflow to make lengthy small file-size minidjvu-mod DjVus to re-colorize is this:

color.tmd > color.pdf > color.djvu > color.bmps > bw.pbms > bwmini.djvu

Timesavers are WinDjVuExtended (file.djvu > color bmps) and IrfanView > pbms)

This avoids having to initially split up DjVus into pages or chunks.
Reassembling DjVus is doable and interesting, but takes quite a bit of time, for me, anyway.
Inconvenient and surprising that djbzs cannot be extracted directly with djvuextract.
Especially when it should parallel the fact that we can add djbzs when using djvumake.
I wonder if we should ask Leon about that.

The workflow, especially the djvu > bmps step, is really handy. Like a pseudo DjVu file splitter.

It takes time of course to later re-colorize the miniDjVu tables with "hand-drawn" FGbzs, but many tables are like templates and the FGbz coordinates can be repeated if saved. But I love your small file sizes, and thanks to your program, I am also able to increase the resolution of the tables should I so choose to, and still have a very nice file size.

Thanks again,
Stephen

[trufanov-nok]

I've managed to build a patched djvumake for Windows x32/x64 with WinXP support via Visual Studio 2013. Whole DjVuLibre 3.5.28 binaries are attached. Didn't test them actually:
patched_djvumake3.5.28_x64_vs2013.zip
patched_djvumake3.5.28_x32_vs2013.zip

In case exe's don't launch on old PC one may try to install Visual C++ Redistributable Packages for Visual Studio 2013