Thread max_colors from API request through pipeline to raster quantizer #104
Labels
No labels
blocked:children
blocked:depends-101
blocked:depends-103
blocked:depends-104
blocked:needs-attention
blocked:needs-decision
blocked:no-changes
blocked:preflight
bug
chore
feature-request
in-progress
lint-cleanup
needs-decompose
performance
quality
quickfix
security/medium
triage-approved
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
Mark/easystitch#104
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Goal
Wire the
max_colorssetting from thePOST /v1/digitizeAPI request all the way through the pipeline to the new raster quantizer added in ch1. Currently,max_colorsis passed toPhysicalOptimizerbut not to the raster/vector stage.Approach
max_colorsto the pipeline config/context object passed from the API handler throughmain_pipeline.py.max_colorsfrom the digitize request settings insrc/service/handlers/digitize.py.src/pipeline_api.pyandsrc/main_pipeline.pytosrc/raster/raster_converter.py.Acceptance Criteria
max_colorsfromPOST /v1/digitizesettings reaches the raster quantizerPhysicalOptimizerstill getsmax_colorsas before (backward compat)POST /v1/digitizewithmax_colors=4produces ≤4 thread colorsFiles touched
src/service/handlers/digitize.pysrc/main_pipeline.pysrc/pipeline_api.pysrc/raster/raster_converter.pyDecomposed from Mark/easystitch#101