go-comic-converter
go-comic-converter copied to clipboard
celogeek
Display the picture in its original size
The resolution of many comics is smaller than the resolution of KS - 1860x2480
If you enlarge the picture to adapt to the height of the screen, it will cause a certain amount of blur.
I want to display the image in a point-to-point (pixel for pixel) manner, i.e. display the image smaller than the screen resolution in its original size on the screen.
For example, the resolution of this image is 1445x2048.
I tried changing the image size in xhtml but it had no effect.
<img src="../Images/img_1_p0.png" alt="Image 1 Part 0" style="width:1749px; height:2479px; top:0.02%; left:0"/>
=>
<img src="../Images/img_1_p0.png" alt="Image 1 Part 0" style="width:1445px; height:2048px; top:0.02%; left:0"/>
kindle size is limited to the size of the SR profile. When you put more like the KS profile, going from ePub to MOBI (using the website or the local tools), will reencode the images to smaller resolution.
Usually the fastest / best render is the SR profile.
To support bigger resolution:
- amazon need to allow it for kindle scribe: we have big screen but document still have limited resolution
- create a custom AZW3 with the GoLang tools we talk about in another PR, and put higher resolution on the images. The file need to be send manually with a cable, and can't be store in the cloud. Also the file is a hack version of the format, with partial support.
I found a strange bug.
I want to keep the original size of the image without any cropping.
Depending on the output format, we will get 2 results.
check it:
original image
no-crop & jpg
no-crop & png
Why does choosing jpg format output result in cropping part of the content?
I have disabled the cropping parameter
jpg -input "Claymore v1.zip" -output "Claymore v1.epub" -profile KS -manga -titlepage 0 -noblankimage=0 -sort 2 -strip -crop=0
png -input "Claymore v1.zip" -output "Claymore v1.epub" -profile KS -manga -titlepage 0 -noblankimage=0 -sort 2 -strip -crop=0 -format "png"
There is no problem with epub, the file that makes the difference is in the final mobi
I tried to use ChainLP to reproduce this bug, but the mobi converted using ChainLP (jpg qualty=85) did not have this problem.
ChainLP and go-comic use the same kindlegen.exe trans manga
Claymore v1 from ChainLP https://pixeldrain.com/u/9G7hXapJ Claymore v1 from Go-Comic https://pixeldrain.com/u/B5AYzbAr The epub output by ChainLP does not have this problem. After epub2mobi, both jpg and png can retain complete pictures
This Bug is really strange. If you have any ideas and need my help, please don't hesitate.
The only thing I can imagine is the PNG produce by GCC has an option epub2mobi doesn't like and have trouble to work with.
Isn't it the jpg that has the problem? Some edges of jpg were incorrectly cropped during conversion to mobi.
There is no problem converting jpg to mobi.
Observed in landscape mode, the jpg retains the complete original image.
The problem is that in portrait mode, the image seems to be forcibly enlarged by the epub css, resulting in the inability to display the complete content.
Of course, the discarded content is blank pixels, but disabling cropping means we need to display the full content.
Does your KS also have the problem that jpg cannot handle disabled cropping correctly?
https://github.com/user-attachments/files/15821018/Claymore.v1.zip
It's really weird. It's obvious that the picture saves the complete content, but KS always seems to accurately discard the blank part at the edge.
Can you set the aspect ratio to 1.6. I think kindle doesn’t handle well other aspect. That may be the case here. I will check soon. Just need to find some time to work on it. I see the aspect ratio is missing in your command.
Test aspect-ratio-1.6 and bug still exit. The really weird thing about this error is that the image files in both epub and mobi retain their original size. It shows that the '-crop=0' has been executed well. But our ks device did crop the image on its own. It's like the kindle system has an automatic cropping function, even though we know it's impossible
When I compare the generation of the file (epub) with your options between png and jpg, both are strictly the same, except the format of the output image.
Sending to my kindle to see the result.
Ok I see. png source looks like the image is not resize. And jpg it enlarge on the screen.
The jpg is the one intend by my sizing option. It's support to spread as much as possible.
so something from the epub to mobi have issue in the convertion.
this format was intend to return as much details as possible on the image (lost less), but not made for kindle. It's more for readers that support ePub with png natively.
I will try to see if I can extract the content of the mobi somewhere.
I have used calibre to extract the image in mobi. There is no problem with the image file and it is exactly the same as the image in ePub.
I extract the content of the mobi, I see some diff like:
- <img src="../Images/image00006.jpeg" alt="Image 1 Part 0" style="width:1653px; height:2480px; top:0.00%; left:5.56%" width="1333" height="2000"/>
+ <img src="../Images/image00006.gif" alt="Image 1 Part 0" style="width:1653px; height:2480px; top:0.00%; left:5.56%" width="1333" height="2000"/>
The png is output to GIF instead of JPG. I suspect the kindle to have a more limited support to this format. GIF is strange to convert to.
Also, here the format:
➜ file jpg-mobi/mobi8/OEBPS/Images/*
jpg-mobi/mobi8/OEBPS/Images/cover00007.jpeg: JPEG image data, JFIF standard 1.01, resolution (DPI), density 1x1, segment length 16, baseline, precision 8, 1279x1920, components 3
jpg-mobi/mobi8/OEBPS/Images/image00006.jpeg: JPEG image data, JFIF standard 1.01, resolution (DPI), density 1x1, segment length 16, baseline, precision 8, 1279x1920, components 1
➜ file png-mobi/mobi8/OEBPS/Images/*
png-mobi/mobi8/OEBPS/Images/cover00007.gif: GIF image data, version 89a, 1279 x 1920
png-mobi/mobi8/OEBPS/Images/image00006.gif: GIF image data, version 89a, 1279 x 1920
As you can see, mobi convertion reduce the image anyway. that's why the SR profile is the best, because the resizing is done locally, and then AWS keep the original image without resizing it again. It's way faster for a better result (you can choose the quality !)
similar diff:
- <img src="../Images/image00006.jpeg" alt="Image 1 Part 0" style="width:1200px; height:1800px; top:3.12%; left:0.00%" width="1200" height="1800"/>
+ <img src="../Images/image00006.gif" alt="Image 1 Part 0" style="width:1200px; height:1800px; top:3.12%; left:0.00%" width="1200" height="1800"/>
But the resolution change a bit. sending to my kindle ....
same result. png is converted to gif on kindle. and it doesn't display it as it should with the jpg.
I think I should revamp the profile with capability.
For example for kindle device:
- aspect = 1.6
- format = jpg ...
if you select desktop, then I can relax the settings to allow more option (as it depend of the reader). and on kobo it's another list of compatibility
I have already something for Apple Books, with enforce settings. It should be a profile.
https://pixeldrain.com/u/STXC64LL - Claymore from ChainLP.epub https://pixeldrain.com/u/cCDMHDL6 - Claymore from ChainLP.mobi Can you check these 2 files using KS? I'm very curious why epub made using ChainLP don't have this problem. The jpg image is complete on the kindle without any cropping.
After my tests I can conclude that the problem is with the image files generated by Go-Comic.
I swapped the image files in Go-Comic.epub and ChainLP.epub
Here is chainLP img set
Result: Go-Comic.epub (jpg from ChainLP) ChainLP.epub (jpg from Go-Comic) Go-Comic.epub is normal but there is a problem with ChainLP.epub
I really hope you can fix this bug after carefully comparing the differences between these 2 jpg files
Here's a quick fix. Add a ‘-raw‘ parameter.
If the user disables cropping they obviously want to keep the full image. In this case, we can directly copy the original image without performing any processing on the image. Unless destructive changes are made to the image, such as split, rotation, resize, contrast, brightness.
The 2 images here:
from ChainLP.jpg: JPEG image data, JFIF standard 1.01, resolution (DPI), density 96x96, segment length 16, baseline, precision 8, 1333x2000, components 1
from Go-Comic.jpeg: JPEG image data, baseline, precision 8, 1333x2000, components 1
the ChainLP generate a JFIF image. I've seen that trick for writing AZW file already. It seems mobi is more or less compatible with JPEG. he kind of need a fixed header.
I will try to use that standard. It's not by default. We trying to generate an image that probably have more than 20 years ... mobi is old.
I create this branch: https://github.com/celogeek/go-comic-converter/tree/38-display-the-picture-in-its-original-size
Can you try to see if I manage to fix the issue ?
go install github.com/celogeek/go-comic-converter/v2@d1265a51350446f646840a2f20f9652fa89b8a8d
The problem still exists. After replacing it with chainLP.jpg, the problem disappears.
It seems we haven't found the real difference between these 2 jpg's yet.
jpg from new branch but crop bug still exists.
I though it was ok, I've test it. I may have take the wrong file. will retry.
is it the cover above ?
Yes, the image above is from the latest branch. By the way, a recent discovery: If cropping is disabled, only the cover image does show the full size in kindle.
This gave me a guess that the problem lies in the cropping detection program part. Even if the user disables cropping, the program still leaves traces in the image. Only the cover image skips detection. But this cannot explain the return to normal in landscape mode. Well, that's just my guess.
The cover has his own way to display on kindle. It doesn't use the CSS style. The image use CSS that will scale up the image to match the kindle size. The aspect ratio will discard (by the kindle) blank part of the image in Portrait mode. The landscape has another rendering view, it have some space between each side and a different aspect as the portrait.
I'm checking if any crop has been done even if we ask not to do so. I'm checking if cropping is actually not a cropping but more a kindle behavior. You say you replace image from another source. How did you recompile the ePub ? you just zip it again ? ePub has a special header, so a simple zip is not a valid one. I don't know if that matter for kindle converter.
Also, on your screen shot, it's hard to tell what do you mean by "crop". I don't see it obviously on the screen shot.
I'm rechecking the files:
- Claymore v1 from ChainLP.epub
- Claymore v1 from Go-Comic.epub
On GCC, I see on that, the aspect ratio = 1.5. I think it's set to automatic and pick up the most common size observed in the files. On CLP, I don't see the aspect ratio settings. It's not set (original-size = X*Y). I guess it's fall back to a default value that will render differently.
Will try other stuff, with image swapping to see it on device.