[Feature Request] Custom Margin

[azuretower]

I'm trying to convert a comic that uses speech bubbles that are open to the edge of the page (Invincible if you want to take a look). That means that when they are on the top or bottom of the page the letters are the first/final pixel of the image which makes a bit hard to read.

I thought that Cropping Power would adjust that but it looks like it doesn't. I ran the conversion with power .05 and with power 3 and both produced the same result.

Could you add a setting to retain (or add back) a custom amount of margin to the top and bottom to help alleviate this? Maybe measured in pixels or something.

[axu2]

Does the old cropping method give the same result? The old cropping method was still in KCC 6.3.1

[azuretower]

I tested with 6.3.1 just now and I think it's a bit better, it left a few extra lines of white margin. But it seems like a useful feature to have the option for custom margins. I would still have added an extra 5-10px if it was up to me. I'm not super sure what resolution i'm working with here. but a bit more would be nice for this series.

[axu2]

Are you doing partially checked or fully checked? send full settings screenshot

@neyney10 in case this interests you.

[azuretower]

I was full checked, margins and page numbers. I just ran it half checked, just margins, and it produced the same result. The words are right against the edge of the image.

Here is a page to see how speech bubbles work pretty often.

[distample]

Yes, it would be nice to combine the small white margins left after cropping from KCC 6.3.1 with the cool page number cropping from KCC 7+

[neyney10]

I tested with 6.3.1 just now and I think it's a bit better, it left a few extra lines of white margin. But it seems like a useful feature to have the option for custom margins. I would still have added an extra 5-10px if it was up to me. I'm not super sure what resolution i'm working with here. but a bit more would be nice for this series.

The newer cropping algorithm crops more tightly around the main content and hence results in a tighter image (relative to the screen edges).

I see two options:

1. Integrating it into the cropping method gives us a cleaner final image, as the crop won't remove unnecessary details from the page when using high power levels as it "undos" part of the cropping to leave a margin. The issue is that it might "undo" the removal of the "page number" as it just crops less and might leave the page number. Also, if there is not enough crop to undo, it will add blank margins (black / white).
2. Simply add margins (black / white) after cropping. This is the simplest and easiest solution.

Would it be better to let the user define the desired margins in

1. Number of pixels (after image resize to fit the desired screen/size)? To allow easier control with a bar (like in cropping power) we might need to use steps of 3px, 5px, or 10px, with some limit.
2. In % of the screen/output size?
3. In % of the image size? - this might lead to some issues as different sources have different image sizes and might result in different / nonconsistent margin sizes between mangas/sources.

[azuretower]

I would vote for number of pixels. You already have UI precedence for input boxes when the user selects the “other” device type, you could go with that.

I’d also suggest different top and bottom pixel counts. I’d love to use the “progress bar” feature of Kobo devices without it covering up some of the image at the bottom.

[axu2]

Also, if there is not enough crop to undo, it will add blank margins

If you decide to go this way, you could just not add extra margin in those cases

[neyney10]

[@azuretower] I would vote for number of pixels. You already have UI precedence for input boxes when the user selects the “other” device type, you could go with that.

I’d also suggest different top and bottom pixel counts. I’d love to use the “progress bar” feature of Kobo devices without it covering up some of the image at the bottom.

I'm not sure I understand what you mean by "UI precedence for input boxes".

Different sizes for each margin seem like a good idea (maybe including also left & right margins?).
Although I feel like using pixels as unit of margin size is less intuitive, it's easier to imagine how the final result would look on the device using % of the screen (like, 1% margin per side) rather than pixels.

Maybe we can combine the two and set a toggle to swap between pixel units and % units.

[@axu2] If you decide to go this way, you could just not add extra margin in those cases

The reason I add this is because what if the image is already cropped and there is nothing more to crop? and hence the algorithm would crop zero pixels. In such a scenario it doesn't have any crop to "undo", and to make sure that there are X pixels of margin, it has to add them anew.

[azuretower]

All I meant was that KCC has used input boxes before, so it doesn't HAVE to be sliders. But percent could work just fine, I see what you're saying.