Exiv2 grabber naming convention

[laxnpander]

During #21 it became clear, that the exiv2 grabber expects the image naming convention: image_0000.jpg. Otherwise really weird behaviour could be observed, e.g. adding the same frame to "valid_input" during georeferencing over and over again. Consequently georeferencing failed.

Todo:

• How to deal with different naming conventions? Grab frame id from somewhere else?
• At least print warning and do not process at all

[ykhedar]

Some suggestions to this problem, usually the names of the images from drones have some kind of logical naming, date-times (2019-11-13T21:35:59.862979Z.jpg, 2019-11-13T21:60:00.845979Z.jpg and so on), increasing numbers (image_0001.jpeg, image_0002.jpeg and so on.). Maybe if you use the default sort algorithm of c++ stdlib, it gives you a sequential image list and the frame numbers can be assumed to start from 0, 1, 2 and so on. The stdlib sort might fail to produce proper results for some cases though. At least in the python world this kind of sorting seem to work.

Other option would be to process exif tags in the image files and extract a list of the all the files sorted according to the date/time. This might add a pre processing step though.

[laxnpander]

@ykhedar: I already do this my friend :) The problem is a bit to adapt to all possible cases. At the moment I assume an image name like "image_0001, ..." so I can extract the frame id from the name. That's nice, because then my saved depth map etc. are traceable back to the original image. If I just have an internal counter this works only if my images start at 0001. But that may not always be the case if you test a subset and so on. The sorting I already do.

The timestamp is currently read from the exif tags, I could also read it from a naming convention if it's in the format you posted. But then again, what if it isn't? One should be able to select, or we set a strict naming policy. But it least it should throw an error, if the convention doesn't fit, which is the main problem here at the moment

[LiShuaixin]

Hi, thanks for your sharing! I met the same issue that realm_exiv2_grabber node crashed from the start in #15. I checked the code and found it crashed calling cv::FileStorage fs(filepath, cv::FileStorage::READ); My PC environment is Ubuntu20.04 with ROS noetic and Opencv 3.4.16. When I complied the OpenRealm_ROS wrapper, it threw out warnings below:

/usr/bin/ld: warning: libopencv_core.so.4.2, needed by /home/lee/RosWorkSpace/openrealm_ws/devel/lib/librealm_ros.so, may conflict with libopencv_core.so.3.4 /usr/bin/ld: warning: libopencv_calib3d.so.3.4, needed by /home/lee/RosWorkSpace/openrealm_ws/devel/lib/librealm_ros.so, may conflict with libopencv_calib3d.so.4.2 /usr/bin/ld: warning: libopencv_imgproc.so.4.2, needed by /usr/lib/x86_64-linux-gnu/libopencv_calib3d.so.4.2.0, may conflict with libopencv_imgproc.so.3.4 It seems like the opencv lib from ROS noetic conflicts with the one I compiled from the source.

Any idea to solve the issue? many thanks!

[LiShuaixin]

Hi, I fixed it with vision_opencv in which cv_bridge is provided. I used the compiled opencv3 lib by changing the find_package(opencv 3) as find_package(opencv 4) in the Cmakelist of vision_opencv, and re-compiled the workspace, and the issued solved!

[laxnpander]

@LiShuaixin I don’t think this is related to the original topic of this issue, but yes this helps with library conflicts! Glad it works for you now.

[LiShuaixin]

Yes, it's just a problem related to the realm_exiv2_grabber node. I think it may be helpful for others who want to build the excellent work on Ubuntu 20.04 with ROS noetic and Opencv 3

[zhangjd1029]

Yes, it's just a problem related to the node. I think it may be helpful for others who want to build the excellent work on with and realm_exiv2_grabber``Ubuntu 20.04``ROS noetic``Opencv 3

@LiShuaixin 老哥，你好，我遇到了和您完全相同的问题。环境是ubuntu20.04，电脑上带有opencv4.2和opencv3.4。根据您的回答，我没有太理解，version_opencv是指的什么，cmakelists of version_opencv是什么意思呢？您可以给一些建议吗？方便的话可以加下微信吗？18348197022，谢谢