Software is not signal processing. If you pass valid input to a software program and it does not do as advertised, it is a bug that needs to be fixed, not something random that just happens. It will have an underlying cause.
So random or anomalous behaviour in a piece of software is a bug by its very definition.
Quote:
As for "compressed" versus "uncompressed" the answer should be obvious.
Kindlegen applies compression to input images (assuming you do not use the -C0 option in the command line). The resulting "compressed" images are sent to standard resolution devices, and I presume these are what end up in the mobi7/mobi8 images folders on extraction. The original source images remain "uncompressed" (i.e. not resized in either resolution or file size), and these I assume are contained in the .azw3 file as well as the kindlegensrc.zip, deriving now from those stored in the HD CONTAINER if I understand correctly.
|
Well actually based on your definition of "compression" above, it was not obvious at all. Any data can be losslessly "compressed" using a number of different data compression schemes that have nothing to do with image data, image size or image resolution. I thought you were talking about gzip, zip, huffman, etc compression schemes on the data and not downsampling and image conversion. The reason this is important is that the starting bytes in the Mobi sector are used to identify the image type. If the data itself is compressed using a compression scheme like zip, gzip, huffman, xc, etc, these bytes would not match any known for an image and would cause a problem in KindleUnpack.