Thanks for this very complete and comprehensive PR :). Bad news first: I will not merge this as is. The main reason is that it slows down the library considerably. This new detector takes more time than all other linear codes combined. That is not your fault, though. It is caused mainly by the FindLeftGuard call with such a long fixed pattern, which we don't have anywhere else. But there is ample opportunity to improve the situation.

The first thing we should do is to only look for the code where we can reasonably expect it in a real-world scenario. If I understand the use case correct, then swiping with a phone over a film strip, like you did in your two videos, is not really something one would do? I thought the input would be way more constraint:

1. near perfect lighting, i.e. no over or underexposure because then the image would be useless anyway
2. always a landscape oriented scan with the film-center close to the image center
3. always scanning from the front-side of the film with the normal orientation (barcode at the bottom of the image, not like in your 1.jpg sample)
4. maybe even generally only one film frame per image?

Can you confirm or dispute any/all of those assumptions?

Then there are a few more 'cosmetic' changes that I would like see before merging the code. Would you prefer to read a detailed review and do those changes yourself or rather have me do them (or some of them) and simply add them to your PR?

@gitlost we are on the same page here, see this comment ;)

Thank you for your feedback!

1. near perfect lighting, i.e. no over or underexposure because then the image would be useless anyway
2. always a landscape oriented scan with the film-center close to the image center
3. always scanning from the front-side of the film with the normal orientation (barcode at the bottom of the image, not like in your 1.jpg sample)
4. maybe even generally only one film frame per image?

1. Indeed, we need a good exposure to scan this barcode
2. Usually, yes
3. The film may be reversed horizontally, it depends on which side we're scanning from. The 180° rotation might be ignored.
4. Usually yes, but some applications may need several codes at once and the location...

I don't use perfectly aligned pictures to scan the code from. First I scan my images, then I want to quickly scan the barcode afterward. So I would prefer the application to be fast and accurate, whether the film is reversed vertically or horizontally. But it might not fit other users' needs.

In my case, I would use the phone to scan over the strip to get at least the first match. So... I also think the best solution here is to simply disable this barcode by default and add the "opt-in" feature since the application is very specific.

@axxel I would prefer a detailed review (it will be easier to keep all the changes in one commit, and I will learn from your feedback at the same time), but as you wish! Feel free to detail all the needed changes.

I spent an unexpected amount of time yesterday to fix the performance issue. After my initial guess turned out to be wrong, it took me ages until I figured out where exactly all the time was spent (basically calling the FindLeftGuard multiple time for the same row was the problem). During this debugging I considerably changed the algorithm. And while I was at it, I also simplified the code and used existing tools instead of your new implementation (e.g. toDecimal). And I changed a few names (like "clock signal" -> clock track"). In the end, I touched almost each and every line. I saw no point in detailing all this to you. To make both of our contributions clearly visible in the project history I decided to merge your PR (with the compressed sample images to not bloat the repo unnecessarily) and then later add my changes.

With the current performance the additional DXFilmEdge detector slows down the whole process only about 1%. I see no point in not including it during the standard detection.

From your ToDo list, only the "check the output format" is open in my opinion. Maybe there is a hint in the Kodak patent at how to write down those 3 numbers in a string?

Thanks a lot for your work on this and welcome as a new contributor.