## 5 Discussion  
Our converter tool is a Windows console application developed in C++, as shown in Figure 7. We believe that this is a novel work that implements the emerging international standard. Our work enables the transformation of a large amount of legacy 360-degree images into the standardized format, which provides a market to use the images in the same format, which was a goal of developing the JPEG 360 standard. This application can also be used to view JPEG 360 metadata in a JPEG-1 image. Users can extract metadata values and use them according to their needs. It can be a basic unit in developing viewer/renderer software for standard JPEG 360 images. We also used it in our PTZ panorama to convert the obtained panorama to JPEG 360 format. Another advantage of this command-line application is that it can be utilized using batch command to convert many files at a time. The subjective and objective quality of the converted image remains the same as the image pixels bitstream is not involved in the conversion process. This is a significant advantage of the converter: visual quality is fully preserved. The file size is increased by approximately 8 kB after adding JPEG 360 metadata. The limitation of the converter application is that if the user wants to forcefully embed JPEG 360 metadata to a 2D image, the image will still be converted to JPEG 360. Another limitation is that the user should carefully provide the metadata values because the converter is not intelligent enough to check the values to understand whether the values satisfy the constraint equations. The PTZ panorama solution is cheap compared to standard 360-degree cameras because the PTZ cameras are very low in price. The standard JPEG 360 metadata values in our panorama are necessary for realistic rendering of the panorama, which helps the viewer see the realistic environment virtually. In our Windows application, we provided four options for stitching algorithms. A user can choose either SURF, SIFT, ORB, or AKAZE. We compared the stitching time of all these algorithms. Table 8 shows the average stitching time. We can observe that ORB consumes less time, and SURF and SIFT consume more time than others. SURF and SIFT take longer because of their robustness. Based on experiments on different input images, we found that SURF is robust in finding features, so it stitches more successfully than the others. We provided two projection formats for the resultant panorama: spherical and cylindrical. Although our resultant panorama is not a full sphere, it is part of a sphere, and the situation is similar for the cylindrical format. \begin{table}
\begin{tabular}{c c c c c c c c} \hline \multirow{2}{*}{**Features**} & **Position** & **Center** & \multicolumn{2}{c}{**Side**} & \multicolumn{2}{c}{**Corner**} \\ \cline{2-9}  & **Config** & **2 Rows** & **1 Row** & **2 Rows** & **1 Row** & **2 Rows** & **1 Row** \\ \hline \multirow{3}{*}{SURF} & Spherical & 17.862 & 12.258 & 2.992 & 1.048 & 1.978 & 0.529 \\ \cline{2-9}  & Cylindrical & 19.963 & 13.032 & 2.946 & 0.901 & 2.946 & 0.525 \\ \hline \multirow{3}{*}{SIFT} & Spherical & 12.356 & 2.729 & 3.428 & 1.129 & 1.765 & 0.725 \\ \cline{2-9}  & Cylindrical & 12.865 & 2.824 & 3.386 & 1.16 & 1.82 & 0.682 \\ \hline \multirow{3}{*}{ORB} & Spherical & 8.824 & 2.199 & 2.522 & 0.793 & 1.157 & 0.395 \\ \cline{2-9}  & Cylindrical & 8.046 & 2.623 & 2.28 & 0.599 & 1.195 & 0.400 \\ \hline \multirow{3}{*}{AKAZE} & Spherical & 8.918 & 2.359 & 3.045 & 1.008 & 1.462 & 0.574 \\ \cline{2-9}  & Cylindrical & 8.82 & 2.236 & 2.936 & 0.975 & 1.833 & 0.581 \\ \hline \end{tabular}  
* All values are in seconds. Each value is average of 5 experiments.  
\end{table} 
Table 8: Stitching time of different feature-finding algorithms. From several experiments, it is observed that when the number of input images is more than 10, the stitching process becomes complicated, and visible seams appear in the resultant panorama.