Port hardsubx imgops

[shashwat1002]

In raising this pull request, I confirm the following (please check boxes):

• I have read and understood the contributors guide.
• I have checked that another pull request for this purpose does not exist.
• I have considered, and confirmed that this submission will be valuable to others.
• I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
• I give this submission freely, and claim no ownership to its content.
• I have mentioned this change in the changelog.

My familiarity with the project is as follows (check one):

• I have never used CCExtractor.
• I have used CCExtractor just a couple of times.
• I absolutely love CCExtractor, but have not contributed previously.
• I am an active contributor to CCExtractor.

---

On determination that the imgops functions have lowest dependency and need to be used as-is, that is where I have begun porting.

The PR introduces (as of now) a function with an identical signature to rgb_to_hsv with rest of the code unchanged. The DISABLE_RUST flag is used to decide if the Rust version is compiled or the C version.
Edit: hardsubx_imgops is now fully ported

The compilation works and the executable runs properly on the files I have. However, the who suite of tests must be run as soon as the imgops module is ported.

Ps: I discovered that when building using cmake, Rust compilation is disabled by default and I had to explicitly set the DWITHOUT_RUST=OFF
I am unsure if this is the expected behaviour.
Edit: apparently this is because cmake caches options

Cc: @PunitLodha, @cfsmp3
please look this over once to check if I am not doing something obviously dangerous. I will continue after feedback.

[shashwat1002]

PR updated
@PunitLodha please review

[PunitLodha]

Also fix the formatting issues by using rustfmt and clang-format

[shashwat1002]

Please check now @PunitLodha

Also note that, the code now is mathematically different for the rgb_to_lab function
I was looking into the actual algorithm so as to write better comments, I noticed that the existing disagreed with several references I found. I may be missing something, but I am not sure

Source:

• https://en.wikipedia.org/wiki/CIELAB_color_space#From_CIEXYZ_to_CIELAB
• http://cs.haifa.ac.il/hagit/courses/ist/Lectures/Demos/ColorApplet2/t_convert.html

[shashwat1002]

@PunitLodha
Rewrote functions using the palette crate

The result is definitely different from the original C code
There is still a lot of hallucination (both the old and the new version)

I believe the new version is leading to slightly less hallucinations when it comes to lines which sort of make sense in the result. I don't have a good metric as of now.

Ps: Also it seems the rust compiler does not support deconstruction on left side in assignment statements because it worked on my system but not in the checks, so I just converted and committed

[PunitLodha]

The result is definitely different from the original C code

This is expected. Once we update the preprocessing code, we should be seeing better results than before

Ps: Also it seems the rust compiler does not support deconstruction on left side in assignment statements because it worked on my system but not in the checks, so I just converted and committed

This is because the tests use rust 1.56.0, and destructuring was added in 1.59.0

[PunitLodha]

Please fix the formatting, https://github.com/CCExtractor/ccextractor/runs/6866810135?check_suite_focus=true

Always make sure that the CI checks are not failing

[PunitLodha]

No need of extern crate in Rust 2018, https://doc.rust-lang.org/edition-guide/rust-2018/path-changes.html#no-more-extern-crate

[shashwat1002]

Please fix the formatting, https://github.com/CCExtractor/ccextractor/runs/6866810135?check_suite_focus=true

Always make sure that the CI checks are not failing

I wanted to ask about that actually. I ran clang formatter, which one should I use then?