I'd be interested in the original screenshots if you have problems. They are kept in the archive folder at your program save location, there is a settings menu item where you can check the folder location. If you have resolution-dependent problems, please also tell me what the screen resolution is, the screenshots will be always be pruned to settings values.
I'd be interested to find out why the program is working so badly on the 1080 screen of user ChaosCloud. That may be a screen setting I don't know yet. The program currently does work for me, and reliably, so I'd be particularly interested on the 1080 screenshots that didnt work.
I'm less interested in the scaling issues because I can't reliably develop for resolutions I can't test with. Some things that come to mind would be:
This kind of thing always depends on how the display is scaled up as the amount of on-screen space increases. You can either put in more text, or make the font larger / change line spacing, or you can do a mix of both. That is something I obviously can't test or prepare for since I have one screen available and thats it. For that reason, I'm treating line spacing / character spacing / table gaps as PIXEL dimensions. You can toy around with the settings for those in ExplOCR.exe.config, but possibly I can figure out the values for you if supplied me with a suitable screenshot. However, since DPI / font size is likely changed, there would be shrinking involved and I can't implement that currently.
(Shrinking is currently out of the question because I'd need a much larger sample to train the neural nets if I also have to worry about letters which look different becauseof interpolation artifacts caused by shrinking. That is something I'd have to redo if they change the font rendering again as in 2.0/1.5. Commas often come out looking like dots in magnified views, and this will likely get worse when shrinking. Since we have commas and dots fighting for dominance in the numerical values, this is no easy matter.)
Overall, I am not thrilled by how the program performs on the scaled-down screenshot sample. The font size related problems seem fixed, the letters are nice and green. However, you are missing entire lines. Line spacing has changed for 2.1/1.6, and this seems to be not quite uniform as screen size (and possibly DPI) changes: If it were scaled the same way as the font, the values from the config files should let you lock onto all text lines of the scaled down screenshot. Something is wrong with the way lines are spaced, and I would have to guess wildly what it is. This part of the problem is more interesting to me than the scaling itself (-> screenshot please).
In the past, scaling up to ultra-wide 1200 screens worked well once people adjusted the ScreenshotX, ScreenshotY, ScreenshotW, ScreenshotH settings in ExplOCR.exe.config -- note that I have set height 1200 there, which will work for both 1080 and 1200. Shrinking the images for high-resolution monitors also used to work, but you'd have to import files individually which is too much of a hassle. I can't develop software on screens I don't own, partly because the next layout change will break it all again.
TLE
I'd be interested to find out why the program is working so badly on the 1080 screen of user ChaosCloud. That may be a screen setting I don't know yet. The program currently does work for me, and reliably, so I'd be particularly interested on the 1080 screenshots that didnt work.
I'm less interested in the scaling issues because I can't reliably develop for resolutions I can't test with. Some things that come to mind would be:
This kind of thing always depends on how the display is scaled up as the amount of on-screen space increases. You can either put in more text, or make the font larger / change line spacing, or you can do a mix of both. That is something I obviously can't test or prepare for since I have one screen available and thats it. For that reason, I'm treating line spacing / character spacing / table gaps as PIXEL dimensions. You can toy around with the settings for those in ExplOCR.exe.config, but possibly I can figure out the values for you if supplied me with a suitable screenshot. However, since DPI / font size is likely changed, there would be shrinking involved and I can't implement that currently.
(Shrinking is currently out of the question because I'd need a much larger sample to train the neural nets if I also have to worry about letters which look different becauseof interpolation artifacts caused by shrinking. That is something I'd have to redo if they change the font rendering again as in 2.0/1.5. Commas often come out looking like dots in magnified views, and this will likely get worse when shrinking. Since we have commas and dots fighting for dominance in the numerical values, this is no easy matter.)
Overall, I am not thrilled by how the program performs on the scaled-down screenshot sample. The font size related problems seem fixed, the letters are nice and green. However, you are missing entire lines. Line spacing has changed for 2.1/1.6, and this seems to be not quite uniform as screen size (and possibly DPI) changes: If it were scaled the same way as the font, the values from the config files should let you lock onto all text lines of the scaled down screenshot. Something is wrong with the way lines are spaced, and I would have to guess wildly what it is. This part of the problem is more interesting to me than the scaling itself (-> screenshot please).
In the past, scaling up to ultra-wide 1200 screens worked well once people adjusted the ScreenshotX, ScreenshotY, ScreenshotW, ScreenshotH settings in ExplOCR.exe.config -- note that I have set height 1200 there, which will work for both 1080 and 1200. Shrinking the images for high-resolution monitors also used to work, but you'd have to import files individually which is too much of a hassle. I can't develop software on screens I don't own, partly because the next layout change will break it all again.
TLE
Previous poster, hat my utility does is basically: Transform the cwelestial body data table view into ASCII text, with a bit of an UI.