[Soc-2016-dev] Week 4 Report, Multiview Reconstruction

[Sergey Sharybin]

Sounds all cool!
On Jun 20, 2016 19:44, "Tianwei Shen" <shentianweipku at gmail.com> wrote:

> Hi Sergey,
>
> Now I have done the track index conversion on the blender side. It is
> indeed more convenient and appropriate to do so on the blender side as you
> said. The global track index is constructed like this: initially tracks in
> each clips are indexed as [0,1,2 … N1-1] for tracks in the first clip with
> N1 tracks, [N1, N1+1, … , N1+N2-1] for tracks in the second clip with N2
> tracks, so on and so forth. Then the correspondence list would be checked
> out. For a single correspondence, the global track index of the second
> track will be altered to the global index of the first track. In this way,
> we can go over correspondence list only once. The global index would be
> passed to libmv.
>
> I have also kept the previous correspondence data structure made on the
> libmv side, in case I may use it in the future. If it goes well, I will
> remove it in the code refactoring. Now I will continue to work on bundle
> stuff.
>
>
> Thanks,
> Tianwei
>
> On 2016 M06 20, at 10:04, Tianwei Shen <shentianweipku at gmail.com> wrote:
>
> Hi,
>
> Sorry for not being able to communicate with you first. I took some time
> to find that the track index in mv::Marker is mean to be global, instead of
> local under clip field. So I might not fully comprehend your meanings in
> the previous email. I was able to pass the correspondences from blender to
> libmv and do the global alignment in the libmv. Now I would do this as you
> suggested. That is, reorganize track index from different clips into a
> global index, on the blender side. Sorry for the communication problem if
> it brings you any trouble. I will get back to you in time and stay focused
> on IRC.
>
>
> Thanks,
> Tianwei
>
> On 2016 M06 20, at 01:00, Sergey Sharybin <sergey.vfx at gmail.com> wrote:
>
> Hi,
>
> Here's some thing about correspondences. Why you are not following
> approach where it is on Blender side to align track numbers so
> correspondence tracks from other clips simply has same number? That's
>
> (a) Simpler from API point of view (so basically you reduce number of
> modifications)
> (b) Simpler from use in Libmv itself (so you work with all tracks in
> similar way)
> (c) This is actually what i've suggested in private mail which was not
> replied.
>
> If you do some decisions i want them to be at least communicated. If it
> doesn't align with suggestions form my side i want to have reasoning. Not
> saying all the suggestions are always correct, but if hey are not this to
> be communicated.
>
> As for code style. Libmv uses Google's code style [1]. It is to be
> followed in Lbmv. However, C-API of Libmv follows Blender's code style.
>
> [1] https://google.github.io/styleguide/cppguide.html
>
> On Sat, Jun 18, 2016 at 5:25 PM, Tianwei Shen <shentianweipku at gmail.com>
> wrote:
>
>> Hi everyone,
>>
>> Here is my week 4 report. I didn’t get much done as my eyes did not feel
>> well this week. I should be catching up with the schedule next week.
>>
>> What I did this week:
>> * Filling the gap in mv::Reconstruction class of libmv/autotrack, namely
>> AddIntrinsics method, AddCamera method, etc.
>> * make correspondence data structure in libmv side, and pass this
>> information from blender to libmv
>> * add bundle.cpp/bundle.h in autotrack, begin migrating bundle from
>> simple_pipeline to autotrack.
>>
>> Next week plan:
>> * finish migrating bundle code
>> * do the mid-term evaluation
>>
>>
>> Question:
>> 1. libmv has a different and non-standard comment and indentation style.
>> For example, blender uses tab (and set as =4 spaces) while libmv using
>> 2-spaces. Should I stick with the libmv indentation style or feel free to
>> comment and indent using blender style?
>> _______________________________________________
>> Soc-2016-dev mailing list
>> Soc-2016-dev at blender.org
>> https://lists.blender.org/mailman/listinfo/soc-2016-dev
>>
>
>
>
> --
> With best regards, Sergey Sharybin
> _______________________________________________
> Soc-2016-dev mailing list
> Soc-2016-dev at blender.org
> https://lists.blender.org/mailman/listinfo/soc-2016-dev
>
>
>
>
> _______________________________________________
> Soc-2016-dev mailing list
> Soc-2016-dev at blender.org
> https://lists.blender.org/mailman/listinfo/soc-2016-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/soc-2016-dev/attachments/20160622/fa4a624d/attachment.htm