ElectroHolography Laboratory

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
======Research Log======
======2018======
-----
=====Fall 2018=====
====31 Oct 2018====
I've made a few edits to the original Arbitrary Chirp function, based on the old Arctan function, including multiplying by $$\pi/\beta_{GPU}$$. Now to see if it works better. \\
EDIT: with that adjustment, the output at least makes sense. There are some definite stability issues with the text input box worth looking into, but for the moment it can be experimented with.
-----
====27 Oct 2018====
I've modified the NearEye generator to use an arbitrary chirp function.
  * There's another library (a git submodule) for math expression parsing. It takes a long time to compile.
  * A new dropdown selects between Linear, Arctan, and Arbitrary chirps
It does compile and run, but the output doesn't seem to be useful yet. It needs some experimentation and adjustment.
TODO: add a picture here
-----
====19 Oct 2018====
I'm starting to work on breaking down Drew's Shader code for the [[:near_eye_display|Near Eye]] to figure out where to put arbitrary wave functions. I'm going to make a new page of [[Near Eye Shader]] to put a breakdown of the per-pixel math to see if that will help.
-----
=====Winter 2018=====
====15 Jan 2018====
In preparation for adding links to the monitor website, I did some digging into permissions in GitLab. It looks like making the projects public is the way to go, but I don't want them to be publicly write-able, lest someone start pushing changes that we haven't been able to review ahead of time. If I'm understanding correctly, "protected branches" provide this function. This lets us restrict pushing to only those with at least "Developer" (or "Master", but since we also control who has what role, I'd say letting developers push generally is alright, at least for now) status. And, we can apply it as a wildcard to the branches, so we can simply say all branches require "Developer" status to push before changing the project access permissions. So, for each "project" (or "repository" in basic git lingo), I'm following this process:
  - go to "Repository" settings (under the settings tab on the left), and under "Protected Branches", create a * wildcard allowing only "Masters" to merge and "Developers + Masters" to push
  - under "General" settings, go to "Permissions". Within that:
    - Change Project Visibility to "Public"
    - Turn off everything but "Issues", "Repository", and "Merge requests" (leave all of those open to anyone with access)
As an explanation for those three permissions to leave on:
  * "Issues" lets them submit problems that they find to us so we can try to fix them (one of the great strengths of an open source model)
  * "Repository" lets them actually access the files. If this was off, then only Owners (Drew and I) could even see the files
  * "Merge requests" lets people fork the project, make changes where they see a problem, and then send those changes to us. Again, this lets open source be a potential way of improving the project, but still keeping us in control.
The permissions turned off by doing this are things we don't use anyway (like the GitLab Wiki, hosted building pipelines, etc.).
-----
====8 Jan 2018====
Bad news on that laser driver: it doesn't seem to be working, and unfortunately I don't know when I'm going to have time to properly debug it. My research priorities, such as they are, for this semester are: making the monitor website (for long term public documentation), and working on the Near-Eye with Drew to hopefully impress the TIPD contract people. Hopefully I'll be able to find some time to work on both.
-----
ElectroHolography Laboratory

User Tools

Site Tools

Page Tools
