View Single Post
Old 10-19-2010, 09:13 AM   #112
lilman
Addict
lilman has learned how to read e-bookslilman has learned how to read e-bookslilman has learned how to read e-bookslilman has learned how to read e-bookslilman has learned how to read e-bookslilman has learned how to read e-bookslilman has learned how to read e-bookslilman has learned how to read e-books
 
lilman's Avatar
 
Posts: 326
Karma: 960
Join Date: Jul 2009
Location: Florida, US
Device: Kindle DX, iPad
Quote:
Originally Posted by badbob001 View Post
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.
Depends on the options you set. The main image processing (resize, adjust dpi, change image format, etc.) is done in one command. If you enabled trimming then that is done in a separate command right before the main processing, but the trimming is performed using the same image format as the input image. Since trimming is merely an intelligent crop, I think there should be no quality loss even for lossy formats like .jpg. Auto splitting landscape pages (which is done before trimming) also boils down to an intelligent crop command, so again no quality loss. There is also a preprocessing step that uses the same image format as the original image. It overwrites the original image, and merely attempts to fix any erroneous data in the image... no real processing is done, so there shouldn't be any quality loss.

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:
Originally Posted by badbob001 View Post
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.
@auto_split_buffer is the % of the other split page to include with the current split page. So if you set it to 1.0, then 100% of the other split page will be included in the current split page (i.e. you will get the original unsplit image, but you'll get it twice since each split page will include the entire other split page).

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).
lilman is offline   Reply With Quote