[Tex2002ans]

I have attached three EPUBs to this post:

• A modified GrumpyGranny with a few more derivatives I generated.
  • I generated 3 more sets of each image: Yours -> GIMP (Double checked Index values and saved), GIMP -> ScriptPNG, Yours -> ScriptPNG.
  • I added the bit depth to text above each section.
• A test EPUB with lots of variations of formula images that I generated.
  • 5 formulas * 6 variations = 30 images. Plus at the end I added ScriptPNG versions of ALL 30 images.
• An EPUB I created when I first ran into this problem (QJAE).
  • This was when I first ran into this "banding" issue. [Images at the end of the post]

Let me start off with a basic overview of the different bit Grayscale/Indexed PNG:

If you are saving as a Grayscale PNG, there is this:

1-bit: 2 shades of gray
2-bit: 4 shades of gray
4-bit: 16 shades of gray
8-bit: 256 shades of gray
16-bit*: 65535 shades of gray

* It seems like this is used most commonly when scanning B&W FILM.... don't know the status of this in actual book scanning (or PDFs you find online).

Side Note: I have no way of generating these (GIMP doesn't support it), perhaps Photoshop can export 16-bit grayscales? I will have to hunt around and see if I can find examples of these, maybe I can generate one using Imagemagick. I don't know if ADE could handle these, but it would be fun to toss at it and see what happens (Perhaps it turns into a big black box like my Grayscale + Alpha image).

Indexed PNGs are a replacement of GIFs, and work on ANY colors:

1-bit: 2 colors
2-bit: 4 colors
4-bit: 16 colors
8-bit: 256 colors

1-bit and 8-bit are the most common.
2-bit PNGs seem to have poor/wrong/non-existent implementation in a lot of programs. GIMP seems to output 2-bit and 4-bit correctly.

If the image program is competent, it should select the proper n-bit for the amount of colors.

<= 2 colors should be 1-bit
3-4 colors should be 2-bit
5-16 colors should be 4-bit
17-256 colors should be 8-bit

Side Note: They probably just got lazy and decided to cut down on logic, and only care about 1-bit B/W (think book scans) or 8-bit Grayscale/Indexed. 8-bit encompasses all below, but would just be slightly more bloated than it COULD be.

NOTES on the Test EPUB:

Side Note: Next time, just use zero text appended to the bottom, this means that it will be the SAME EXACT IMAGE, but the only variable thing changing is the different settings. You can always add the explaining text in the EPUB between sets of pictures + relevant filenames.

I used imagemagick's "identify -verbose" command to take a close look:

- Your "2-bit" image is actually saved as a 4-bit image (could be non-existent support for 2-bit PNG in PaintShop Pro).
- Your "3-bit" image is actually a 4-bit image (no such thing as 3-bit lol)
- Your 16->256 is saved as an 8-bit image.
- All the others are saved as the correct bit.

GIMP:

- 2 color image saved properly as 1-bit.
- 4 color image saved properly as 2-bit.
- 16 color image saved properly as 4-bit.
- 256 color image saved as 8-bit.


Testing on my Nook:

- In the 16->256->16 section.
-- The only difference is bit-depth (PaintShopPro = 8-bit, GIMP+ScriptPNG = proper 4-bit).
-- My Nook shows weird artifacts (looks like speckling) on the 4-bit images.



- In the Indexed 8 color section, for some weird reason the GIMP version looks EXTRA HORRENDOUS.
-- Your version + ScriptPNG versions look speckled, but otherwise the same.
-- This is odd because they are all 4-bit, so I would have expected that all three would look horrible... so I have no clue.



- There is weird degradation in your image reduced to 16 colors, there is no degradation in the GIMP 16 color version.
-- This is also odd.

My Image Test EPUB:

OF COURSE I can't get the problem to replicate in my test EPUB consistently NOW... (those gremlins are out to get me lol). But the PNG I was able to get to break was the 2-bit elementof PNG compressed through ScriptPNG:



Here is the problem as I first ran into it in the QJAE (EPUB is attached):



My best guess is... ADE has a bug with 2 and 4-bit PNGs. The "banding" issue is happening on your images, but it is just VERY HARD to tell because of the nature of a photographic image. In my formulas it is much easier to see the bug because there are large swaths of solid color.

Without access to ADE source code, I have no clue exactly what the problem is. I will continue to poke around at the different images with imagemagick... hopefully between comparing all of these different images, I can stumble upon SOME difference. Maybe ADE is ASSUMING 1-bit/8-bit but is ALSO looking at the amount of colors in the PNG, if it falls into those in between ranges, maybe ADE blows up (The amount of colors are saying it should fall into "2-bit/4-bit" while another part of code is forcing it into 8-bit mode?).

This bug COULD have been fixed on a newer version of ADE... could anyone test all of this on a newer e-ink device?

Side Note: Days of work has gone into this. I was reading all this in depth PNG documentation, now time for my brain to explode.

Edit:

Originally Posted by Jellby

That's basically what I mean. With 256->16 you reduce the number of colors to 16, with 16->256 you ensure that the colors are stored as 8-bit numbers.

I just thought of this. Perhaps as a workaround, the image can be reduced to 17 colors instead. This will still force the PNG to 8-bit mode, you will have a very minimal amount of shades of gray, and most of that useless information can be tossed out, leading to a semi-smaller filesize (definitely less than the 256 shades of gray image). ADE SHOULD display that one fine (since it is 8-bit). My brain hurts, I might test it later in the week.