Is it normal for `branca.utilities.write_png` function to normalize its values?
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 42/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- numpy, python
- Domain
- data-visualization
Research direction
Start in branca/utilities.py at write_png, using the linked line and the supplied NumPy/PIL example to reproduce the current output. Done means deciding and verifying the intended normalization behavior for mono, non-mono, and colormapped rasters, including the reported brightness effect in folium ImageOverlay layers.
Written by the indexing model from the issue text.
Description
I may be wrong, but I find it weird the way branca.utilities.write_png function normalize its values.
See https://github.com/python-visualization/branca/blob/v0.8.1/branca/utilities.py#L324.
>>> import io
>>>
>>> import numpy as np
>>> import PIL.Image
>>>
>>> import branca.utilities
>>>
>>> data = np.array([[[0.74901961, 0.50196078, 1.0, 1.0], [0.25098039, 1.0, 0.74901961, 1.0]]])
>>>
>>> # Current result
>>> png_bytes = branca.utilities.write_png(data)
>>> with PIL.Image.open(io.BytesIO(png_bytes)) as image:
... np.asarray(image)
array([[[255, 127, 255, 255],
[ 85, 255, 191, 255]]], dtype=uint8)
>>>
>>> # What I expected
>>> np.rint(data * 255.0).astype(np.uint8)
array([[[191, 128, 255, 255],
[ 64, 255, 191, 255]]], dtype=uint8)
As a result, folium layers like folium.raster_layers.ImageOverlay appear brighter than I expected when passing image as an array because of the normalization.
I guess this allows users to automatically display mono rasters with a scale from minimum value as black to maximum value as white. However, for non-mono and mono rasters with a colormap, the normalization seems undesirable.
- Dominant language
- Python
- Stars
- 134
- Forks
- 69
- Avg merge
- 1h 10m
- Merged PRs (30d)
- 1
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from python-visualization/branca
-
Difficulty 2/5 1-3 hours Newbie friendliness 58/100
python-visualization/branca#222 · 1 comment ·
-
Difficulty 3/5 1-2 days Newbie friendliness 45/100
python-visualization/branca#213 · 1 comment ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 45/100
python-visualization/branca#190 · 6 comments ·
-
Difficulty 3/5 1-2 days Newbie friendliness 35/100
python-visualization/branca#182 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 30/100
python-visualization/branca#174 · 9 comments ·
All issues in python-visualization/branca
Similar issues
-
essnmx good first issue
Difficulty 1/5 Under an hour Newbie friendliness 95/100
-
[Feature] 奇物选择添加优先级 Open
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
syfoud/Simulated_Scepter#174 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Giskard-AI/giskard-oss#2840 · 1 comment ·
-
A claim comment carrying the issue number is silently declined while the workflow reports success Openarea: repo bug perceived difficulty: 2
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
yeti-platform/yeti#1380 ·