Client Side Image Enhancement

[subdavis]

Client-side image enhancements that can be used to adjust the contrast within grayscale images. previous tools "had a range slider that controlled dynamic range to cut out high-end or low-end of pixels. Had 2 sliders to control min, max, and center of range."

<FeComponentTransfer> filter for SVG should help with this using a type='linear with a slope and intercept to adjust the low white and high black points. With this linear slope you should be able to condense the the range of the white/black pixels.

This component could help: https://github.com/Kitware/UPennContrast/blob/master/src/components/ImageViewer.vue This was designed for more complicated higher bit imagery but I believe the basics are in there for the remapping of the low and high points of an image.

See discussion notes: https://www.notion.so/Meeting-Notes-286fa21b125142e098c08006464f9780#178add01f7c74bb8ba7ed9d565b1b8da

[BryonLewis]

initial testing of the system and need to decide on scoping of the issue.

https://user-images.githubusercontent.com/61746913/158190746-27a17a66-cd6a-464c-b9ea-70e0c938b84e.mp4

• When talking about a "center of range" is this a third point that allows sliding left/right of the other two sliders (I.E. you drag the middle point left two pixels so both the left and right endpoints slide 2 pixels to the left)?
• Do we want to support client side histogram generation so there is a visualization to use with these sliders (or would we consider this out-of-scope or now)?
• Do we want to support sliders for each channel on RGB imagery or only support brightness (all channels)?

[waxlamp]

initial testing of the system and need to decide on scoping of the issue.

testContrast.mp4

• When talking about a "center of range" is this a third point that allows sliding left/right of the other two sliders (I.E. you drag the middle point left two pixels so both the left and right endpoints slide 2 pixels to the left)?

No need for this, unless someone asks for it specifically. My intuition is that this operation of moving the entire range is not usually useful; in the vast majority of cases, people will want to manipulate each end of the range in isolation in order to investigate how each affects the image.

• Do we want to support client side histogram generation so there is a visualization to use with these sliders (or would we consider this out-of-scope or now)?

Out-of-scope for a first attempt.

• Do we want to support sliders for each channel on RGB imagery or only support brightness (all channels)?

Don't worry about RGB. The right way to handle color images is likely not to include three separate sliders, so let's wait until there's a need to deal with color images.

[subdavis]

This looks awesome. Agree with Roni's comments.

There will be conflicts with #1188 because I had to change how the sidebar context worked to enable web to register a sidebar component not in dive-common. It should be minor to resolve, but just FYI.

[BryonLewis]

Additional quick question. I'm guessing this should be stored in the meta data for the dataset like the typeStyling? Something we want persisted on the dataset between different users and set by the owner of the dataset?

[waxlamp]

I know we talked about this on Tuesday, but just for the record: we decided that a first pass could avoid persisting this setting altogether, and in a future iteration we can gather requirements to see what users actually need of persistence.