What's wrong with the current setup? Because the current dialog is built around an '8bpc' interface (note: the backend operates with a higher, bpc-respecting precision), we can run into a few problems:
- There's no way to respect middle gray. Adobe implemented '16bit' editing at 15bpc specifically to allow a true middle gray - but it's almost impossible to maintain when applying a curve.
- You can't change the display size for the window. No zooming in to tweak your curve, no blowing it up for projection / display / teaching purposes, etc. A PITA for projection, IMO.
- You end up restricted to not placing points more than ~5 mapping values apart, remanding fine control of values to multiple curve sets or to be generated through masking of the same. Even though your dataset may allow for and benefit from greater resolution.
What would be better? Simply mapping the backend directly to the interface. Start with the end values, and instead of always being 0 and 255, they become 0 and (1.0 * MODE_MAXVALUE). For 16bpc RGB processing this would mean we would have values from 0 to 32768 (with a pinnable 50% gray!); for 32bpc 0 to 1 (pinnable 0.5); and just as now 8bpc would be 0 to 255. CMYK and LAB would also get the option to display values of 0 to 100 and -1.0 to 1.0 as appropriate. Everything between the end values is of course interpolated to the display size.
What's better is that once the interface is set to be relational between display size and the actual data format, it becomes simple to make the interface scalable and the user can now be allowed to resize the curve window to any size desired, to zoom in and out of the curve ala online mapping programs (scroll wheel!), and to place points as close to one another as is desired (accepting that maximum zoom becomes 1->1 mapping with the actual data resolution). The user might want an option to display curve values as if mapping to different bit depths (8bpc 'traditional', 16bpc for reference, 0.0-1.0 for geeks), and this should again be easy to implement through an addition to the Options dialog.
The one difficult part about this may be the ACV Curves files. I've not been able to dig up the internal data structure, though I suspect given Adobe's historic efficiency and a bit of prodding around a few files that it's simply storing the curve's 8bit values. Obviously this would require revision, likely offering a second data format for newer curves using a pair of floating point values for each point on the curve. There's an outside chance that - depending on how the files are processed internally and whether there is an internal EOF marker in the files - they could store two datasets within the same file, the first down-resolved for legacy purposes and the second containing the floating-point values. That part is to Adobe, though.
If it's something you'd like to see, please let Adobe know.