Basic image processing module about open3d HOT 6 CLOSED

In test, the module name can be TestImage

Also, since they are in Core now, please add python bindings to these functions. I suggest we split it into two pull requests: first is just the change to the cpp files; second is the python binding (and tests in python).

If OpenCV is available, CMake tool-chain will link it for utilizing higher level functions such as ORB.

This is lower priority, we don't need to fix it in near future (i.e., before the first launch).

from open3d.

Questions.

• I guess we need a function that transforms FloatImage to uint_8 or uint_16 image. WriteImage does not have this functionality.
• I am bit confused with CreateImageFromFile and ReadImage. CreateImageFromFile is only used in TestTriangleMesh.cpp. What is recommended way to read an image? Do we need both function?
• All the image processing functions assumes the image is float type. How about constrain input arguments of downsampling, filtering, creating pyramid image functions to be FloatImage?

from open3d.

I guess we need a function that transforms FloatImage to uint_8 or uint_16 image. WriteImage does not have this functionality.

Good point. Play with it. I did not thoroughly design the Image module. Also, I have been considering removing the FloatImage class for a long time. It only has an sub-pixel functionality and used in one app. Maybe we just remove it and use Image with 4-bit channel instead.

I am bit confused with CreateImageFromFile and ReadImage. CreateImageFromFile is only used in TestTriangleMesh.cpp. What is recommended way to read an image? Do we need both function?

ReadImage is in IO. It is actually bad design (due to some history reasons). My current plan is to wrap these IO functions into good design, like the factory functions. An analog is in dealing with PointCloud. I use ReadPointCloud in the IO module only internally in Open3D, and expose CreatePointCloudFromFile as external interface (e.g., in python binding).

All the image processing functions assumes the image is float type. How about constrain input arguments of downsampling, filtering, creating pyramid image functions to be FloatImage?

I am actually thinking of removing FloatImage class. I don't know, maybe it makes sense to keep it? And use it as the type of parameters used in the image processing functions? In this way I would vote for keeping it, since now it has a clear meaning: Image is for conventional images; FloatImage is for images used for image processing in Open3D; it is recommended to use Image just for IO and related stuff, and always convert it to FloatImage before any processing.

from open3d.

I actually agree with your original idea: removing FloatImage because

• It might be confusing and not consistent with other data structures: we don't have FloatPointCloud, or we don't want to have DoubleImage. I had this confusion when I tried to use Image class in Open3D for the first time.
• In many cases, we can write an app only using FloatImage, which means Image can be isolated.

I think we may unite FloatImage and Image, and simply the image processing functions are only activated if its data type is 32bit float. I originally thought we make FloatImage is only for internal usage and not unveiled to users, but existence of FloatImage still would give confusion.

How do you think?

from open3d.

Good to me. Remove FloatImage.

Can you make a small pull request first, just doing this.
Then make another pull request to address the other changes we discussed for Image.

from open3d.

The module is implemented and merged. Closing.

from open3d.