Gauging Interest and Input: Software Tool Development and a Data Format for Vision Logs

Maybe some of you remember the graphs I’ve been posting from time to time, or cryptic remarks about working on a data format for vision logging. This thread aims to explain these things and gauge interest in a version of these tools that everyone can use.

In case I haven’t spammed them often enough yet (:stuck_out_tongue:), here’s the kind of plot I’m talking about; this one shows my left eye’s spherical equivalent diopters over time (and that winter fail :sweat_drops:):

These are made from a custom log format and software I’ve written, using libraries with permissive or otherwise unproblematic licenses, so that I can share both the program and its results freely. Right now, the software is not really suitable for most people to use, because it requires some technical actions, like typing XML by hand. But if there is enough interest, I could improve its usability to a point where I could share it on this forum.

I’d like to discuss three spotlights on this topic; let’s start with the most relevant one for reusability:

Draft for a Windows UI

So, adding to the log could use some more user-friendliness. I’ve been drafting how an input form could look:

VisionlogUIDraft-2019-05-23-Meow
See how it already color-marks the fields that don’t have proper data. Praise mah mad WPF skillz!!!111 :nerd_face:

The “Comments or Diary” and “Advanced Items” on the bottom would be expandable, where the first allows to add any text to the entry, while the second would allow inputs for more involved types of measurement, like axial length, autorefractor or keratometer results, or acuity tests à la optometry prescriptions.

Unfolded comment/diary section:

VisionlogUIDraft-2019-05-23-Meow-Diaryunfold

Would any of you be interested in using something like this? I’m interested in any thoughts.

Focus Range Target Image Design

This topic has already come up in my troubleshooting-turned-tech-orgy thread: many people are lacking a standard image to look at for centimeter measurements.

In search of something better than the messy test image I currently use, I started toying with the longitudinal chromatic aberration of our eyes. Have a look at this:

focustest-chroma-visionlogtool

If you’re being a good kitteh and using some form of computer glasses / Differentials, you should see some curious things happening with the focus and perceived distance here. The upper two lines should appear crisper and closer, the lower two very fuzzy and further away, and green somewhere in the middle. This is because different wavelengths aren’t refracted the same way, and so color plays into the perceived focus distance.

While I’m not yet using this for measurements, it could be a lead how to standardize focus range measurements. Quite possibly, the right computer glasses and distance get the red contrasts at the top into focus, but keep green just a tiny bit fuzzy. And the blue contrast should look bad. :stuck_out_tongue_closed_eyes: Maybe blue getting crisp is how the eye detects hyperopic defocus? Or the green being crisper than the red? Anyway, the point is, these things could be useful to determine the right focus challenge on a screen, and might help making these measurements more comparable between people.

If something comes out of this and the Windows UI, then I could put this kind of test image to the right of the focus range input form, with lots of white around it to keep overall screen brightness high. Then you’d measure to the screen and have the form to log the results right there. HOW PRACTICAL :cowboy_hat_face:

I’m considering to add something like astigmatism wheels in magenta and cyan (inverse green and red) around the above color test image, to give an indication of directional blur / uncorrected astigmatism in the relevant color range. There’s enough space anyway, I guess…?

As with everything, I’d appreciate any ideas and comments!

Creating a Format for Sharing and Analyzing Vision Logs

This is where things get a bit more technical, but it might be the most important topic if we want to advance the state of knowledge about myopia.

Because right now, the data situation on vision improvement is a mess.

  • Everyone does their own thing.
  • Most people just write text.
  • Almost nothing can be easily compared or quantitatively analyzed.

This is holding us back, because we can’t even ask the simplest questions to this kind of data. Try answering some quantitative questions:

  • Does the optimal undercorrection depend on total diopters?
  • What is the average effect of a dark winter?
  • How much does improvement fluctuate randomly?
  • Are there diminishing returns?
  • Are contact lenses better than glasses?
  • What difference does age make?
  • … and so on, and so forth, etc.

While Jake is making an admirable effort to create standards within BackTo2020, this is a small group in a walled garden. By and large, everyone is starved for usable data. Better ways to create and share it would not only help the community at large, but also be of personal interest to anyone working on their eyesight, as personal logs are very useful for improving habits, choosing glasses, quantifying progress, and more.

This places us in a rare position where we could create a standard that might spread in the future of vision improvement, allowing us to share results and run data analyses that give us more reliable answers to the big questions. This is why I started on this format pretty much the moment I began systematic logging about a year ago. Here’s an excerpt from my log:

visiondata-xml-sample-2019-05-23
The tech-savvy will quickly recognize XML, the markup language that is also behind websites and various other technologies (like the Windows UI layout from before). I won’t go into the details of why I think XML is suitable here, but if someone wants to discuss this, please ask and I’ll give deatils. For this post, it is more important to talk about the kind of content that the format should support.

Agreeing on Format Contents

The thing with data formats is that once they are out in the world, they are hard to expand and practically impossible to change. Make an error in its small beginnings, and people may be cursing about it decades down the line. This is why I’d like to ask anyone who survived this far into this post (:sweat_smile:) to chime in on what a vision log absolutely needs, what might go wrong with the definitions we make, and what problem cases I might have overlooked.

The Windows UI above should already give a rough idea how the format works. Here’s more precisely what the current draft entails:

  • Every person’s history is organized as a list of entries, which must record the local date and time and may record a location.
  • Entries can contain any number of comments – which are free text – or measurements.
  • Measurements always concern a single eye. The following kinds are currently supported:
    • Focus range measurements record centimeters to blur, optionally a text to identify the target looked at, and optionally the spherical and cylindrical power of any lens worn while measuring.
    • Automated refractive measurements record machine estimates for an eye (Sph, Cyl, Axis), as well as the name of the machine (that is technically optional, though I’m not sure if that’s a good idea in typical usage).
    • Axial length measurements contain the name of the device and a list of samples that estimate the eye’s length.
    • Acuity tests contain the information about the lens worn / prescribed for good distance vision, and optionally a LogMAR value of how well the eye sees with them. I think in the future, an optional Snellen value could be useful to add here. And maybe a parameter to denote self-measured results, for the living room Snellen?

If all of this becomes a thing, the format will be formally specified via an XSD schema, including annotations that hopefully make it rigorously defined. For the XML-savvy, here’s the current XSD draft (Pastebin, expires in six months).

Something I’m uncertain about are binocular measurements (using both eyes at the same time). In the current draft, this isn’t supported, since refraction physically exists on a per-eye basis and the brain magic of binocular vision just obscures errors. But given how many people track this in one way or another, maybe it should be included after all?

Bottom line on the format, the point is to make something that can be used in various contexts of tracking eyesight, promote its usage, and then hopefully get more people to share logs to run data analysis on. If enough people help out, the resulting information could be a very powerful resource to better understand myopia.

Immediate Plans

Damn, my threads get longer every time.

If there’s interest in this stuff, I should be able to get a rudimentary release together next month. So, a program that can create a log in the new format, add entries with focus range measurements and text to it, and make graphs for each eye, as well as a moving average if enough data is entered. Does that sound useful?

Okay, I’ll stop now. Hope I didn’t scare anyone away with this monstrosity of a post. Any opinions appreciated! It would be kinda sad if I made a user interface that’s only used by myself in the end. :laughing:

If I respond more slowly than usual, that’s because I’ll be on two bike tours shortly after posting this: one to a wedding and then another over the Alps to Venice. Outdoor stimulus! :sunglasses:

15 Likes

Wow, you have time to do all that and make a living too? I am jealous :smile:

Here’s my one need for data analysis / logging and the solution I found for it. I would hope for more of the same under this Topic but maybe this Topic is more for research.

I have been recording my CM numbers (right, left, both eyes, a.m. and p.m.) since 1/1/19. Almost immediately I saw that I could not tell much about the data from looking at the numbers…so I put it into a LibreOffice Calc spreadsheet graphing a linear fit to the number series. The following is a pdf of the result for April.

centimeter_chart_libre_calc_2019_04.pdf (37.8 KB)

3 Likes

Hi Varakari,

TLDR but I’m down with this. Personally, though I don’t prefer a GUI although many would, I’m sure. I’d rather have some data worksheets with all the fields for raw data and then use pivot tables. I already have worksheets for near vision, distance, astigmatism and Snellen. But I’ve had some trouble making useful pivot tables with it. I’d be happy to show you what I’ve got for you to improve.
Also, I need to start using the LUX lightmeter app consistently with each measurement. That way we have a basis for normalizing the data if we have a large group of people contributing. It needs to be standardized.
Thanks for your thoughts!
Deb

1 Like

Hahah… well, to be honest, I’m cheating a bit. The closer my eyes get to long-term axial reduction, the less I work on other projects. So I’m spending reserves right now. Which isn’t too bad; I saved up enough beforehand to do some wild things now.

Your post is perfect for this topic, since it shows what I need to do if I want to ever convert your data into a common format. Namely, I need a binocular variant of focus range measurements, so your “both eyes” values can be represented. Thinking about it, this requirement is so common that it should be added.

Seems like I overdid it with the post length… :sweat_smile::sweat_drops::sweat_drops: I’ll try to keep it shorter when it comes to actual releases.

Well… hand-typing XML would be valid. Datasheets are an uncanny valley to me – not user friendly enough for a good front-end, but also not particularly powerful when it comes to complex content. Though it would be possible to write exporters that turn the XML into whatever datasheet layout desired, if that’s useful for analysis.

If you want to share anything, I’ll gladly look through it in search of ideas!

That’s a good idea! Also something to consider adding into the format! I wonder how reliable the brightness readings from smartphones are. Do they need calibration?

Thanks for your input!

1 Like

I use one on my iPhone (downloaded a free one randomly from the app store). It does not need any calibration. Unfortunately I don’t know how reliable it’s in absolute measure (I don’t have any calibrated device to compare with), but I’m pretty sure that it gives stable result, so when I measure the same thing with the same conditions it gives the same number.

1 Like

I was going to chip in on the brightness measurement as standard option to add to each measurement. On that note:

I stumbled onto this post looking for info about the phone-app measure brightness option, seems they’re not quite perfect, but perhaps OK for a general indication…


Maybe not the most objective source, but still.

1 Like

Thanks for this link!

Even if the source may be biased, it looks like they made a serious attempt and got nothing but abysmal results. That is exactly what I feared about smartphone illuminance measurement.

I think this is enough to not include illuminance for now. There’s no obvious advantage, but it could lead to lots of bad data if people measure it poorly. Most fluctuations in brightness should even out quickly enough to track long-term improvement. And for the seasonal fluctuations, the date and location of a measurement should suffice to check for correlations.

This measurement and logging system is really awesome, looks so cool and promising.

I really like the idea that this will create a large sample size with a unified measuring system. You may very well get a nice publishable article from all the data obtained this way. Thanks for the effort so far, let’s hope you’ll be able to make it work the way you’ve envisioned/intended! :+1::clap:

1 Like

Allow me to express a thought that challenges this conclusion. In the end if you get this pool of data, one would want to tease measurable effects out of it. One source of “noise” in the data will be the level of luminance. If you do set up a standard way for people to record level of lighting at time of measurement, this may be a way of reducing noise a bit in the eventual statistical work. And if it doesn’t reduce noise, one can always ignore the parameter. But if you don’t record it, there’s no choice.

3 Likes

That’s true @Jonas. There’s always a benefit to “document everything”. So, this isn’t to throw the idea out forever. If we manage to get the main features going, we could still extend the format to add a way to indicate brightness.

But cost-benefit is crucial. At this point, given the noise we can’t get rid of anyway, how hard it is to do this properly, and the costs of adding a potentially half-baked feature now, this doesn’t seem like it would pay off. If you want to log it anyway: you could add extra data via the comment function, and transcribe it if it becomes standardized later.

There are some proposals that offer much greater benefit at the moment. How about this one for example:

Logging Glasses In Use

This would log which glasses are used for which purposes at a given time. (E.g. the Normalized & Differential in use.) Standardizing this part of logging hasn’t gotten much discussion yet, but I think it could be tremendously useful. It is surely tricky, given all the corner cases. But imagine being able to statistically check how the glasses used influence results! This isn’t a feature for the first version of the program, but wouldn’t this be great in the long run? Maybe one day, we could make statistical recommendations when to reduce, based on personal past performance and glasses used. :upside_down_face:

So, I’m thinking to first focus on the basics, and then on features like this, the kind that applies to almost everyone and could make a big impact.

Now I wonder, how do most people log changing glasses? I just have a messy text file where I write what I changed.

1 Like

Now I wonder, how do most people log changing glasses? I just have a messy text file where I write what I changed.

I use the app “Journey” with tagging different entries.

1 Like

@Varakari ditto on @Jonas