add simplejpeg

[carlodri]

https://github.com/jfolz/simplejpeg

Checklist

• Title of this PR is meaningful: e.g. "Adding my_nifty_package", not "updated meta.yaml".
• License file is packaged (see here for an example).
• Source is from official source.
• Package does not vendor other packages. (If a package uses the source of another package, they should be separate packages or the licenses of all packages need to be packaged).
• If static libraries are linked in, the license of the static library is packaged.
• Package does not ship static libraries. If static libraries are needed, follow CFEP-18.
• Build number is 0.
• A tarball (url) rather than a repo (e.g. git_url) is used in your recipe (see here for more details).
• GitHub users listed in the maintainer section have posted a comment confirming they are willing to be listed there.
• When in trouble, please check our knowledge base documentation before pinging a team.

Taken from @hmaarrfk's #27270

[github-actions]

Hi! This is the staged-recipes linter and I found some lint.

File-specific lints and/or hints:

• recipes/simplejpeg/recipe.yaml:
  • lints:
    • The following maintainers have not yet confirmed that they are willing to be listed here: hmaarrfk. Please ask them to comment on this PR if they are.

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipes/simplejpeg/recipe.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipes/simplejpeg/recipe.yaml:

• ℹ️ No valid build backend found for Python recipe for package simplejpeg using pip. Python recipes using pip need to explicitly specify a build backend in the host section. If your recipe has built with only pip in the host section in the past, you likely should add setuptools to the host section of your recipe.
• ℹ️ PyPI default URL is now pypi.org, and not pypi.io. You may want to update the default source url.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/14036284618. Examine the logs at this URL for more detail.}

[carlodri]

@hmaarrfk let me know if you want to maintain or if I should remove you 🙂

UPDATE: I have removed you for the moment if you want to be added let me know

[github-actions]

Hi! This is the staged-recipes linter and your PR looks excellent! 🚀

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipes/simplejpeg/recipe.yaml) and found it was in an excellent condition.

[hmaarrfk]

I've muted notifications. please ping again whe nready.

[carlodri]

@hmaarrfk this is ready for review if you are available

[hmaarrfk]

I need to triple check but I feel like you are using a vendor we jpeg turbo and not. Conda forges

https://github.com/jfolz/simplejpeg/blob/c6051d5984987bc2a7f476778cde339a87711412/setup.py#L184

[carlodri]

Indeed. We can remove it from the deps. 'simplejpeg' is tailored around a specific 'libjpeg-turbo' commit, I think. Not sure if there is any way to use conda-forge's.

[hmaarrfk]

no, I would rather that the work to unvendor it be done. it shouldn't be so specific, libjpeg-turbo is quite stable in terms of abi.

[hmaarrfk]

I am also curious what packages actually depend on simplejpeg, could you please point me to them?

In my experience, they have been drawn to simplejpeg since opencv and PIL as released on PyPi use jpeg and not jpegturbo.

However, we use jpegturbo for both, and thus the featureset is quite expansive for PIL and opencv.

[carlodri]

My goal is to package picamera2, which depends on simplejpeg. I started an attempt to migrate to pyturbojpeg in this PR raspberrypi/picamera2#1254 (some discussion here), but there are some parts I would need to better understand so I would rather package simplejpeg for the moment.

[hmaarrfk]

would rather package simplejpeg for the moment.

ok there are 2 choices:

1. Elevate your PR to unvendor jpegturbo library at conda-forge (i was too lazy to do this in my PR so I gave up)
2. Eleveate your PR to allow a new backend of jpegturbo you need to fix https://github.com/raspberrypi/picamera2/blob/fb031cb49cb2af4dab7439be7a90784c9d3db1ab/picamera2/encoders/jpeg_encoder.py#L48
3. release this on your own channel.

I personally think you should replace the simplejpeg with PIL or OpenCV. its just as fast in my personal benchmark

Ideas for how to replace that function:
https://github.com/vispy/jupyter_rfb/blob/main/jupyter_rfb/_jpg.py#L102

[carlodri]

I can give a try at point 1.

My preference would be indeed point 2, but it is not so simple, see another place where simplejpeg is used:

https://github.com/raspberrypi/picamera2/blob/382be3a5555a7e579df6565d9b0af6a420c029a4/picamera2/request.py#L217

where picamera2 uses some tricks inside simplejpeg to handle YUV with different chroma subsampling schemes.

[carlodri]

@conda-forge/staged-recipes this is ready for review.

I know it is not nice but the patches and work to be done to un-vendor libjpeg-turbo are too much effort for me. I tried to add also the libjpeg-turbo licenses as properly as possible.

CC @traversaro @wolfv I've noticed that you were interested in the raspberry pi camera stuff here conda-forge/libcamera-feedstock#7 so I'm CC-ing you since this would enable to package picamera2 on conda-forge and finally solve its dependency hell moving away from apt. Not sure if you are interested though.

[github-actions]

To help direct your pull request to the best reviewers, please mention a topic-specifc team if your recipe matches any of the following: conda-forge/help-c-cpp, conda-forge/help-cdts, conda-forge/help-go, conda-forge/help-java, conda-forge/help-julia, conda-forge/help-nodejs, conda-forge/help-perl, conda-forge/help-python, conda-forge/help-python-c, conda-forge/help-r, conda-forge/help-ruby,or conda-forge/help-rust. Thanks!

[traversaro]

@conda-forge/staged-recipes this is ready for review.

I know it is not nice but the patches and work to be done to un-vendor libjpeg-turbo are too much effort for me. I tried to add also the libjpeg-turbo licenses as properly as possible.

CC @traversaro @wolfv I've noticed that you were interested in the raspberry pi camera stuff here conda-forge/libcamera-feedstock#7 so I'm CC-ing you since this would enable to package picamera2 on conda-forge and finally solve its dependency hell moving away from apt. Not sure if you are interested though.

fyi also @elephantum

[github-actions]

To help direct your pull request to the best reviewers, please mention a topic-specifc team if your recipe matches any of the following: conda-forge/help-c-cpp, conda-forge/help-cdts, conda-forge/help-go, conda-forge/help-java, conda-forge/help-julia, conda-forge/help-nodejs, conda-forge/help-perl, conda-forge/help-python, conda-forge/help-python-c, conda-forge/help-r, conda-forge/help-ruby,or conda-forge/help-rust. Thanks!

[hmaarrfk]

Fingers crossed.

[hmaarrfk]

Are you ok with these changes?

[carlodri]

Are you ok with these changes?

Great work, thanks @hmaarrfk! My only observation is that libjpeg-turbo is pinned to 3.1.0 in the library source, so we should probably do the same here.

[carlodri]

all good for me, can be merged

[hmaarrfk]

Are you ok with these changes?

Great work, thanks @hmaarrfk! My only observation is that libjpeg-turbo is pinned to 3.1.0 in the library source, so we should probably do the same here.

In short. No.

In long. Library maintainers usually pin the version they last used when developing the code. They don’t always have time to keep up with updates, security and bug fixes. By using dynamically linked libraries and taking care of matching the application binary interface (ABI) we can ensure that libraries function correctly while staying up to date, often more updated than upstream.

[wolfv]

Thank you so much @hmaarrfk for helping this one!