Open pretenderlu opened 1 year ago
@pretenderlu
Do you have an example? input file and settings used? (GUI settings or command line settings)
I have tried many times, whether it is ks or other custom, or choose not to process the picture……maybe you can try any one picture 1860x2480 Sample:https://drive.google.com/file/d/1SMI5fIbq0gVkc75bcrg3JgtzOncC2N/view?usp=share_link
@pretenderlu
I tried your input file
same settings as Quicker_20230119_163441.png
if I unzip the generated 001.epub
in \001\OEBPS\Images\
the file test.jpg is 1860 x 2480 Pixels (4.61 MPixels) (3:4)
<img width="1860" height="2480" src="../Images/test.jpg"/>
in 001\OEBPS\Text\test.xhtml
Where and how do you see a result of xxxx1920
?
@darodi if you turn the epub to mobi, the picture will be change
@darodi Epub is OK. The problem is the mobi format file.
How did you convert to mobi?
Amazon Kindle Previewer 3 Folder\lib\fc\bin
?@darodi Just use KCC, output epub & mobi as the same time.
@darodi I just use KCC, so that means I using kindlegen.
The kindlegen is from https://www.amazon.com/Kindle-Previewer/b?ie=UTF8&node=21381691011 in Amazon Kindle Previewer 3 Folder\lib\fc\bin.
I experience the same issue (.epub is 18602480, .mobi/azw3 is x1920) both by using KindleGen and Send to Kindle via browser. :(
@pretenderlu @nicoladicicco
Indeed, there seems to be a limitation with kindlegen.
What is the result if you open the created epub in Kindle Previewer 3
https://www.amazon.com/Kindle-Previewer/b?ie=UTF8&node=21381691011 and export to mobi?
Use the GUI or command line:
Put C:\Users\username\AppData\Local\Amazon\Kindle Previewer 3\
in your path
or go into that directory then:
"Kindle Previewer 3.exe" 001.epub -convert -output .
There is also a new pc version of Send to Kindle for Windows
. https://www.amazon.com/sendtokindle/pc
Is the result correct with it on your device?
@darodi Unfortunately, still the same result.
I thought the images looked a little soft, so this is why. I converted the final MOBI back to EPUB using Calibre and see it now.
Looks like kindlegen used to have a -preserve_img
parameter that either got removed or renamed. https://reverseengineering.stackexchange.com/questions/14121/how-to-find-obfuscated-hidden-command-line-parameters.
There's a bunch of references to 1920 here: https://kdp.amazon.com/en_US/help/topic/G9GSTY4LTRT39D4Z
@axu2 I'm just more confused, after all, ks can support such a large resolution, it's still a shame. Speed is not a point of concern for me.
@pretenderlu @axu2 @powersee @nicoladicicco
Amazon has announced the retirement of its proprietary MOBI file format for eBooks, and a transition to the EPUB format for use on Kindle devices and apps. (August 2022)
I don't own a kindle scribe, but could someone try to use https://www.amazon.com/sendtokindle with an epub to send to kindle scribe and tell the result?
I doubt the file in the kindle will be a mobi file, and the resolution might be correct.
@darodi I have sent recently several epubs to my Scribe using Send to Kindle via web. They are converted to AZW3, and to the best of my recent experience the image resolution is still downscaled (down to 1440x1920).
Amazon's support for epubs means that you can indeed sideload epubs to your device... but for now they still need to be converted in their proprietary format
Is there any other way to send a file to the Kindle Scribe with the native resolution of the panel (2480x1860)? Or does that mean you're always limited to x1920 and <256kB images? I'm new to Kindle devices, so I don't know
Thanks! That's honestly pretty sad, wanted to get a Scribe for high-quality manga...
Yea, it's barely better than the Kobo Elipsa. Maybe Amazon will unlock the resolution later in a future version of Kindle Previewer, I bet the maximum resolution was hard coded like 10 years ago for the Kindle Fire which had 1920 height.
These projects don't use kindlegen to create MOBI, bypassing the 1920 restriction: https://github.com/leotaku/kojirou https://github.com/tsopeh/mapaki
both use the go library: https://github.com/leotaku/mobi
Feel free to experiment and report your results on image quality/sharpness/file size. The fact that this is a 3rd party implementation of MOBI file creations may have issues since I haven't tried it myself.
~An idea could be using KCC Scribe profile but select CBZ output to resize to 2480 height and other kcc optimizations. And use that CBZ in the other projects to make a MOBI without the 1920 restriction.~
I've done some test with local conversion. I create an epub from my comic, which resolution is ...x3031 (3031 height). The size is 245M
I also create an epub from the same comic with max resolution set to 1920 (height). The size is 122M
Then I run on each of my epub,
kindlepreviewer EPUB -convert
I have 2 mobi. The high resolution take a long time to convert and the size is 374M The standard resolution take little time to convert and the size is 246M
When I ask calibre to transform those mobi to ZIP or EPUB, I check the images directory after unpacking, both have image with maximum width or height to 1920 both have the same size of 126M
So, first, if the image is resized, why do we have 2 differents size of mobi here ? And why both mobi lead to the same epub size ?
is it possible that the image is actually correct in the mobi, but calibre downsize it during conversion ???
Summary: HR(3031 height): Mobi = 374M => epub = 126M => image from epub limited to 1920 SD(1920 height): Mobi = 246M => epub = 126M => image from epub limited to 1920
After fixing my converter call, with "dont_append_source" (thx @darodi ), both endup with similar size. The big difference is the time of conversion. For the 1920 resolution, it's few seconds, as if he don't need to do anything, just convert. The 3031 resolution, take 15 min I think, and each image seems to be resize.
With the current support of amazon, image <=1920 is highly recommended. Same result but very fast conversion.
I see some module on GoLang to create AZW3, I haven't seen something about resizing image in it, I will give it a try.
The module seems to generate an older version of AZW3. So even the format has versioning. I haven't found an obvious way to transform an ePub to AZW3 in the doc. I see this: https://github.com/leotaku/mobi Is a kind of helper for the PDB database. At some point, it's a matter of pushing html+css+image into the palm database in a specific order I suppose. The HTML include ref to image, but ref are encoded differently into an MOBI. It's like a ID in a database.
I will try to find some example with an image.
This application create hybrid MOBI/AZW3 files. Don't be misled by extension of file output. All problems described in this topic are limitations of the used format and/or kindlegen itself.
Remember that Amazon already moved to KFX format.
If KindleGen work "slow" that mean it reconverting images created by KCC again as they are outside the specification.
Don't expect this issue to be fixed on Amazon side. This is not a bug.
Is they a way to create KFX from Epub with a tools from amazon ? or third party tools ? may be calibre ? is that accurate ? does it works ?
KFX support larger image ?
There is a plugin in calibre to convert epub to kfx https://www.mobileread.com/forums/showthread.php?t=272407 I haven't tried HQ images yet.
I had tried this method, use the plugin in calibre to convert epub which is generated by KCC, the picture in the result kfx file could not fill the full screen.
There is a plugin in calibre to convert epub to kfx https://www.mobileread.com/forums/showthread.php?t=272407 I haven't tried HQ images yet.
I use Calibre to convert CBZ files to KFX (using the KFX output plugin) and use the viewer in Calibre. It displays that the image resolution is 1859 x 2480 (no cropping). However, as others have said, the image does not fully fit on Kindle Scribe.
Did you use the process described here?
https://www.mobileread.com/forums/showpost.php?p=4430602&postcount=1547
Did you use the process described here?
https://www.mobileread.com/forums/showpost.php?p=4430602&postcount=1547
You saved my life! Yes, it is the best way! Absolutely the best quality. I can only say that the creation process is too complicated. Using Kindle Create is very painful; aside from the error prompts, it crashes if there are any non-English characters in the path. It also seems that the author's name cannot be entered in Unicode (though I'm not sure about this yet). Compared to Kindle's official books, the converted KFX only lacks the fast page-turning and bookmark functions, which is almost ideal. I hope that in the future, there will be a way to simplify these processes, especially a fully CLI-based method...
@2ji3150 if you could upload some comparison shots here or on mobileread, that'd be cool.
I wrote a guide for utilizing kcc
and mapaki
for full resolution Manga on the Kindle Scribe. Hope someone finds it useful.
@darthtechworker thanks for the images! It looks really sharp!
Out of curiosity, why did you use mapaki over kojirou? I've used neither.
I see you answered in the comments why you chose azw3 over kfx.
Out of curiosity, what looks sharper? Starting with an image, with say, 2400 height. (The important part is that the height is between 1920 kindlegen limit and 2480 scribe height).
1) Process that image directly in mapaki, preserving 2400 height, and let the scribe resize the image to 2480.
2) Or do your method that uses kcc to first upscale to 2480 height?
@axu2 I choose Mapaki because Kojirou requires you to pass a Mangadex id to run the script. There is a way to skip getting images from Mangadex if you already have the images, but I couldn’t get that to work.
I did not know that Kindle upscales the images. I believe it does not. Because I do not see lower resolution Manga getting upscaled on my Kindle Scribe.
Btw many thanks for maintaining KCC for us. I could’ve never gotten into reading Mangas and Comics on Kindle without it.
When I say upscale, I mean that if I say upload a mobi with 1200 height, it fills the screen instead of only taking up half the screen height of 2480 and leaving huge borders.
And you are welcome. I wonder if it's possible to integrate the go mobi library in kcc.
Gotcha, yeah scribe always fills the screen.
I think it should be possible. There are some libraries that allow python to interact with the shell, so you could have mapaki as a dependency and then invoke it through the shell through python.
~Ah, I see on Reddit you confirmed that letting kcc upscale first gives you sharper results than using mapaki alone. This implies that kcc is a better upscaler than the scribe.~ Did you use default gamma or did you disable gamma by setting it to 1.0?
Out of curiosity, does using mapaki
solve any of the other scribe issues?
I used default gamma. (unchecked Custom gamma). I haven't experimented with gamma yet, already so happy with current results, don't wanna go down another rabbit hole just yet 😅
I only tried jpg. I don't have any png Manga, so I can't comment on those.
@axu2 I did 3 things 1) Just use KCC for .mobi 2) Use KCC for cbz and then use Mapaki to package into a AZW3 3) Just Use Mapaki to package into a AZW3
Picture quality to me was 2 > 3 > 1
KCC mobi was blurry to the eyes.
Resolution difference between (KCC + Mapaki) and (just Mapaki) was imperceptible, however the blacks from (KCC + Mapaki), gave an illusion of more contrast and therefore appeared to have more resolution to the eye.
Thanks for the info! Here's some background info you might find interesting.
(TLDR: kindlegen downscaling of content larger than 1920 was REALLY blurry).
And the black level difference is due to kcc image adjustments, mostly the gamma.
When I choose ks for output, the generated mobi does not reach the resolution of 18602480, but xxxx1920.What seems to be a limitation?