Pixels_Seminar
Pixels_Seminar copied to clipboard
SRA-VJTI
Redesign a new File structure.
Is your feature request related to a problem? Please describe. As we are moving the contents to c++ as discussed in this thread, it is important to redesign the existing file structure.
Describe the solution you'd like I would like to propose the file structure as below:
File structure
.
├── 1_cpp_basic # Contents on the basic of cpp concepts like pointers.
├── 2_build_systems # Topics of build systems including Makefile and Cmake.
├── 3_git_github # Git Github basic contents.
├── 4_cv_basics # Contents of all the Computer Vision Fundamentals.
│ ├── image_representation # Contents in markdown format for the basic image representation.
│ ├── Color spaces and conversion # Introduction to image color spaces and their conversions.
│ │ ├── color_conversion.cpp # Contain the C++ code for conversion between the colorspaces.
│ │ ├── Makefile # Includes build commands.
│ │ └── Readme.md # Detailed Explanation of the topic and its instructions for running the code.
│ ├── Playing with image coordinates # Content on the OpenCV mat container.
│ ├── Convolution and filtering # Contents on the convolution and filtering.
│ ├── Masking # Contents on the Masking.
│ ├── Morphological Transformation # Contents on the morphological transformation.
│ └── Blob Detection # Mini project of blob detection.
├── Assignments # Contains the assignments
├── assets # Contains the images and gifs.
├──.gitignore # ignores the unnecessary build files.
├── LICENSE # Licence for this project.
└── README.md # Contains documentation and topics of the repo.
Additional context Reference from : Ancient Secrets of Computer Vision
Note: File structure is not finalised and open for discussion.
In case of many modules, several different Jupyter Cells work together to complete the concept. When converting to CPP should we combine all of these different cells into a single file? Or should we make separate files for significantly different cells?
In my opinion, significantly different cells should warrant their own files that explain what is happening in depth. Certain cells however can be grouped together.
For e.g.
We can divide blob detection into three parts in this manner:
The only caveat here is that the build file might be a bit more complicated since it needs to work with 3 files instead of just 1.
Please share your opinion on this.
@toshan-luktuke, We will be adding both the contents, the build instructions for compiling from terminal using gcc/g++, and a more standardize way of using build system such as through make/cmake. We will decide to whether to teach build sytem or not depending on the time constraint.
Also, I didn't understood what's the difference between 2_blob_detection.cpp and 3_webcam_blob_detection.cpp, can you elaborate on it?
Ahh, apologies 2_blob_detection.cpp is through a pre-made video that the user provides. Hence the separation between the two.
Still, my main point was on whether to separate these files at all. The alternative being we could implement something like a switch-case if we want it all to be in one file. However, that'll complicate the code structure as the participants would have to scroll through a large file whenever we teach something.
To solve this we can use menuconfig option. It will even address the black-box left in wall-e.
Still, my main point was on whether to separate these files at all. The alternative being we could implement something like a switch-case if we want it all to be in one file. However, that'll complicate the code structure as the participants would have to scroll through a large file whenever we teach something.
Instead of dividing the implementation in different .cpp files, We can define a .h ie header file where we can declare the modular functions by dividing up the implementation logic. Then implement those functions in a respective .cpp file and use those functions in the main driver code. Those modular functions will be easy to explain and easy to use as well!