My Manga Program

[lilman]

Originally Posted by badbob001

Regarding the new trim_cancel option, which is awesome, if the trim amount exceeds the specified percentage, does it just trim up to the limit or does it leave the page untrimmed?

It will leave it untrimmed. Canti uses ImageMagick's trimming algorithm so it actually performs the trim and then determines whether to:
1) Keep the trimmed image and delete the untrimmed image
2) Delete the trimmed image and keep the untrimmed image
based on the @trim_cancel value. In other words, Canti has no direct control over trimming, so it doesn't just say "trim x # of pixels". I would have to write my own trim algorithm to leave a trim buffer.

Originally Posted by badbob001

Is it possible to specify that the add_border_color option use the same color that was trimmed? If nothing was trimmed, then use a specified default border color?

Canti tells ImageMagick to only trim white, and should stop once it reaches any color outside of white fuzz. So if you want to use the same color border as was trimmed, set @add_border_color to white.

Originally Posted by badbob001

I ran it against a 179 page comic and as usual, convert ate up all the virtual memory but strangely didn't use much real memory. I left it running and churning. In the morning, touching the computer made it bluescreen and reboot. After it's back, I check the comic pdf and it's perfect. I'll have to investigate if convert has parameters to limit its memory usage. Anyway to pass in additional convert parameters during your apps operation?

You had to leave it running overnight??? Let me do a quick test to see how long 179 scans take to process on my laptop...
...
3 mins 18 secs.
The dual core cpu was running hard the whole time, but the only time ram starting filling up was while creating the pdf (and even then the ram usage increased by 800mb at most, so virtual memory was never used).

You're on a netbook right? Maybe there is something weird with ImageMagick and netbooks.

[lilman]

Here's Canti v1.92

New to verison 1.92:
-Bug fix: Brain tweak
Canti's brain had to be tweaked a bit. It wouldn't correctly determine that an output_folder archive needed restoring because a new output format (like .pdf) was requested by the user.
-Set unrar and rar handlers in .properties file
In previous versions of Canti, unrar/rar handlers were determined automatically at runtime. This can be a problem if Canti is unable to find unrar/rar handlers on your system even though they are there.
The locations of unrar/rar handlers is now specified in the .properties file.
When creating the .properties file, Canti will attempt to determine these values automatically. If it can't find one/both, the user can manually specify the values.
Canti will still attempt to find unrar/rar handlers at runtime if the values in the .properties file are blank or inaccurate.
This is set up in the .properties file.

Enjoy and let me know if this works for you

[jozicka]

Getting close:

unrar handler: d:\winrar\
rar handler: d:\winrar\

Testing rar handler...
Can unrar: true
Can rar: true

parent_folder D:\image1\ast.cbr is a rar/cbr, so running in single folder mode

Restoring 1 image folders in parent_folder...
java.io.IOException: Cannot run program "d:\winrar\": CreateProcess error=5 acess is denied

[lilman]

Originally Posted by jozicka

Getting close:

unrar handler: d:\winrar\
rar handler: d:\winrar\

Testing rar handler...
Can unrar: true
Can rar: true

parent_folder D:\image1\ast.cbr is a rar/cbr, so running in single folder mode

Restoring 1 image folders in parent_folder...
java.io.IOException: Cannot run program "d:\winrar\": CreateProcess error=5 acess is denied

So close. @unrar_handler and @rar_handler need the exact path including executable name. For example:

unrar_handler = C:\\Program Files\\WinRAR\\UnRAR.exe 
rar_handler = C:\\Program Files\\WinRAR\\Rar.exe

[jozicka]

Superb!

Now it is all working!

Great job! You are a master!

[badbob001]

Originally Posted by lilman

Canti tells ImageMagick to only trim white, and should stop once it reaches any color outside of white fuzz. So if you want to use the same color border as was trimmed, set @add_border_color to white.

I'm pretty sure it's cropping a page that has a black background (see attached).

Is there a way to make auto_rotate not rotate a page if it is undersized? See the attached before.jpg and after.jpg.
The original size is 700x500. I have my device resolution set to 800x-1 so it should fit without change. But...

• It's black background got cropped.
• It got rotated.
• It got shrunken.
• The left and right sides got filled with a white background.

I'm not sure what really happened and why it got downsized. Perhaps it got downsized and then rotated?

I have another page that is 1103x803. Ideally, it would be rotated and shrunked to something like 800x1100. But it got rotated and shrunked to 587x803 and had borders added to the sides to create a final 800x803 image. I disabled borders and the image is still shrunken. Again no difference if I change max_dpi between -1, 167, and 72.

My settings with 1.92

width (in pixels): 800
height (in pixels): original
maximum dpi: original
auto trim: true
trim fuzz: 15%
trim cancel: 0.7
add border: true
border color: white
auto rotate: true
color mode: grayscale
num colors: 256
pdf chapters: true
pdf r to l: false
archive chapters: false
epub chapters: false
auto bind: false
auto split landscape scans: true
split right page first: true
keep unsplit scans: true
allow auto split color scans: true
auto split gray strictness: 0.0
auto split color strictness: 0.0
auto split buffer: 0.0
auto sense landacape folders: false
use original filenames: true
archive input image folders: false
delete output image folders: false
image format: .jpg
kindle bookmark: true
comic zeal naming: false
ImageMagick home directory: C:\Program Files\ImageMagick-6.6.4-Q16\
unrar handler: C:\Program Files\WinRAR\Rar.exe
rar handler: C:\Program Files\WinRAR\Rar.exe

Originally Posted by lilman

You had to leave it running overnight??? Let me do a quick test to see how long 179 scans take to process on my laptop...

I really have no idea what is going on, but I see convert.exe using 8MB of ram and 2+GB of virtual memory. Now the harddrive is thrashing and it's very very slow, hence why I just left it running.

This a laptop has a Core 2 Due 2.26Ghz, 2GB ram and Windows XP. I'm going to increase the page file from 2GB to 3GB to see if that helps. How can I have canti skip the final PDF output step? What are the convert.exe parameters to create the final pdf from the processed images? I want to see if I can run convert.exe outside of canti but using the same parameters to see what happens.

In other news, I've made a batch file that makes it possible to invoke canti by dragging a folder or comic file onto a script file, avoiding the need to open a command prompt.

Open notepad, paste the following, and save as something like run.cmd in the canti folder.

@echo off
set parent_folder=%~1
set title=%~n1
set app_folder=%~dp0
set output_folder=%~dp0%~n1\

set parent_folder=%parent_folder:\=\\%
set output_folder=%output_folder:\=\\%

echo - Parameters ----------------
echo app_folder=%app_folder%
echo parent_folder=%parent_folder%
echo title=%title%
echo output_folder=%output_folder%
echo.
echo - To Run ----------------
set to_run=java -jar canti.jar -parent_folder "%parent_folder%" -title "%title%" -output_folder "%output_folder%"
echo %to_run%
echo.
pause
cd "%app_folder%"
%to_run%
pause

Then simply drag and drop a folder or comic file (eg: cbz, zip) and the script will assume the title is the folder/file name and output is located where the script is but in a subfolder named after the title.

[lilman]

Originally Posted by badbob001

I'm pretty sure it's cropping a page that has a black background (see attached).

Is there a way to make auto_rotate not rotate a page if it is undersized? See the attached before.jpg and after.jpg.
The original size is 700x500. I have my device resolution set to 800x-1 so it should fit without change. But...

• It's black background got cropped.
• It got rotated.
• It got shrunken.
• The left and right sides got filled with a white background.

I'm not sure what really happened and why it got downsized. Perhaps it got downsized and then rotated?

I have another page that is 1103x803. Ideally, it would be rotated and shrunked to something like 800x1100. But it got rotated and shrunked to 587x803 and had borders added to the sides to create a final 800x803 image. I disabled borders and the image is still shrunken. Again no difference if I change max_dpi between -1, 167, and 72.

I've suspected that ImageMagick ignores the color I tell it to trim. I will play around with it and see if I can force it better.

I'm also thinking about writing my own trim algorithm. I already have some pixel interpretation code from the auto split landscape scans feature, but I'm pretty sure it wouldn't be able to handle as many input image formats as ImageMagick. I can always program it and see how it goes.

Originally Posted by badbob001

I really have no idea what is going on, but I see convert.exe using 8MB of ram and 2+GB of virtual memory. Now the harddrive is thrashing and it's very very slow, hence why I just left it running.

This a laptop has a Core 2 Due 2.26Ghz, 2GB ram and Windows XP. I'm going to increase the page file from 2GB to 3GB to see if that helps. How can I have canti skip the final PDF output step? What are the convert.exe parameters to create the final pdf from the processed images? I want to see if I can run convert.exe outside of canti but using the same parameters to see what happens.

To have Canti skip the final pdf output step, disable pdf output in the .properties file (pdf = false). Let's see, the ImageMagick command to create a pdf is something like:

convert *.jpg out.pdf

That should do it. Just open a command terminal within the image folder you want to make a pdf of and run that command (I'm assuming the image format is .jpg, if not change *.jpg to whatever format you are using).

Originally Posted by badbob001

In other news, I've made a batch file that makes it possible to invoke canti by dragging a folder or comic file onto a script file, avoiding the need to open a command prompt.

Open notepad, paste the following, and save as something like run.cmd in the canti folder.

@echo off
set parent_folder=%~1
set title=%~n1
set app_folder=%~dp0
set output_folder=%~dp0%~n1\

set parent_folder=%parent_folder:\=\\%
set output_folder=%output_folder:\=\\%

echo - Parameters ----------------
echo app_folder=%app_folder%
echo parent_folder=%parent_folder%
echo title=%title%
echo output_folder=%output_folder%
echo.
echo - To Run ----------------
set to_run=java -jar canti.jar -parent_folder "%parent_folder%" -title "%title%" -output_folder "%output_folder%"
echo %to_run%
echo.
pause
cd "%app_folder%"
%to_run%
pause

Then simply drag and drop a folder or comic file (eg: cbz, zip) and the script will assume the title is the folder/file name and output is located where the script is but in a subfolder named after the title.

Nice, thanks for sharing. I know some people don't like command line programs. Hopefully I will make a proper gui... eventually.

-Edit-
I think I fixed both the ImageMagick trimming non-white space and weird output sizes when specifying one dimensional resize. I pm'ed you the code and if all is fixed I will post the update.

[badbob001]

Here is an update of my drag-drop script for canti.

• Better error handling when nothing is dropped onto the script.
• Better support for paths and files names with non-alphanumeric characters like &.
• Can support UNC paths (eg: \\server\share) for input and canti itself.
• If canti.properties does not exist, will guide the user to create it.

It looks like if canti.jar is on a unc path, canti ignores the canti.properties file in the same location but looks for it in the user's profile folder. This applies as well when canti creates the properties files. I've resolved this by forcing canti to look in its current location with the -properties parameter.

@echo off
echo Script start...
set jar=canti.jar
set prop=canti.properties

if !%1!==!! goto:usage

set parent_folder=%1
set title="%~n1"
set current_folder="%~dp0"
set jar="%~dp0%jar%"
set prop="%~dp0%prop%"
set output_folder="%~dp0%~n1\"

set parent_folder=%parent_folder:\=\\%
set output_folder=%output_folder:\=\\%

:prop_check
if exist %prop% goto:prop_ok
echo - Setup ----------------
echo * Canti.Properties file does not exist. Please type in the device you have from the following list:
echo default, kdx, k2, ipad, nook, prs-900, prs-700, prs-600, prs-505, prs-500, prs-300, iliad, dr800, dr1000, jb, jbl
echo.
:prop_setup
set /p device=Your Device:
if !%device%!==!! goto:prop_setup
java -jar %jar% -create_properties %device%
if exist "%userprofile%\canti.properties" move /y "%userprofile%\canti.properties" %current_folder%
goto:prop_check

:prop_ok
set prop=%prop:\=\\%
echo - Parameters ----------------
echo * jar=%jar%
echo * prop=%prop%
echo * parent_folder=%parent_folder%
echo * title=%title%
echo * output_folder=%output_folder%
echo.
echo - To Run ----------------
set to_run=java -jar %jar% -properties %prop% -parent_folder %parent_folder% -title %title% -output_folder %output_folder%
echo %to_run%
echo.
pause
%to_run%
goto:end

:usage
echo * Usage: Drag folder or archive onto script.
goto:end

:end
echo ...Script end.
pause

[lilman]

Here's Canti v1.92a

New to version 1.92a:
-Bug fix: Auto trimming not working properly
The auto trim algorithm was only supposed to be trimming the white space around a scan, but if there was another dominant color on the outside of the scan (such as black) it would trim that instead.
Now instead of trimming a random color, auto trimming will trim whatever color you specify in @trim_color.
-Bug fix: Resizing only width or height would produce weird sized output
If you disabled either width or height resizing (so you set one of them to some integer > 0, and the other to -1) then the output images could come out at a size you didn't expect.
Resizing one dimension should work correctly now.
-Trim color
If you enabled auto trimming, this is the color that should be trimmed.
If you set this value to original, then the trimming algorithm will trim whatever color it encounters first.
Acceptable values: original, white, black, #[hex color code] (for example: #000000)
Recommended: white
This is set up in the .properties file.

Enjoy

[badbob001]

It seems that trying to match the resolution of the Kindle is a bit of a wasted effort due to the Kindle's PDF viewer lacking a full screen mode and forced margins. I wonder if the zero-margin hack + the mobi format would yield better results, but I think the mobi viewer will always scale an image to fit the screen.

[lilman]

Originally Posted by badbob001

It seems that trying to match the resolution of the Kindle is a bit of a wasted effort due to the Kindle's PDF viewer lacking a full screen mode and forced margins. I wonder if the zero-margin hack + the mobi format would yield better results, but I think the mobi viewer will always scale an image to fit the screen.

I hate that the Kindle pdf viewer doesn't offer a true fullscreen mode. An early verison of Canti gave you the option to either output to fullscreen (matching the specs of the screen) or pdf fullscreen (I don't even remember the specs for this, it was a little smaller to match the pixels lost from the pdf menu bars). Personally I think you should just go with the fullscreen specs of your device and let the pdf viewer handle the small downsize. From my experience with the first gen KDX, the pdf engine on the Kindle is fast so having to downsize at viewtime isn't a big deal. The difference in file size between true fullscreen vs pdf fullscreen is also negligible. Hopefully Amazon (or maybe a Kindle dev from this board) will make a change to the pdf viewer to allow for true fullscreen, and if/when this happens you won't have to worry about reprocessing your collection again if you stuck with the true fullscreen specs.

[jozicka]

I currently use

width = 750
height = 1000

so If I read in landscape mode, the fit size is very close to actual size, so the text is very readable (almost the same as if I choose actual size)

There is one think on K3 I do not understand, If I choose actual size, pressing next page puts me directly to next page, but If I leave default (fit page), pressing next page puts me to second half of the page.
So that is why I use this setting to use default setting.

[badbob001]

Not one canti configuration matches all my conversion needs and so I've updated my script to support multiple configuration files:

If Canti.properties is:

1. Found within the folder that is being sent to Canti, then that one will be used.
2. Found in the same folder level as the source folder or archive, then that one will be used.
3. Found where Canti is located, then that one will be used.
4. Not found, then user will be prompted to create one.

The above list is ordered so the first found properties file takes priority over the ones below. The following may be insulting to the intelligence of the forum members, but what the hell.

+-- Comic01.cbz
|
+- canti.properties [2]
|
+-+ Folder_of_Comics\
| |
| +-- Comic02.cbz
| |
| +-- Comic03.cbz
| |
| +-- canti.properties [1]
|
+-+ Canti_folder\
  |
  +-- canti.jar
  |
  +-- run.cmd
  |
  +-- canti.properties [3]

If Folder_of_Comics was dragged, canti.properties [1] would be used. If that didn't exist, then canti.properties [2] would be used.
If Comic01.cbz was dragged, canti.properties [2] would be used.
If Comic02.cbz was dragged, canti.properties [1] would be used.
If canti.properties [2] and [1] didn't exist, then canti.properties [3] would be used.

Other changes:

• Supported device list is no longer hard-coded and is extracted from the output of Canti.

@echo off
echo Script start...
set jar=canti.jar
set prop=Canti.properties

if !%1!==!! goto:usage

set parent_folder="%~1"
set title="%~n1"
set current_folder="%~dp0"
set jar="%~dp0%jar%"
set output_folder="%~dp0%~n1\"

:prop_check
if exist "%~1\%prop%" set prop="%~1\%prop%"& echo * Found Canti.properties in source subfolder& goto:prop_ok
if exist "%~1\..\%prop%" set prop="%~1\..\%prop%"& echo * Found Canti.properties in source folder& goto:prop_ok
if exist "%~dp0%prop%" set prop="%~dp0%prop%"& echo * Found Canti.properties in current folder& goto:prop_ok

echo - Setup ----------------
echo * Canti.Properties file does not exist. Please type in the device you have from the following list:
java -jar %jar% | find "Acceptable [device_name]"
echo.
:prop_setup
set /p device=Your Device: 
if !%device%!==!! goto:prop_setup
java -jar %jar% -create_properties %device%
if exist "%userprofile%\canti.properties" echo Moving canti.properties file to current folder& move /y "%userprofile%\canti.properties" %current_folder%
goto:prop_check

:prop_ok
set prop=%prop:\=\\%
set parent_folder=%parent_folder:\=\\%
set output_folder=%output_folder:\=\\%
echo - Parameters ----------------
echo * jar=%jar%
echo * prop=%prop%
echo * parent_folder=%parent_folder%
echo * title=%title%
echo * output_folder=%output_folder%
echo.
echo - To Run ----------------
set to_run=java -jar %jar% -properties %prop% -parent_folder %parent_folder% -title %title% -output_folder %output_folder%
echo %to_run%
echo.
pause
%to_run%
goto:end

:usage
echo * Usage: Drag a single folder or archive onto script.
goto:end

:end
echo ...Script end.
pause

Anyone actually using this?

[badbob001]

Originally Posted by jozicka

There is one think on K3 I do not understand, If I choose actual size, pressing next page puts me directly to next page, but If I leave default (fit page), pressing next page puts me to second half of the page.

In any zoomed mode, the page buttons will go to the next page and not pan to the next section of the document. If there was a way to control the zoom window with pixel-level perfection to crop out margins, then this page button behavior is good since it will maintain the same crop for all following pages.

The reality is that actual size (100%) blows up the image way too big and there should be an option to have the page buttons move the view window in a zigzag motion to scan all parts of the page. And to add to the confusion, when zooming, the zoom window doesn't accurately represent what is going to be displayed. There is also a bug in portrait where the zoom window on the first page is at about 66% of the screen while later pages has it at 25%.

Anyone figure out a PDF setting (resolution, dpi, etc) where Actual Size makes the page match the size of the display? Playing with the density and unit setting with convert.exe, a setting of 300 is close to the actual size but there are still scrollbars.

I also tried just copying the image files straight to the kindle and the images can be viewed fullscreen and the last accessed page is remembered. There is the occasional ghost artifact from previous pages and an annoyance with it saying it's full screen but the title bar is still there. I'm going to try this and if it's okay, I may go this route. I suppose I could had used mangle but canti supports splitting landscape pages (thanks!) and supports converting whole folders of content at a time. Mangle outputs to gif so I'm wondering if I may get better and cleaner results setting canti to gif as well (gif is cleaner than jpg for high contrast line-oriented images).

[badbob001]

It seems like there are some strange bugs when the output is set to GIF. And some minor bugs with landscape pages when border=true and rotate=false.

The following chart may help explain what is happening (I need to use my free time more wisely :


The input are a portrait and a landscape page from the web comic Octopus Pie. If you want to see the actual input and output images and properties files, see the attached zip.

It looks like some sort of extra black border is being applied to the GIF images to cause them to be bigger than the target size.

Another major thing is that the created GIFs are unreadable on my Kindle but are okay on my PC. When I simply ran "convert.exe 0000.png 0000.gif", that gif views fine on the Kindle so it must be some extra steps in Canti causing the problem. Progressive gif?

Another thing is that the generated xxxxx.manga_save file always specifies the filename extension as .PNG, despite the output in canti set for .JPG or .GIF. Is this expected? It seems to cause a strange bug on the Kindle where trying to view the gif makes it show the last screen saver image. Buffer overflow?