Data compression
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 20/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Cần làm rõ
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- python
- Lĩnh vực
- data, performance
Hướng nghiên cứu
Bắt đầu bằng việc đọc thảo luận về nén TRX và các issue được tham chiếu là dipy/dipy#2229 và nipy/nibabel#942. So sánh các tùy chọn được liệt kê, bao gồm lưu trữ bằng float16, downsampling, nén thư mục thành các tệp ZIP và các chiến lược trong định dạng; công việc chỉ hoàn tất khi đã thống nhất được một định hướng nén cụ thể, vì issue này không xác định mục tiêu triển khai hoặc kiểm thử.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Given recent comments in dipy/dipy#2229, and further back in nipy/nibabel#942, I think it is worth dedicating a discussion thread to the issue of data compression.
I think it is fair to say that this particular format proposal has prioritised extensibility and simplicity over compression. But for some users / developers the latter may be the higher priority. So here we can discuss whether the gains in this department from the current TRX proposal are adequate, whether it is possible to bootstrap any kind of explicit data compression into this format proposal, or whether a drastically different proposal would be necessary in order to satisfy such demands.
Please amend or correct as necessary, and comment as you see fit.
Where compression may be possible in TRX:
- Use of float16's for vertex locations -> halves storage over float32
- No need for delimiters -> one less vertex per streamline compared to delimiter-based formats, though explicitly storing offsets reduces that gain slightly
- Compatible with downsampling, i.e. storing less vertices per streamline than what was used in generation of the streamline; this can be a naive integer factor reduction in vertex count, or based on estimation of error accumulation (e.g. https://www.sciencedirect.com/science/article/pii/S1053811914010635); in either case for algorithms with small step size this can be the primary source of storage reduction
- Zipping of full directory structure (albeit depending on implementation this may impact IO substantially), though yields with this tend to be minimal due to the nature of the data
- Support for more dedicated compression strategies as in-place alternatives for vertex position (or indeed DPP / DPS / DPG) data within TRX.
Point 5 may be interesting to explore: there's been a number of manuscripts published explicitly on storage reduction of streamline vertex information, so simply having the option to utilise within TRX one such format for vertex position information would theoretically be possible. It would make the technical specification considerably more complex, but technically one could defer to external specifications for datasets doing such. I'm not a fan of this personally, I'm simply stating that it's a prospect.
In the converse case, i.e. a format from the ground up that would prioritise compression: A couple of these already exist, but don't have the extensibility of TRX. Trying to extend the capabilities of compressed streamline data storage could look something like bootstrapping compression into the .trk format, or it could be something entirely novel. It probably falls upon someone who prioritises such to propose something that still has a chance of satisfying the desires of those prioritising extensibility. But this is likely one of multiple dimensions of difference that caused the original discussion in nipy/nibabel#942 to go slightly astray, so warrants greater precision here.
- Ngôn ngữ chính
- Python
- Star
- 27
- Fork
- 20
- Merge trung bình
- 2 ngày 25 phút
- Pull request đã merge (30 ngày)
- 1
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của tee-ar-ex/trx-python
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 45/100
tee-ar-ex/trx-python#85 · 1 reaction ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 25/100
tee-ar-ex/trx-python#77 · 1 bình luận ·
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
tee-ar-ex/trx-python#72 · 3 bình luận ·
-
Circular Dependency for DIPY ?Đang mở
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
tee-ar-ex/trx-python#51 · 23 bình luận ·
-
Allow other types into `append`Đang mởgood first issue
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
tee-ar-ex/trx-python#39 · 1 bình luận ·
Tất cả issue của tee-ar-ex/trx-python
Issue tương tự
-
`LazyFrameRemote` and `ExecuteRemote` sinks do not accept `Path`, like `LazyFrame` sinks do.Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
WingedGuardian/GENesis-AGI#3375 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
curriculum documentation quality
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
githubnext/gh-aw-workshop#4601 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
approved Good First Issue scope: docs
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 85/100
hiero-ledger/hiero-sdk-python#2730 · 3 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày