This scikit-surgeryimage is based around OpenCV. Default for OpenCV is BGR. So, we should not impose any additional assumptions, like RGB.
The reason being: Other functions in OpenCV will implicitly assume BGR. So, if an algorithms converts to HSV colour space for example, then internally the method will call cvtColor(...COLOUR_BGR2HSV), and not use RGB2HSV.
So we should be consistent with this convention.
If you add another assumption, like, "our library assumes RGB", then you will spend a lot of time needlessly converting RGB to BGR and back whenever you call an OpenCV function.
Therefore the only time you should have to convert is when you cross a boundary between OTHER libraries. i.e. OpenCV->VTK. VTK will assume RGB. .... or passing an OpenCV image into TensorFlow, which underneath uses PIL, which assumes RGB. These conversions are unavoidable.
So you should only convert at the interface between two libraries.... and not add extra assumptions to this library. This library is OpenCV convention.
This scikit-surgeryimage is based around OpenCV. Default for OpenCV is BGR. So, we should not impose any additional assumptions, like RGB.
The reason being: Other functions in OpenCV will implicitly assume BGR. So, if an algorithms converts to HSV colour space for example, then internally the method will call cvtColor(...COLOUR_BGR2HSV), and not use RGB2HSV.
So we should be consistent with this convention.
If you add another assumption, like, "our library assumes RGB", then you will spend a lot of time needlessly converting RGB to BGR and back whenever you call an OpenCV function.
Therefore the only time you should have to convert is when you cross a boundary between OTHER libraries. i.e. OpenCV->VTK. VTK will assume RGB. .... or passing an OpenCV image into TensorFlow, which underneath uses PIL, which assumes RGB. These conversions are unavoidable.
So you should only convert at the interface between two libraries.... and not add extra assumptions to this library. This library is OpenCV convention.