HD_CONTAINER anomalies

[AcidWeb]

I have two image heavy EPUB files.
A - 2,38 MB - Image resolution: 758x1024 (PW1/2)
B - 3,93 MB - Image resolution: 1072x1448 (PW3/Voyage)

There are only two differences between them:

• image resolution
• original-resolution meta property field

When I convert them using KindleGen V2.9 build 1029-0897292 with -dont_append_source option size of output is strage...

A.mobi - 2,50 MB - This is OK.
B.mobi - 6,92 MB - Bloated like hell.

After further examination I discovered that HD_CONTAINER is added to B.mobi. For some reason it contain another copy of the same images, with the same resolution. Complete waste of space.

Headers:
A
B

It is not connected to input file size so I guess there is some boundary resolution that trigger creation of HD_CONTAINER. Additionally I experimented with original-resolution field but not found any connection with HD_CONTAINER creation.

Anybody researched this matter? Any idea how to strip HD_CONTAINER or modify EPUB so that container would not be created?

[Notjohn]

I only do reflowable books, but the so-called "mobi" created in the KDP conversion process (and I assume by KindleGen as well) actually contains two or three entire books, one for Mobi 7, one for KF8, and usually the original file you uploaded. The size of the finished book is displayed at the bottom of the pricing table on the second page of your Bookshelf detail for the book, something on the order of: Your book file size after conversion is 1.06 MB.

[AcidWeb]

I know.

And I'm not creating anything that will be delivered by Amazon infrastructure.

[DiapDealer]

Originally Posted by AcidWeb

After further examination I discovered that HD_CONTAINER is added to B.mobi. For some reason it contain another copy of the same images, with the same resolution. Complete waste of space.

If you're using KindleUnpack to investigate the images/images sizes, make sure the "Use HD Images" option is unchecked (or you're not using the equivalent command-line "i" switch).

The "Use HD Images" option causes KindleUnpack to overwrite the images in low resolution folder with their high resolution versions from the HD_Container folder. This is so the resulting epub can be built using the high resolution images instead.

I only mention this because it could explain why you're seeing...

another copy of the same images, with the same resolution. Complete waste of space.

... when the "images" and HD Container folders actually contain the same images (but with different resolution) within the binary.

Double check that you're not using the above mentioned option to verify that the two image folders contain low and high resolution version of the same images (when unpacking dual-format kindlegen-created mobis). One for the mobi7 format and one for the KF8 version.

You're right that a certain threshold causes the HD Container folder (but I don't know what that threshhold is) to be created (because the HD images can't be shared between the two different formats) but I don't think they will be exact duplicates within the binary Kindlebook.

[AcidWeb]

I had "Use HD Image" unchecked. Both sets of images are the same.

Considering that input images have already resolution of Kindle screen it not a surprise why HD Container don't have higher quality.

I'm simply puzzled why KindleGen decided to create that section at all. And more importantly - how to get rid of. Probably I will be forced to split KindleGen ouput and produce clean KF8 file - but I really don't like this method as it is _slow_ with MOBI files that contain hundreds of pictures.

[DiapDealer]

Originally Posted by AcidWeb

I'm simply puzzled why KindleGen decided to create that section at all.

So that the KF8 format can contain higher resolution versions of images that mobi7 does not support. The dual format mobi normally shares images between the mobi7 and KF8 portions. This is not possible when images that have a resolution higher than mobi7 can support, so the HD Container is created for KF8 alone.

And more importantly - how to get rid of. Probably I will be forced to split KindleGen ouput and produce clean KF8 file - but I really don't like this method as it is _slow_ with MOBI files that contain hundreds of pictures.

That may be your only option, as I don't think there's a way to tell kindlegen not to create it (if images hit the threshold).

[AcidWeb]

Thank you for explanations.

I will check my old Python3 rigged KindleSplit version - but I expect that it will not detect HD container at all and place it unchanged in output file.

[AcidWeb]

Well as expected it would require some MOBI hacking skills WAY over my knowledge.

I do not feel comfortable asking for code donations once more so I will probably will offer some bounty this time. I have to think about...

EDIT:
I'm apparently blind as HQ container contain images with lower compression.

EDIT2:
Well. I found reason of bloat. I screwed up EPUB headers. book-type and original-resolution need to be meta name not meta property. I messed that up in last update. With them in place KindleGen don't create HD container at all.