• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Cropping since Version 2.8.7.
#1
Windows Version v10.0.18362.592
MobileSheets v2.8.7 from Windows Store
Device: h8-1425eg


Hallo MIke,

Neither automatic, nor agressive cropping work correctly since Version 2.8.7.
Automatic cropping does not cropp as precise, as it used to all and agressive cropping cuts at least one staff away. 

When trying to manually cropp the pages, pressing the "next page" button causes the App to crash.
Is this a bug?

Thank you very much and many greetings,

el-Odysseas
electricOdysseas

Windows 11
Android
MobileSheetsPro
Reply
#2
It works for me, at least with songs that are already in my library
MSP 2.8.7
Win 10 1903 Build 18362.592
first language: German
Acer A1-830, Android 4.4.2 - HP x2 210 G2 Detachable, Win 10 22H2 - Huawei Media Pad T5, Android 8.0 - Boox Tab Ultra C, Android 11
www.moonlightcrisis.de - www.basdjo.de - www.frankenbaend.de


Reply
#3
To my oppinion auto cropping does not work correct anymore (see pictures attached)!
But I cannot confirm the crash.


Attached Files Thumbnail(s)
       
---------------------------------------------------------
13" - Point of View POV_TAB-P1325, Android 4.1.1
13" - Point of View POV_TAB-I1345, Android 5.1.1
Microsoft Surface Pro 4; Windows 10
Phone: Motorola Moto G3, Android 6.0
Reply
#4
(01-19-2020, 08:36 PM)itsme Wrote: It works for me, at least with songs that are already in my library
MSP 2.8.7
Win 10 1903 Build 18362.592

And how about the crashing? 
Pick a file with more than one pages, select manual cropping, edit, then press next page (to proceed to the next page that you want to manually crop).
electricOdysseas

Windows 11
Android
MobileSheetsPro
Reply
#5
(01-20-2020, 12:27 AM)Vibraphon Wrote: To my oppinion auto cropping does not work correct anymore (see pictures attached)!
But I cannot confirm the crash.
Thanks for the respond!

About the auto cropping, this is exactly what happens here also!

To reproduce the crash:
Did you pick a file with more than one pages?,
I select manual cropping, edit, then press next page (to proceed to the next page that I want to manually crop) and the App crashes.

electricOdysseas

Windows 11
Android
MobileSheetsPro
Reply
#6
(01-20-2020, 12:38 AM)el-Odysseas Wrote:
(01-19-2020, 08:36 PM)itsme Wrote: It works for me, at least with songs that are already in my library
MSP 2.8.7
Win 10 1903 Build 18362.592

And how about the crashing? 
Pick a file with more than one pages, select manual cropping, edit, then press next page (to proceed to the next page that you want to manually crop).
What do you mean with "select manual cropping"? On the import dialogs there's a check box "Automatically crop pages", when I click on a song and select the icon bottom left there's a menu entry "Crop", in the crop dialog there's "Auto-Crop". The behaviour is as always, just the look of the movable cropping lines has changed. I can use it without issues. No matter if I change the cropping or not, also on multi-page songs.
It might be helpful for Mike to describe your workflow that leads to the crash step by step in detail.
first language: German
Acer A1-830, Android 4.4.2 - HP x2 210 G2 Detachable, Win 10 22H2 - Huawei Media Pad T5, Android 8.0 - Boox Tab Ultra C, Android 11
www.moonlightcrisis.de - www.basdjo.de - www.frankenbaend.de


Reply
#7
There is indeed a bug with the cropping editor when switching pages. A user notified me of the bug yesterday and I submitted an update to Microsoft immediately to fix it. Microsoft doesn't process updates over the weekend, so the earliest it can be available is tomorrow morning if they approve it right away. The FastSpring version has already been updated so for users that have purchased through my store, they already have the update.

I have not changed any of the logic for automatic cropping between version 2.8.6 and 2.8.7. When I test automatic cropping, it seems to work just fine for me. Vibraphon - in both of the images you provided, they look like they have dark pixels around the page. Those will stop the cropping from going any further. I've attached an example of how the automatic cropping looks for me on one of my test files. Seems like it crops as much as it can.

Several updates ago (version 2.8.2) I modified the automatic cropping logic so that it properly processes colors on pages. Before, it would just ignore pixels that should have been considered. If both of you went from 2.8.1 to version 2.8.7, then we can certainly discuss these changes, but otherwise, no other changes have been made to the automatic cropping. 

Mike


Attached Files Thumbnail(s)
   
Reply
#8
(01-20-2020, 03:29 AM)Zubersoft Wrote: Several updates ago (version 2.8.2) I modified the automatic cropping logic so that it properly processes colors on pages. Before, it would just ignore pixels that should have been considered. If both of you went from 2.8.1 to version 2.8.7, then we can certainly discuss these changes, but otherwise, no other changes have been made to the automatic cropping. 

Mike

Hallo Mike,

Thanks for the upcoming update and the bug-fix!
 
About the "sensitivity" of the Auto-Crop, I think that it should not be very high, since a scanned  document very often creates these dark pixels you mentioned.
I guess the possibility to set the sensitivity would be great.

I also provide you an example of how an original file (left) is being processed with the Auto-Crop (middle) and the Agressive-Auto-Crop (right) function.
As you can see the black, lined pixels on the bottom, prevent the App from cropping at all (too sensitive), and the agressive cropping is cutting half of the page away (too agressive).


Attached Files Thumbnail(s)
   
electricOdysseas

Windows 11
Android
MobileSheetsPro
Reply
#9
There isn't really an easy option for "sensitivity", because you have to think about what that means in regards to an algorithm that is scanning pixel by pixel trying to determine how much of the document it should cut off. Right now, this is the aggressive cropping algorithm:

1) Go to each side of the page and try to find the a line of white pixels along the entire extent of that side, going from the outward edge inwards. Stop the second you find a line of all white pixels. If none are found, use the line with the highest number of all white pixels

2) Now starting at the lines calculated in #1, work inward and try to find (on each side) a block of "significant" pixels. A pixel is considered significant if it is "dark enough" and each side of it has pixels that are also dark enough (below a certain threshold in terms of their RGB value). Find the block of significant pixels that is the furthest outward (i.e. closest to the beginning lines). 

3) Use the four points determined in #2 to define the rectangle of the cropped region.

So what does "sensitivity" mean when you think about the existing algorithm? Does it modify how dark or light the pixels have to be in ordered to be deemed "significant"? Does it require more than just a 3x3 block pixels and instead require 5x5 or 7x7 (where a certain number of those pixels are dark)? It obviously wouldn't make sense to need an entire 5x5 block of pixels to be dark content, as that wouldn't be encountered unless it was a just block of ink on the original document. 

If you are aware of existing algorithms for determining crop points accurately and ignoring scan marks near the edges, let me know. I can try making some adjustments to the current algorithm but I don't know if it will address your concerns.

If you are wanting to know why your document was cropped the way it was, it's because the algorithm saw that black line down the side as it was trying to find the cropping point for the top of the document, so it went pretty far down the page before picking the starting point, most likely because the pixels on the side of the page may have been slightly thinner there. So an adjustment I can make is to find the left/right coordinates first, then the top/bottom would only iterate between the left/right calculated positions, which would help in ignoring scan lines on the side.

Mike

UPDATE:

With the adjustment I described, the page you posted is cropped is correctly el-Odysseas (I reproduced what was shown in your screenshot before that). So I will include this change with the next update which may address some of your concerns.
Reply
#10
Hello,

I'm using Version 2.8.8 in Windows 10 (1903) -Environment on a Microsoft Book 2 and a Teclast X6. The errors with cropping occour on both tablets as decribed in this thread, most with new imported PDF-Files having more than one page. While changing to the second page, the program hangs (autocrop is turned off). In addition the eight resize-markers are not displayed on the border of the first page. There is no chance to resize the page manually.

Sometimes, but not with all PDF-Files, the autocrop-feature works in such circumstances and crops alls pages (selected mode is: all pages in file). The resize-markers are displayed. Now it is possibile to manually crop the page and the <next page> function works too. Same with older files which stay longer in the library. In such case, an other error will occour, by sizing the right border to maximum right. Mobile sheets crashes and the programm is exited soon.
Reply
#11
Version 2.8.9 is available in the Microsoft Store (it was released on Friday) that has additional error checking and handling for the cropping editor. That should resolve the crashes you are seeing. Please update to that version and let me know if you are still encountering the issue where you can't resize a page, please let me know.

Thanks,
Mike
Reply
#12
Hello Mike,

updating to Version 2.8.9 solved the problems. Thank you for your support and last not least for your great product! Smile 

Best regards
Gerhard
Reply




Users browsing this thread:
2 Guest(s)


  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2024 MyBB Group.