Fixed render issues

Signed-off-by: Jim Martens <github@2martens.de>
This commit is contained in:
Jim Martens 2019-02-21 14:45:38 +01:00
parent 7a4c932dcd
commit 11ed4e2b93
1 changed files with 45 additions and 31 deletions

View File

@ -206,7 +206,7 @@ fact I do want to reserve free time.
\textbf{Due date:} 20th March
\begin{description}
\item[Download SceneNet RGB-D to cvpc\{7,8\} computer]
\item[Download SceneNet RGB-D to cvpc\{7,8\} computer] \hfill \\
Requires external resource.
\end{description}
@ -215,14 +215,14 @@ fact I do want to reserve free time.
\textbf{Due date:} 5th April
\begin{description}
\item[Download pre-trained weights of SSD for MS COCO]
\item[Download pre-trained weights of SSD for MS COCO] \hfill \\
This is trivial. Takes not more than two hours.
\item[Modify SSD Keras implementation to work inside masterthesis package]
\item[Modify SSD Keras implementation to work inside masterthesis package] \hfill \\
Should be possible to achieve within one day.
\item[Implement integration of SSD into masterthesis package]
\item[Implement integration of SSD into masterthesis package] \hfill \\
Implementing the glue code between the git submodule and
my own code. Should be doable within one day.
\item[Group SceneNet RGB-D classes to MS COCO classes]
\item[Group SceneNet RGB-D classes to MS COCO classes] \hfill \\
SceneNet contains more classes than COCO. Miller et al have
grouped, for example, various chair classes in SceneNet into
one chair class of COCO. This grouping involves researching
@ -231,15 +231,15 @@ fact I do want to reserve free time.
All in all this could take up a full day and perhaps slip
into a second one.
\item[Implement variant of SSD with dropout layers (Bayesian SSD)]
\item[Implement variant of SSD with dropout layers (Bayesian SSD)] \hfill \\
This is a rather trivial task as it only involves adding two
Keras dropout layers into SSD. Can be done in one hour.
\item[Fine-tune vanilla SSD on SceneNet RGB-D]
\item[Fine-tune vanilla SSD on SceneNet RGB-D] \hfill \\
Requires external resource and length of required training is
unknown. Due to two unknown factors (availability of resource,
and length of training) this task can be considered a project
risk.
\item[Fine-tune Bayesian SSD on SceneNet RGB-D]
\item[Fine-tune Bayesian SSD on SceneNet RGB-D] \hfill \\
Similar remarks like the previous task.
\end{description}
@ -259,30 +259,29 @@ so that the training time is used as efficiently as possible.
\textbf{Due date:} 12th April
\begin{description}
\item[Adapt GPND implementation for SceneNet RGB-D using MS COCO classes]
\item[Adapt GPND implementation for SceneNet RGB-D using COCO classes] \hfill \\
Requires research to figure out the exact architecture needed
for a different data set. The code is not well
documented and some logical variables like image size are
sometimes hard-coded, which makes this adaption difficult
and error-prone.
Furthermore, some trial-and-error regarding training successes
is likely needed, which makes this task a project risk.
If the needed architecture was known the time to implement
it would be at most one day. The uncertainty therefore
lies with the research part.
\item[Implement novelty score calculation for GPND]
\item[Implement novelty score calculation for GPND] \hfill \\
There is an implementation for this in the original
author's implementation. It would have to be ported
to Tensorflow and integrated into the package structure.
Takes likely one day or two.
\item[Apply insights of GAN stability to GPND implementation]
\item[Apply insights of GAN stability to GPND implementation] \hfill \\
The insights from the GAN stability\footnote{\url{https://avg.is.tuebingen.mpg.de/publications/meschedericml2018}} research should be applied to
my GPND implementation. Requires research what, if any,
insights can be used for this thesis. The research is
doable within one day and the application of it
within another.
\item[Train GPND on SceneNet RGB-D]
\item[Train GPND on SceneNet RGB-D] \hfill \\
Requires external resource.
In contrast to the SSD network, there are no pre-trained
weights available for the GPND. Therefore it has to be
@ -304,32 +303,32 @@ the aggressive date I will work towards.
\textbf{Due date:} 10th May
\begin{description}
\item[Implement evaluation pipeline for vanilla SSD]
\item[Implement evaluation pipeline for vanilla SSD] \hfill \\
Involves the implementation of the evaluation steps
according to the chosen metrics. Takes likely two days.
\item[Implement evaluation pipeline for Bayesian SSD]
\item[Implement evaluation pipeline for Bayesian SSD] \hfill \\
Involves the implementation of the evaluation steps
for the Bayesian variant. As more is has to be done,
it will likely take three days.
\item[Implement evaluation pipeline for vanilla SSD with GPND for novelty score]
The implementation of this pipeline will take probably two
days.
\item[Run vanilla SSD on test data]
\item[Implement evaluation pipeline for SSD with GPND for novelty score] \hfill \\
Implementation of the evaluation steps for my approach.
It will probably take two days.
\item[Run vanilla SSD on test data] \hfill \\
The trained network is run on the test data and the results
are stored. Requires external resource but should be
far quicker than the training and will probably be done
in two days at most.
\item[Run Bayesian SSD on test data]
\item[Run Bayesian SSD on test data] \hfill \\
Similar remarks to previous task.
\item[Run vanilla SSD detections through GPND]
\item[Run vanilla SSD detections through GPND] \hfill \\
For my approach the SSD detections need to be run through
the GPND to have all the relevant data for evaluation.
Requires external resource. Will take likely two days.
\item[Calculate evaluation metrics for vanilla SSD]
\item[Calculate evaluation metrics for vanilla SSD] \hfill \\
Takes one day.
\item[Calculate evaluation metrics for Bayesian SSD]
\item[Calculate evaluation metrics for Bayesian SSD] \hfill \\
Takes one day.
\item[Calculate evaluation metrics for vanilla SSD with GPND]
\item[Calculate evaluation metrics for vanilla SSD with GPND] \hfill \\
Takes one day
\end{description}
@ -341,19 +340,18 @@ happen on the CPU as all the data is already there by then.
\subsection*{Visualizations created}
\textbf{Due date:} 31st May
\textbf{Due date:} 31st May\\
I won't be able to work on the thesis between May 13th and May 26th
due to the election campaign. I am involved into the campaign already
as of this writing but I hope that up until May 10th both thesis
and campaign can somewhat co-exist.
The visualizations should be creatable within one week from May 27th
to May 31st.
\subsection*{Stretch goals}
\textbf{Due date:} 27th June
\textbf{Due date:} 27th June\\
As I mentioned earlier, there are no specific tasks for the
stretch goals. If the critical path is finished by the end
@ -364,24 +362,24 @@ writing period.
\subsection*{Thesis writing}
\textbf{Due date:} 30th August
\textbf{Due date:} 30th August\\
A first complete draft of the thesis should be finished
at the latest by August 16th. The following week I am not
able to work on the thesis but it can be used for feedback.
The last week of August should allow for polishing of the
thesis with a submission-ready candidate by August 30th.
\subsection*{Finishing touches}
\textbf{Due date:} 13th September
\begin{description}
\item[Due date:] 13th September
\end{description}
The submission requires three printed copies of the thesis,
together with any digital components on a CD glued to the back
of the thesis. A non-editable CD ensures that the code submitted
cannot be modified and will be exactly as submitted when reviewed.
I will use these two weeks to print the copies and to make
last publication steps for the code like improving the code
documentation and adding usage examples.
@ -401,3 +399,19 @@ The workload for the election campaign, in which I have an
organizational responsibility in addition to being a candidate
myself, could come into conflict with the progress of the
thesis.
Availability of the external resource can hinder the progress
and delay steps of the thesis. In such a case dependent
tasks cannot commence until the earlier task has been finished,
resulting in an overall delay of the thesis.
To deal with these risks, I have planned for one whole month
of buffer time that can account for many delays. Furthermore,
the writing time is intentionally that long as it is difficult
to predict how inspired I will be. I know from my bachelor
thesis that on some days it can be many pages you write and
on others you might barely make one page progress.
I would argue that the thesis success is largely dependent on
the first part of the work as it can make or break it. Once
the technical part is done, the way forward should be downhill.