hsluv / hsluv-python Goto Github PK

My intention is to package hsluv-python to Debian due to a dependency, but our policy requires us not to package generated code but to rebuild them.

I tried to run Haxe by myself, and found that the formats of source code are different, although every function looks like having the same structure:

What I found that the function name and packaging are different than generated code, also the format is a lot cleaner and readable, and I think you did not just remove dead code as you said in the header of hsluv.py.

Could you tell me the details about this?

Hi @boronine,

could it be that you ran setup.py sdist for hsluv 5.0.1 in an environment with setuptools older than version 38.6.0?
I'm asking because the markdown readme rending is broken at https://pypi.org/project/hsluv/ and my guess is that the setuptools used to create the release was too old to understand the explicit markdown mimetime that is needed for markdown to be rendered on PyPI. What do you think?

Best, Sebastian

PS: This is what I see on PyPI:

Hi!

It came to my attention that the two most recent releases to PyPI — 0.0.1 and 0.0.2 — do not have Git tags here. Since https://github.com/hsluv/hsluv-python/releases went up to v4.0.2 for husl, it takes (a) a different namespace or (b) jumping to something bigger than v4.0.3. My recommendation is to use 5.0.0 on PyPI and v5.0.0 for the next Git tag.

What do you think?

Best, Sebastian

Currently hsluv is no longer on pypi, will it be uploaded again?

e.g

>>> import husl
>>> husl.__version__
'4.0.3'
>>> husl.huslp_to_rgb(1,40,100)
[0.9999999999999524, 1.000000000000017, 1.0000000000000127]
>>> husl.husl_to_rgb(1,40,100)
[0.9999999999999524, 1.000000000000017, 1.0000000000000127]'

Originally suggested by @hartwork here: #30 (comment)

I agree with this, but we should do it in the next version, e.g. v5.1.0 so that we can refer Python 2 users to v5.0.1.

Python 3.5, HUSL v4.0.2:

In [8]: r, g, b = 0, 0.6666666666666666, 0.8666666666666667
In [9]: husl.rgb_to_hex((r, g, b))
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-9-bac31aa4bd0c> in <module>()
----> 1 husl.rgb_to_hex((r, g, b))

/usr/lib/python3.5/site-packages/husl.py in rgb_to_hex(triple)
    180 def rgb_to_hex(triple):
    181     [r, g, b] = triple
--> 182     return '#%02x%02x%02x' % tuple(rgb_prepare([r, g, b]))
    183 
    184 

TypeError: %x format: an integer is required, not float

I patched it by adding ret = [int(i) for i in ret] before line 168 in husl.py (before rgb_prepare() returns).

Hey

I hit a bit of a weird wall... when I try running this in my code, I'm getting incorrect results...

offset = int(x * 3)
print(x, "R : ", data[offset], " G : ", data[offset + 1], " B : ", data[offset + 2], "Offset ", offset)
rgb = (reRange(255, 0, 1.0, 0, data[offset]),
       reRange(255, 0, 1.0, 0, data[offset + 1]),
       reRange(255, 0, 1.0, 0, data[offset + 2]))
print("RGB : ", rgb)
hsl = rgb_to_hsluv(rgb)
print("HSL : ", hsl)
hsl[2] = hsl[2] * lumi
# h = hsl[0] * hue
hsl[1] = hsl[1] * sat
print("HSL : ", hsl)
toRgb = hsluv_to_rgb(hsl)
print("pRGB: ", toRgb)
data[offset] = int(reRange(1.0, 0.0, 255.0, 0.0, toRgb[0]))
data[offset + 1] = int(reRange(1.0, 0.0, 255.0, 0.0, toRgb[1]))
data[offset + 2] = int(reRange(1.0, 0.0, 255.0, 0.0, toRgb[2]))
print(x, "R: ", data[offset], " G: ", data[offset + 1], " B: ", data[offset + 2], "\n\n")

Print out is as follows:

319996 R :  14  G :  6  B :  6 Offset  959988
RGB :  (0.054901960784313725, 0.023529411764705882, 0.023529411764705882)
HSL :  [12.177050630062146, 21.184609202372744, 2.138737995579452]
HSL :  [12.177050630062146, 10.592304601186372, 2.138737995579452]
pRGB:  [0.0436894824389459, 0.027017028218122827, 0.027017028218122255]
319996 R:  11  G:  6  B:  6 


319997 R :  255  G :  17  B :  5 Offset  959991
RGB :  (1.0, 0.06666666666666667, 0.0196078431372549)
HSL :  [12.482352433878221, 99.99999999999856, 53.68125203861338]
HSL :  [12.482352433878221, 49.99999999999928, 53.68125203861338]
pRGB:  [0.8152300064437905, 0.358083498149423, 0.35453935730595854]
319997 R:  207  G:  91  B:  90 


319998 R :  5  G :  255  B :  21 Offset  959994
RGB :  (0.0196078431372549, 1.0, 0.08235294117647059)
HSL :  [127.93115964717315, 99.9999999999918, 87.77728072672164]
HSL :  [127.93115964717315, 49.9999999999959, 87.77728072672164]
pRGB:  [0.6067511284818852, 0.9409300618470916, 0.609497221091625]
319998 R:  154  G:  239  B:  155 


319999 R :  7  G :  8  B :  255 Offset  959997
RGB :  (0.027450980392156862, 0.03137254901960784, 1.0)
HSL :  [265.86195104698476, 99.99999999999959, 32.784073217562245]
HSL :  [265.86195104698476, 49.999999999999794, 32.784073217562245]
pRGB:  [0.2621364290105094, 0.2623202526490048, 0.5939211583491713]
319999 R:  66  G:  66  B:  151 

Processing min :  0.0  max :  255.0 Lumi :  1.0  Hue :  0.0  Sat :  0.5

the R G B flips a lot... is this a lib bug or did I miss something?
All it does is change saturation from whatever it is to 50% of it.

I think the conversion functions should return tuples as the colors doesn't need to be mutable.

On create github release entry is created email notification to those whom have set in your repo the web UI Watch->Releases.
gh release can contain additional comments (li changelog) or additional assets like release tar balls (by default it contains only assets from git tag) however all those part are not obligatory.
In simplest variant gh release can be empty because subiekt of the sent email contains git tag name.

I'm asking because my automation process uses those email notifications by trying to make preliminary automated upgrades of building packages, which allows saving some time on maintaining packaging procedures.
Probably other people may be interested to be instantly informed about release new version as well.

Documentation and examples of generate gh releases:
https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository
https://cli.github.com/manual/gh_release_upload/
jbms/sphinx-immaterial#282
https://github.com/marketplace/actions/github-release
https://pgjones.dev/blog/trusted-plublishing-2023/
jbms/sphinx-immaterial#281 (comment)
tox target to publish on pypi and make gh release https://github.com/jaraco/skeleton/blob/928e9a86d61d3a660948bcba7689f90216cc8243/tox.ini#L42-L58

Hi! I package this project for Arch Linux.

We are now relying on upstream provided sources instead of PyPI: https://rfc.archlinux.page/0020-sources-for-python-packaging/

Unfortunately, for 5.0.4 on PyPI there is no related tag in this repository and I am unable to upgrade the package. Can you please add it? :)

Looks like with new pytest 8.0.0 test suite fails.

Something wrong with translate rgb to huslp. huslp must output H(0-360), S(0-100), L(0-100) but husl.rgb_to_huslp(0.6666666666666666, 0.3215686274509804, 0.7607843137254902) output 295.94701360615693, 204.03762706932616, 50.06910179946446

Channel saturation is wrong?

Hi! Similar to the missing LICENSE.txt (#28), the tests are also missing in the source tarball on pypi.org.

Tests are fairly important for downstreams (such as Linux distributions), so that they can ensure software integrates with the existing ecosystem (e.g. python interpreters, etc.).
It would be very awesome, if you could add them!

Hi! I'm packaging hsluv for Arch Linux.
To be able to distribute the package, I require the license file, that is contained in this repository.
Unfortunately it is not contained in the source tarball on pypi.org

Hi @boronine

I noticed at https://github.com/hsluv/hsluv-python/commits/master that the latest commit did not get CI coverage by Travis any more. I suggest we re-do CI with GitHub Actions, I could do the work if desired. What do you think?

Best, Sebastian

Hello, the tarball from pypi doesn't include the files LICENSE and README.md
To include them in the distribution tarball you wil lneed to create a MANIFEST.in file with someting like

include README.md
include LICENSE