Stmated

Hello there. I hope this is in the right place. Couldn't really see a subforum geared towards sourcecode questions. Anyway: I've been rewriting some of the code for PDN for my own personal project, that will specialize in helping to scan, translate and edit comicbooks to work easier and faster without having to switch between as many applications, and whatnot. I am currently working on the scanning, and with it I will have quick crop and align features. The crop should work almost identical to http://hem.bredband.net/pnyxtr/cropping/crop.html. If you get the time to test it, you'll see that it plays around a whole deal with the scales, having different scales horizontally and vertically. Now I'm trying to write a Tool that will behave just as that other application. But as you probably already figured out, all scaling in PDN is done by the ScaleFactor's ratio, so it's impossible to tell it to just modify one axis. Since the different ratios are transmitted to other factors over the whole code; the set modifier value doesn't stick to later created factors and give rather random results. Or maybe I'm wrong about that and I'm just st0pid. I did however figure out one way to do it which works 50%. To override OnSizeChanged() for the SurfaceBox class, and in it write the multiplication of the original sent in values, hence change the size again, and add check to avoid an endless call loop. This code here below works just fine for scaling the image to always see the whole vertical axis, and zoom in on the horizontal axis: private bool ignore; protected override void OnSizeChanged(EventArgs e) { if ( !ignore ) { ignore = true; // [...] Get the active DocumentWorkspace and put as variable "doc". Size = new Size(doc.Panel.Width, surface.Height * 3); // [...] Own call to make the control refresh and layout ignore = false; } base.OnSizeChanged(e); } However, it does not work to simply exchange that code line with: Size = new Size(surface.Width * 3, doc.Panel.Height); So I can't do the same thing when I want to focus on the left- or right-side instead of top or bottom. Instead the only thing it does is to scale the zoom to 100% and the SurfaceBox clips the height so it is no longer vertically scrollable, and the width stays 100% and is not multiplied as told to be. And no matter what I do I can't seem to figure out what causes this, or any way to circumvent. Anyway. If someone here is knowledgeable enough about the code: What would I have to change to be able to modify X and Y differently for image resizing? If not possible, it's not that big of a deal, though. Just something that has been on my mind and a feature I quite like when cropping many pages quickly. I'm not afraid to fork the code a whole lot, either. That, I've already done so much already. I have tried the code both for my own, much changed, version, and a clean one of the latest version. I hope this makes any sense, and that you can help me; or I will have to resort to showing the image to fit the window and display moveable guides for where to crop. Very big thanks in advance.

The "algorithm" used is to debind the book from its spine and scan each separate page, instead of pushing the book onto the scanning surface. As far as I know there is no way that really works to get rid of 'gutters' (as this deformation is called). The best way of doing it, however, is to add leveling that increases in strength further along the page, manually. There is no way for the algorithm of really knowing how to level automagically only to get rid of the gutter and not ruin the rest of the image, since the decrease of light further along the sides might even be intentional, for example if it's a photo of some kind and not a scanned book page. The algorithm would need to be specific for books.