Fixed render issues
Signed-off-by: Jim Martens <github@2martens.de>
This commit is contained in:
parent
7a4c932dcd
commit
11ed4e2b93
|
@ -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.
|
||||
|
|
Loading…
Reference in New Issue