Quote:
Originally Posted by hupple
I have tried -auto-gamma. -auto-level and -contrast. I agree that auto-gamma doesn't work well. But auto-level is better.
|
Quote:
Originally Posted by badbob001
I think auto-level may be closer to what is described as color balancing.
|
All my digital scans are manga so I don't have a good testbed for color correction testing. But since you both recommend auto-level I will include it in the next update.
Quote:
Originally Posted by badbob001
I understand. ImageMagick is an external app and you can't predict its output. The only thing you could do is let Convert process the image, analyze the result, and re-do the process. Too bad convert doesn't have a test mode so you can just see what it's going to do.
|
Predicting the resize is easy, but predicting the amount of trim isn't possible. Writing my own trim algorithm wouldn't be too difficult since I already developed the necessary base code for analyzing images when I wrote the auto_split_landscape_scans feature, but I'm not sure Java can handle as many input image types as ImageMagick. Not being able to use the split_buffer as a border isn't that big of a loss anyway.
I kind of want to write my own image handling library and cut ImageMagick out completely. Oh well, a project for another time.
Quote:
Originally Posted by badbob001
|
Nice find. I was only using "-repage -1-1!" to account for adding a 1px border of the desired trim color, but since that 1px border gets trimmed anyway, using +repage will readjust the canvas size data for both the 1px border and the trimmed space from the original image. .gif issue should now be fixed, although from what I've been reading lately .png is a better alternative than .gif.