Hi @Lucas-C I added support for compression using LZWDecode, and I would like you to look at my code and give your opinion. I tested this filter manually by adding images compressed with LZWDecode to pdf files, and it seems to work correctly. Local check of pylint and black showed no errors. After the review, if the code is ok, I could write unit tests.

Hi @Lucas-C I added support for compression using LZWDecode, and I would like you to look at my code and give your opinion. I tested this filter manually by adding images compressed with LZWDecode to pdf files, and it seems to work correctly. Local check of pylint and black showed no errors. After the review, if the code is ok, I could write unit tests.

Good job 👍

I'll try to review this PR very soon, today or tomorrow.

OK so there is one thing currently blocking in the GItHub Actions pipeline:

6.1.10-1 (1): test/image/image_types/image_types_insert_jpg_lzwdecode.pdf

This is the relevant VeraPDF rule: https://github.com/veraPDF/veraPDF-validation-profiles/wiki/PDFA-Part-1-rules/#rule-6110-1

I think the best fix is to add this rule (6.1.10-1) into verapdf-ignore.json, with reason: fpdf2 wants to support LZWDecode filter`

Thank you for your contribution @opposss 👍

@allcontributors please add @opposss for code

@Lucas-C

I've put up a pull request to add @opposss! 🎉

I noticed today that the unit test test_insert_jpg_lzwdecode is quite slow to execute: ~78s on my computer.

And 90% of this execution is spent in pack_codes_into_bytes() based on this quick test:

pip install pytest-profiling
pytest test/image/image_types/test_insert_images.py -k lzwdecode --profile

I wonder if this could be improved...

@Lucas-C
Apparently there is a problem with encoding large amounts of data in the case of JPEG, in case of PNG and other formats everything seems to work fine.

I changed the implementation pack_codes_into_bytes() a bit, and so far I've only managed to reduce the time from 80s to ~40s.
I will try to improve the performance even more in the coming days.