Bug with cFRQI function from "qpixly_parallel.py"

[duspic]

What this bug does

This bug is noticeable by a corrupted decoded image, with various distortions. It seems that, based on the shape of the second image, it corrupts the first image.

What causes this bug

an issue stems from the current cFRQI() function implementation found in "QPIXL/qiskit/qpixl_parallel.py"
from my examination, it seems that there is a special case in the cFRQI function, in which a parity check (pc) variable is miscalculated.

How to reproduce the bug

To reproduce the simplest case, trying to run two images in parallel, set the size of the first image to (32,32) and the second to (30,49).
This is illustrated in the attached image above. This only happens in certain, elusive cases. Most combinations of image shapes do not produce the bug.

How to solve the bug

I've found a way to solve it (at least for now), and will propose a pull request. It's just a matter of changing when the controlX gates are applied in relation to updating the parity check variable.
I'm raising this issue to separate it from another issue, as has already been discussed in another pull request's thread.

[phantmgx]

I’ve submitted a fix in PR #15 to resolve the parity control bug mentioned in this issue.

[duspic]

@phantmgx

I've also made a PR with a proposed solution, that includes a notebook. In the last cell there are some "randomized tests" that I've used to compare the results of the original cFRQI and my updated version.

I'm trying to compare your version as well, to see the differences and possible advantages. Can you include some code that shows how you run a full example? Perhaps you pre-process images in a different way than me?

Currently, when I try to run your version of the cFRQI, there are corrupted images
Running it on the example from the issue gives this:

[phantmgx]

I originally submitted PR #15 thinking the logic was solid, but after running through your notebook and testing it properly, I realized my version didn’t fully handle padding or parity masks correctly
By the way, for the QPIXL visual challenge — would it make sense for us to integrate your fixed version into our submission, or should we continue working with the original (buggy) version as a base?
Thank you!

[duspic]

A good question... perhaps the repo owner can answer that? @danielbultrini
From my perspective, it would make sense to use the fixed version, but it could also produce some repository mess since it hasn't been merged yet.

The bug only appears on certain input shapes, so it might not affect your submission. Perhaps you can locally have the old and the fixed versions, work with the fixed one to ensure you're not getting corrupted results, then at the end check if your submission runs equally well on the old cFRQI version.
But let's see if Daniel has something else to say

[danielbultrini]

Hello @duspic and @phantmgx , sorry for my late response - it makes sense to work off of the fix by duspic - sadly I did not have time to go over everything in depth enough to merge (we were thinking of doing that closer to the end of the hackathon), in case you have already done some work, I will integrate the two PRs manually. Otherwise I would ideally first pull duspic's and then phantmgx's.

[duspic]

With the merge of #16 , I consider this completed!