Varakari's Vision Log Tool for Windows, Test Version [Current: 0.1.3]

I’ve put together a program for measurement and logging, based on the personal tools I’ve been using. It contains explanation texts, a measurement target to help with finding the edge of blur, an input form for logging, and some basic plotting of the results.

It is designed for two main goals:

  • Making logs more precise and meaningful, to help with finding cause and effect
  • Creating a standard for sharing logs, comparing results, and statistical analysis

The target audience are people who are serious about improving, so as usual here, there is “some assembly required.” I hope that the explanations cover things well enough to get you going; please tell me if something is unclear or too difficult.

Since this DIY approach doesn’t satisfy the cultural ADHD of today’s Youtube or Facebook, I’m only sharing it with people of the proper mindset so far – like the kittehs of Le Meow. :smiley_cat:

Some screenshots:

This is a test release, so please don’t expect the program to be in a complete and polished state. There are things missing, and some parts aren’t very user friendly. I’m looking for enthusiasts who like trying something new and want to give input on how to improve this. I’d be happy if I could convince you to learn this measurement method and collect data, so we can test how it goes.

The download also includes a fairly recent version of my personal log.

This is a portable program, packed into a zip file. You only need to unpack it to any folder and start it. I haven’t included any installation, so it should leave your computer’s settings untouched. But check the disclaimer; for all legal concerns, please consider it “AS IS” software, where I don’t guarantee suitability for any purpose.


Keep backups of your logs! When switching to a new version, it’s a good idea to just keep the old log version around, to avoid any error breaking your data.

Click here to download the Vision Log Tool 0.1.3

Old version

Click here to download the Vision Log Tool 0.1.2.

Old version’s log formats will eventually become unsupported.


I checked it quick, two things come to my mind:

  1. It would be great if the text could be changed or at least the two text would be the same. It would be easier to realize when one of is blurred while the other is still clear.
  2. It would be good for some list where you can check back your previous entries. The Plot overview is great but there is a lot of information loss.

A bug:
On the new entry page it was 20:21 when I opened it. Before I saved it I pressed the “Now” button and it changed to 20:23. But after saving on the Plot Overview there is 20:21. I could reproduce it later with 20:27 - 20:29 times.

1 Like

What!! You hit a bug there pretty quickly, and a big one too! I found what’s going on; this is conditional on the order in which you input things. I’ll make a 0.1.1 shortly, with this bug removed.

On 1, in principle, I could just change both lines to read “FOCUS” … TBH, I’m not sure though, because the difference should be more obvious. I’m not sure if this works reliably if the difference from the color is so weak that identical letters are needed to spot it.

On 2., the list view for data: this is something I want to do; it’s a matter of workload right now, since I’m not too used to WPF, and so I’m slow at implementing these things. Definitely on the list of things to do if more people start using this.

For now, I know it’s not super user friendly, but if you need to it’s not too hard to edit the log file with a text editor. I’ll try to have a look at how to make a list view when I have the time, but for now, I’m moving and the IOL Master is damaged, so it’ll have to wait.

You discovered a major bug! How would you like to be credited, is using your full name (Dávid Halmágyi) okay? I don’t have credits page yet, but that’s also on the list of things to add soon.


Download and unzipped fine.
Does the background colour have to be bright? I’d prefer a dark skin like endmyopia has.


On the focus reach test, it has to be, because this is supposed to be as standardized as possible. So this view is forced to white background.

I thought that other views might respect the app theme set in Windows, but after checking it, this doesn’t seem to be the case. Even though it looks different on different versions of Windows. Microsoft being weird again… not sure if there’s a simple switch to make this happen, or if I’d have to implement my own color scheme for everything to allow setting this. :thinking:

Version Update: 0.1.1

  • Fixed a bug where an outdated time for an entry gets committed if the controls are used in a certain order and time passes in between. Credit to @halmadavid for finding this.
  • The focus reach target has been updated to read “FOCUS” in both red and green, as per @halmadavid’s suggestion.
  • Added a credits page, to honor testers for fixes like this one. (I used the full name from here for now; please tell me if you’d rather be pseudonymous.)

After looking at the red and green both reading FOCUS, I figured that the effect of just the perceived distance changing is cool anyway, and there’s no downside really, so I changed it after all. :cowboy_hat_face:

I edited the download link in the original post to avoid linking to old versions in this thread; please get the new version there.


Will have to install bootcamp again and find a copy of Windows and give this a go!

You’re a wizard, @Varakari. First the axial change experiment, now this.


Thanks :slight_smile: One of my responsibility at workplace is to test and approve our external programmer’s work, so I have an eye for these kind of things :smiley: And yeah, full name is fine.

1 Like

I added a backup server for downloading, since there seems to be an issue with the main server. Sorry about that, I don’t know when it went down.

BTW, if you start an actual log with this, please keep me posted! It’s helps a lot to get a feeling of how things are used in real-world conditions.

This is great, thank you so much for sharing! I particularly like that this tool has a standardised target to test with.

I have a couple of questions - I guess they’re relevant to any measurement technique but I’m curious as to your take on them:

  1. How do you define the blur horizon that you are measuring? I know that all we really care about is consistency because we’re looking to measure change over time, but I find it hard to keep a mental model of what exactly it is that I mean by “blur”. When I move my head back and forth in front of a target, I notice incremental changes to the sharpness of the text. To start with, they’re not really what I’d call blur - more than the text starts to subtly change. There’s a point where I’d say “this looks blurry now” but it’s probably 5cm or so from where I think there’s some sort of very subtle change. The range is sufficiently large that it makes me worry that I’ll be paying attention to slightly different cues each time I take a measurement. I wish there was some more objective way of defining the measurement point! Any thoughts?

  2. What’s the easiest point you find to measure from to the screen? I mean do you run a tape measure to the end of your nose? To your eyeball (ouch)? Obviously once again it’s mostly about finding a good consistent point - just curious what you’ve found works best.

Final question - not really related to the above - what did you develop this in?

Thanks again for making this available to us!


Thank you for the feedback and the important questions!

  1. The precision is never perfect, focus reach fluctuates, and I think it’s most important to accept that and keep measuring. This is really something I should address in the explanations. Also, you don’t need to use the very first bit of error if it might not be from myopia. The right distance is where red is still clear, but green shows a little bit of fuzziness in multiple directions. (Too much remaining cylinder error messes with this and requires different measurement glasses.) I use my memory of past blur and the moving average feature to deal with it. (Another thing I still have to explain.) There are approaches to improve relative precision, but they come with their own issues. I simply do the best I can in a minute or two about twice a week, which works surprisingly well in the long run.

  2. How exactly to measure centimeters is also an important point I forgot to write about! I try to measure on the side of my head, using my fingers to pinch the measuring tape at an orthogonal angle, slightly touching my eye socket from the side. Then I read the centimeters I pinched with my fingers. I try to get the distance to my cornea, which is the physically meaningful value. Now that I think about it, this isn’t obvious when starting out; I’ve been logging this way for so long that these details slipped my mind.

The back-end of all my analysis is written in F#, using an XML logging format and an XSD schema to define it. The user interface is written in WPF (XAML/C#). To be honest, the reason I only support Windows right now is that I can’t find the tools to make decent user interfaces for cross-platform or web in reasonable time.

This is valuable input about missing explanations! Is it okay if I credit you as a tester?


There are cross platform GUIs for .NET (which is crossplatform if you use .NET Core), like this: Though I’m not sure if implementing it is “reasonable time” or not :slight_smile:
On the other hand on the long run I think the best would be a web based application, because people don’t need to download and install it, and it’s much-much easier to make sure everyone uses the same version. And it would be also a great thing to have a lot of records at one place for analysis. Though there could be legal things (and complications) here, because of storing medical information, etc.

Definitely include this. Maybe you should also start a topic here on the forum, because it could be an interesting discussion. I measure my eyes totally different and I have always struggled with it, your method sounds much better :slight_smile:


Thanks for the explanations of your measuring technique. What you say about defining blur makes a lot of sense, I will try to focus (no pun intended) on the concept of “a little bit of fuzziness in multiple directions”.

I see now from your screenshot that the tool calculates a moving average (when there’s enough data points to do so?). That will definitely help with day to day variation in readings. How long is the averaging period btw? Is it a linear average or weighted?

I wish there was a more objective way to define the blur point, but it’s obviously hard when you’re talking about evaluating a perception. It’s all subjective in the end! If only we all had a means of measuring axial length…

I don’t feel like I’ve made enough of a contribution to deserve a credit!

1 Like

This looks really promising! Since the technology is so similar, it could become possible to migrate, and then we’d get the other desktop/laptop platforms. I’ll keep an eye on the Avalonia UI project!

I added a bit of explanation about how to use measuring tape that’ll be in the next version. I’ll see if I can find the time to start a more detailed thread about it, though right now, my schedule is packed because I’m about to move, and I want to carefully consider all feedback about the program.

BTW, talking about schedule: good news! I got a repair offer for the IOL Master that claims to fix it in two weeks!


It’s an exponential moving average (EMA) that weights each new sample with 6% into its new state. The initialization is weird, so as you guessed, it only appears after you collected enough data.

This is on the list of things I didn’t write an explanation for yet, because even at two measurements a week, it takes months before this appears. I find it useful to remind myself not to lose sight of the bigger picture.

It’s not just a subjective fluctuation. If I measure axial length right after getting up, it’s off by about as much as focus reach fluctuates. For actual refraction, the tear film and ciliary body don’t have a constant state either. I think we have to live with the fact that it takes a while to confirm long-term changes in myopia, because the eye isn’t static.

You found not just one, but two critical omissions in the instructions for the most important measurement process! Imagine just five people who make 200 focus reach entries each, measuring both eyes every time. Even with such conservative numbers, that’s two thousand times someone has to pick an edge of blur and use measurement tape to determine the distance. This is a process worth optimizing, and without this kind of feedback, I would have no idea what parts are the bottleneck.

Yes, and this connection between axial length and focus reach is absolutely fascinating. I hope you get your IOM fixed soon because I’m dying to see where your measurements go as you progress!

1 Like

Version 0.1.2

This version introduces a UI to log acuity tests and updates the log format.

Please update to ensure compatibility of your log with future versions.

How to update

  • Download the new version of the Vision Log Tool (updated link in the first post of this thread).
  • Find your logs in the old version’s “userdata” folder.
  • Backup your log, in case something goes wrong.
  • Copy your log to the “logs” folder of the new version.
  • As soon as you add an entry to your log, the log’s format will be automatically updated.

From this version onward, nonstandard log content (anything that differs from the specifications in visionlog-0.1.1.xsd) is not allowed and will be removed when the program writes to a log. This is to ensure that we can automatically operate on logs in the future and don’t have to worry about breaking anything.



  • Added user interface for inputting acuity tests (e.g. for optometry prescriptions).
  • Changed the folder where logs are located from userdata to logs.


  • Changed explanation for finding the edge of blur; thanks @carljannson for discussing this. This turned out a little different than discussed before; see also the comment below. (Also thanks to a contributor whom I still have to ask for permission to credit.)
  • Changed explanation for the process of using measurement tape to determine the distance between cornea and screen, also thanks to @carljannson for the feedback.

Format and log handling update (visionlog.xsd 0.1.1)

  • Added formatVersion attribute to logs; this is optional now but intended to become mandatory later.
  • Changed how acuity test results are represented, now two attributes: acuityType and acuityResult.
  • Deprecated the logMAR attribute on acuity tests. This is superseded by acuityType=“LogMAR” and will become invalid in future versions.
  • Added acuity result types: decimal, imperial Snellen (20 feet), metric Snellen (6 meters).
  • Added the ability to mark acuity tests as conducted by experts, under high-quality conditions, to high acuity.
  • Implemented automatic conversion of unversioned logs to the visionlog.xsd 0.1.1 format.
  • Logs are now completely recreated on changes, as the program now converts to and from an internal representation.


  • Refraction plotting only shows acuity tests marked as expert tests.
  • Added labels to vertical axes and slightly simplified the legend.


Finding the edge of blur with undercorrected cylinder error

Sorry @carljannson for the back-and-forth, this was my mistake. The former idea to define the edge of blur as only the point where blur in all directions appears would have been inconsistent with the use of spherical equivalent, which counts cylinder error half as much as spherical error. So if there’s visible astigmatism left, the proper way is to find the edge of blur for one direction and all directions, then take the middle in terms of diopters – but given a proper measurement setup, the middle in terms of distance should be very close to that, so that should be a good approximation.

Update of my personal log

The IOL Master is repaired, and I’m getting back to measuring axial length! I measured on another device for comparison, and it was off a bit, but systematically on both eyes. I hope that this is just an offset, and not a more complicated error. Also, my left eye doesn’t seem to have taken a recent reduction as well as the right, so I reverted my distance glasses to -2.5 for now.

My updated log comes with the 0.1.2 release. As usual, you can find the current download link in the first post of this thread!


Very cool! Glad you got the IOL Master repaired, too.

1 Like

This is very cool and I’m looking forward to trying it out. My main limitation on using it at a regular basis is that I use Linux as my daily driver. I’ll have to see if it works under Wine.


Same here. Let me know if you manage to make it work, I tried but it won’t start. :cry:

1 Like