Any way to change volume bar colors by comparing consecutive volumes, not by prices

[milekey]

Hello.

Are there any way to change volume bar colors by comparing consecutive volumes, not by prices?

If today's volume >= yesterday volume, GREEN volume bar
If today's volume < yesterday volume, RED volume bar

Thanks.

[sanykiv]

I'd like to work on this. Proposed approach: add an opt-in so volume bars are
colored by volume change (today's volume vs the previous bar's) instead of by
price direction — green when volume[i] >= volume[i-1], red otherwise.

This can reuse the existing _updown_colors(...) helper in plotting.py by
passing the previous-volume and current-volume arrays in place of opens/closes,
gated behind a new kwarg (e.g. volume_updown='volume', defaulting to the
current 'price' behavior) so existing plots are unchanged.

@DanielGoldfarb does this approach sound acceptable, and do you have a preferred
kwarg name/API? Happy to add a short example and a regression test.

[DanielGoldfarb]

@sanykiv - Thank you for you interest in mplfinance and your work proposal. Your proposal sounds great. I would encourage you to first read Issue #246 about kwarg vcdopcod (volume color depends on price change on day). You are now effectively proposing vcdoVcod (volume color depends on volume change on day. That kwarg was created when it was pointed out to me that Schwab and Yahoo finance charts color the volume bars based on the previous day's price (instead of the same as candles based on today's open vs close) and so I wanted the canned styles "charles" and "yahoo" to match correctly.

We have a couple of choices, because now, with your proposal, we have essentially three states (other than fully custom).
The simplest thing to do would be to add kwarg vcdovcod - I'm not thrilled with the name, as it is easily confused with vcdopcod, and we would have to force users to set vcdopcod to None or document that if vcdovcod is True then it takes priority; that's all kind of messy.

Alternatively we could add a new kwarg that handles all three states (and any future states), something like:
volume_color_updown_dependancy with allowed values such as "Open vs Close", "Previous Close", "Previous Volume". This is cleaner in that it is more transparent and explicit to the caller, but it leaves open what to do with the old vcdopcod kwarg: some of the styles use it, and it is not known whether any mplfinance users use it. We could add a deprecation warning. Or, perhaps all volume colorization code only looks at only the new kwarg, but to be backwards compatible, as soon as plot is called it looks for the kwarg or in the style dict and if vcdopcod is True and volume_color_updown_dependancy is None or "Open vs Close" (depending what we choose as the default value) then it changes it to "Previous Close". I hope this is making sense. Deciding what to do with the old kwarg is important: Do we add a deprecation warning with a deadline, or do we try to make it somehow logically backwards and forwards compatible. Let me know your thoughts.

[sanykiv]

Thanks @DanielGoldfarb! I read #246 — so vcdopcod currently lives in the style
dict (no plot / make_mpf_style() kwarg for it yet) and colors the volume bars by
today's close vs the previous close, which is what "charles" and "yahoo" use.

I agree Option B is the cleaner path: a single explicit kwarg scales to all three
current states plus future ones, and avoids the confusing boolean-priority handling
between vcdovcod and vcdopcod.

Concretely I'd propose one setting (exposed as a plot kwarg, a make_mpf_style()
param, and a style-dict key), e.g. volume_color_updown_dependancy, with allowed
values:

• "Open vs Close" — default, current behavior
• "Previous Close" — equivalent to today's vcdopcod=True
• "Previous Volume" — the new behavior from this issue

For backward compatibility (so charles/yahoo and existing user styles keep working
unchanged): at plot time, if the new kwarg is unset and vcdopcod is True (from
kwarg or style dict), map it to "Previous Close"; if the new kwarg is set, it takes
precedence. We could emit a soft DeprecationWarning pointing to the new kwarg while
keeping vcdopcod functional (no hard removal deadline yet), so nothing breaks today.

If that direction and the kwarg name work for you (or if you'd prefer something
shorter), I'm happy to implement it — reusing _updown_colors(...) with the
previous/current volume arrays for the "Previous Volume" case — plus a tutorial
notebook and a regression test.

[DanielGoldfarb]

Sounds good to me. And thanks again for getting involved. Much appreciated.

one last thing which you probably already thought of: while we advertise/document the possible values as "Open vs Close", "Previous Close", and "Previous Volume" ... in the code we should check for these values in a case-insensitive manner. (i.e. volume_color_updown_dependancy.lower() == "blahblahblah") ; if you want, you could also squeeze spaces out, so if someone forgets and doesn't insert the space, or if someone does insert the space, either will work).

[sanykiv]

Visual comparison of the three modes on identical data (only the volume bar
colors differ):

[DanielGoldfarb]

Looks great. And it is clear from looking at the charts that each mode is working correctly.