10-15-2010, 07:42 PM | #106 | ||
Addict
Posts: 326
Karma: 960
Join Date: Jul 2009
Location: Florida, US
Device: Kindle DX, iPad
|
Quote:
-Update- badbob, going through the amazing test case you uploaded, it looks like the output .gif images are the correct size. What program are you using to get the width and height stats of the images? Both my linux standard image viewer ("Eye of Gnome") and ImageMagick (identify -format [%w or %h] [filename]) are reporting size information different from your chart. Quote:
-Update- Fixed the Kindle bookmark code, it was a silly mistake that has probably been broken for a long time. I don't read manga on my KDX anymore so I never would have caught this. Thanks, the fix will be included in the next update. Last edited by lilman; 10-16-2010 at 11:10 AM. |
||
10-18-2010, 03:04 PM | #107 |
Fanatic
Posts: 556
Karma: 1102020
Join Date: Sep 2009
Device: Kindle Keyboard (rip), Kindle Voyage, Fire Tablet 10 '17, iPad '19
|
Sorry that I didn't respond sooner since updating your post doesn't actually make the thread appear updated.
I really don't understand why on linux you're seeing the gif sizes as normal. I'm relying on Windows XP's interface to tell me the dimensions and they are confirmed by MS Paint, Picasa Photo Viewer, Internet Explorer, and Firefox. The attached screen capture compared \GIF\01 Scenario+trim+border+rotate\0000.gif and \JPG\01 Scenario+trim+border+rotate\0000.jpg. Notice that the gif has extra large margins to the left and rights sides and a very small margin to the top (and bottom)? On web browsers, those extra margins appear as white. Perhaps it's transparency? I ran the canti analyze option and it doesn't show the problem, so I don't know what to say about that (see attached txt). At least it shows the 800x800 issue with jpg/png in certain scenarios. Have you tried viewing one of the gifs on your Kindle? I'm curious if it can be viewed currently without crashing the app. Thanks! |
Advert | |
|
10-18-2010, 04:05 PM | #108 | |||
Addict
Posts: 326
Karma: 960
Join Date: Jul 2009
Location: Florida, US
Device: Kindle DX, iPad
|
Quote:
Quote:
I'm guessing it's a problem with the way trimming works now. In order to force the trimming of a certain color, I have to add a 1px border of that color to the image and then trim. After trimming the algorithm then does a -1-1 repage of the image, but that may not be correctly adjusting the canvas size. Quote:
I haven't turned on my Kindle in ages. If I get a chance I will try it, but if it crashes for you I'm guessing it will crash for me as well. Also, I don't see the benefit of using .gif for comic scans... they're freaking huge compared to .jpg, and personally I can't tell the difference in graphics quality. Last edited by lilman; 10-18-2010 at 04:08 PM. |
|||
10-18-2010, 04:57 PM | #109 |
Fanatic
Posts: 556
Karma: 1102020
Join Date: Sep 2009
Device: Kindle Keyboard (rip), Kindle Voyage, Fire Tablet 10 '17, iPad '19
|
Yes, at this point, I think I'm going to stick with JPG, but I was just curious if GIF would be sharper. Curious how the PNGs created by Mangle are much smaller than even Canti's JPG output.
Any chance the next version will move the unarchiving temp folder from the parent_folder to the output_folder? This would allow me to work with read-only media, read-only network shares, and cut down the back and forth on network shares. Or perhaps have a setting to specify an over-riding temp folder. Do you know if the .manga and .manga_save extensions are actually officially created by Amazon for the kindle, implying that they had manga support in mind? Thanks! |
10-18-2010, 05:40 PM | #110 | |||
Addict
Posts: 326
Karma: 960
Join Date: Jul 2009
Location: Florida, US
Device: Kindle DX, iPad
|
Quote:
Quote:
Quote:
|
|||
Advert | |
|
10-19-2010, 07:08 AM | #111 |
Fanatic
Posts: 556
Karma: 1102020
Join Date: Sep 2009
Device: Kindle Keyboard (rip), Kindle Voyage, Fire Tablet 10 '17, iPad '19
|
Does the conversion process involve multiple convert commands or just a single long convert command? If the former, then perhaps it would be best to pick a lossless image format to hold the intermediate results (png?). This may fix the gif issue since you will only need to output to gif at the very end, similar to pdf. And maybe the files will be smaller and less blurry since you're not re-compressing over and over again.
Does the @auto_split_buffer parameter limit itself so that the final split pages are not wider than the target resolution? So if I set it to the maximum (1.0), it'll only include as much of the other page as the available space. This would help eliminate seeing the fill border on split pages. Thanks! |
10-19-2010, 09:13 AM | #112 | ||
Addict
Posts: 326
Karma: 960
Join Date: Jul 2009
Location: Florida, US
Device: Kindle DX, iPad
|
Quote:
So it all comes down to what algorithms ImageMagick uses for cropping. I know there are lossless crop algorithms for .jpg, and I assume that since ImageMagick is such an amazing image processing program that they would use the best available algorithms. Quote:
If you use fill border, you would still want it for split pages since the purpose of fill border is to make the page fit the screen perfectly (so the need for fill border is independent of the contents of the page). The purpose of splitting pages is to that the page can better fill up the screen, making it easier to read. Fill border occurs after image resizing so it won't affect how much of the screen the real image data takes up (it just fills in what would have been empty space with whatever border color you specify). |
||
10-19-2010, 10:19 AM | #113 |
Fanatic
Posts: 556
Karma: 1102020
Join Date: Sep 2009
Device: Kindle Keyboard (rip), Kindle Voyage, Fire Tablet 10 '17, iPad '19
|
Ok, but I just didn't want an arbitrary auto_split_buffer percentage to push the final image beyond the target dimensions. It would be nicer if the overlap buffer was dynamically determined based on how much leftover space there will be after the split.
Say the target device is 600x800 and there is a 1000x800 page. A non-buffered split would be 2 x 500x800 pages. With bordering, it'll add 50 pixels to the left/right sides of each page. It would look better to only add the border to the sides away from dividing edge: [border][left page] [right page][border] Now it is very clear visually which side of each page is the divider. Another idea would be a dynamic overlap buffer that would calculate how much room is left (600-1000/2=100) and add that difference to to the left and right pages so we don't have to deal with borders for splits. [left page][100 pixel overlap] [pixel overlap][right page] Just some suggestions. App is still awesome. |
10-19-2010, 11:53 AM | #114 | ||
Addict
Posts: 326
Karma: 960
Join Date: Jul 2009
Location: Florida, US
Device: Kindle DX, iPad
|
Quote:
Btw, the split doesn't necessarily occur in the dead center of the image. The split algorithm starts in the center and moves outwards to handle cases where the two-page scan isn't perfectly centered. The split buffer then takes the specified percentage of the other split page. So if a page with a width of 1000 is split at x=600 and the split buffer is set to 0.1, then the left page (with a width of 600) will get a 40px buffer from the right page (width of 400), and the right page gets a 60px buffer from the left page. This all happens prior to resizing. Quote:
|
||
10-19-2010, 02:44 PM | #115 |
Fanatic
Posts: 556
Karma: 1102020
Join Date: Sep 2009
Device: Kindle Keyboard (rip), Kindle Voyage, Fire Tablet 10 '17, iPad '19
|
My point regarding borders only applies to splits for landscape spreads. In print, it's normal for single pages to have margins on both sides. But for two-page spreads, the margins are only located on the opposite far sides. If you take apart the two-page spread and add in the inside margins, then the pages would look like stand-alone pages and be confusing visually. By having the margin on one side gives one a visual clue to the fact that the current page is part of a spread and the next section continues on the side where there is no margin.
It's just a visual design thing and not worth worrying about. |
10-19-2010, 02:56 PM | #116 | |
Addict
Posts: 326
Karma: 960
Join Date: Jul 2009
Location: Florida, US
Device: Kindle DX, iPad
|
Quote:
|
|
10-20-2010, 12:45 PM | #117 |
Addict
Posts: 326
Karma: 960
Join Date: Jul 2009
Location: Florida, US
Device: Kindle DX, iPad
|
Here's an update on what I've been working on for the next release of Canti:
-[code done] Contrast adjustment (user requested) Ability to adjust the contrast of images. Personally I don't like this feature... contrast is one of those things you shouldn't leave up to a batch job, but instead should be done manually on a per image basis. But someone requested it, and it is a feature of ImageMagick so it wasn't hard to add to Canti. The same user also requested implementing ImageMagick's auto-gamma feature, but I tried it out and it really doesn't work well on manga scans so it will not be included. -[code done] Handle read-only parent_folder (user requested) Canti normally uses parent_folder for some temporary files (namely unarchiving zips/rars in parent_folder, or converting a pdf in parent_folder to an image folder), but this isn't possible if parent_folder is read-only. I was afraid this would be difficult to implement, but it turned out to be like a 30 minute job. -[dropped] When using @auto_split_landscape_scans and @add_border, use split_buffer as horizontal border (user requested) I am not sure this can be implemented since adding borders occurs after landscape splitting and major image processing. In other words, by the time you want to use the split_buffer as a border it may be no longer possible to do so. I will think more about it, there maybe a clever way to pull this off. Update: This really isn't possible short of reprocessing from the unsplit scan. This feature has been dropped. -[code not started] Directional add_border (user requested) Instead of centering the scan when adding a border, add horizontal border to simulate the original physical page side (left or right) of the scan. This of course could only be used on landscape split scans since it is impossible to determine the original page side of a scan otherwise. -[code not started] Sharpen image I'm interested in exploring ImageMagick's sharpening abilities to see if they should be included in manga processing. Well that's about it. Also some random bug fixes (like the Kindle bookmark bug, which has already been fixed). Last edited by lilman; 10-20-2010 at 05:02 PM. |
10-20-2010, 05:25 PM | #118 | ||||
Fanatic
Posts: 556
Karma: 1102020
Join Date: Sep 2009
Device: Kindle Keyboard (rip), Kindle Voyage, Fire Tablet 10 '17, iPad '19
|
Quote:
Quote:
Quote:
Quote:
I hope that made sense. |
||||
10-20-2010, 06:51 PM | #119 | |
Addict
Posts: 326
Karma: 960
Join Date: Jul 2009
Location: Florida, US
Device: Kindle DX, iPad
|
I think color balancing is more related to gamma than contrast. Contrast is how distinct things in the image look in comparison to other things. For example, after increasing contrast what was once a mere speck looks a lot more noisy. I don't like auto balancing color or contrast since I think it is something that should be left to the human eye to decide, but it was requested so I included it.
Quote:
To sum up the logic since it can be a bit confusing: 1) Find the x coordinate for a page split 2) Split the image. If the user specified a split buffer, move the x coordinate a bit for each page side before performing the split (so each page may have a different x split coordinate when using a split buffer) 3) Process the split pages like normal (trim, resize, etc.) 4) Add borders if the user requested them and they are needed That should explain why I couldn't implement using split_buffer as a border. Once a landscape scan has been split in two, each page is treated independent of the other. Each page may be trimmed, resized, etc. differently than the other. You can't go back later and say "I want to use some of you as a border for this other page" since there is no guarantee that they will still be properly aligned. The alternative is to know ahead of time how big the image is going to be after resizing, and this would be possible if ImageMagick didn't handle the trimming (i.e. Canti could predict a simple image resize, but not including an unknown amount of trimming). I hope that explains it. |
|
10-20-2010, 11:13 PM | #120 | |
Junior Member
Posts: 6
Karma: 10
Join Date: Oct 2010
Device: Kindle DX
|
Quote:
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Canti: Manga Processing Program | lilman | Workshop | 42 | 04-14-2011 06:52 PM |
Canti: Manga Processing Program | lilman | Apple Devices | 55 | 04-14-2011 05:50 PM |
Classic Canti: Manga Processing Program | lilman | Barnes & Noble NOOK | 4 | 07-14-2010 04:45 PM |
Canti: Manga Processing Program | lilman | Sony Reader Dev Corner | 1 | 07-14-2010 04:43 PM |
Best for manga | eqzitara | Which one should I buy? | 27 | 11-19-2007 07:58 AM |