Quote:
Originally Posted by lilman
-[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.
|
Does this have anything to do with Color Balancing? In Windows app CDisplay, the Color Balance feature is described as such:
Quote:
The Colour Balance option applies a histographic colour balance to the image. In other words, it analyzes the image and spreads out the colours so that the lightest is white (255, 255, 255) and the darkest is black (0, 0, 0).
There is also a discards per 1000 value. This allows the specification of a number of 'pixel discards' per 1000 when producing the colour table. This allows you to stop the phenomenon of the odd bright white or jet black pixel from skewing the averages - these extreme valued pixels are simply discarded from the average calculation. Put simply, it allows a glint of white or fleck of black which is not part of the image to be discarded.
|
Quote:
Originally Posted by lilman
-[dropped] When using @auto_split_landscape_scans and @add_border, use split_buffer as horizontal border (user requested)
I think this cannot 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'm not sure how auto_split_buffer size relates with solid color borders. But it is a brain twister since you calculate the auto_split_buffer and split BEFORE your resize BUT only after you resize do you realize if the auto_split_buffer amount is too much (ie: top/bottom borders introduced due to split image being too wide). Would the following logic work to calculate how much buffer is needed?
Quote:
/* Resizing an image to a target size while maintaining the correct aspect ratio involves calculating two ratios and deciding which ratio gets us to the target size without going over: */
ratio1 = target_width/source_width
ratio2 = target_height/source_height
ratio1width = source_width * ratio1
ratio1height = source_height * ratio1
ratio2width = source_width * ratio2
ratio2height = source_height * ratio2
/* I'm ASSuming other test cases are not needed to be checked...  */
if (ratio1width <= target_width) and (ratio1height <= target_height) {
ratioToUse = ratio1
} else {
ratioToUse = ratio2
}
/* With the correct ratio found, we can calculate the width the source will be reduced to and determine the leftoverSpace of the target, which we can use to fill with background color. But instead, we will divide that number with the ratio to calculate the leftoverSpace of the source image. And that number is the auto_split_buffer amount to use (in pixels). */
leftoverSpace_target = target_width - (ratioToUse * source_width)
leftoverSpace_source = leftoverSpace_target / ratioToUse
bufferwidth = leftoverSpace_source
|
Example time:
I hope that made sense.