Repository navigation
Any way to change volume bar colors by comparing consecutive volumes, not by prices #680
Description
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.
Activity
[-]Any way to change bar colors by comparing consecutive volumes, not by prices[/-][+]Any way to change volume bar colors by comparing consecutive volumes, not by prices[/+]sanykiv commentedon Jul 17, 2026
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 inplotting.pybypassing the previous-volume and current-volume arrays in place of opens/closes,
gated behind a new kwarg (e.g.
volume_updown='volume', defaulting to thecurrent
'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 commentedon Jul 17, 2026
@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 proposingvcdoVcod(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 setvcdopcodto None or document that ifvcdovcodis 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_dependancywith 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 oldvcdopcodkwarg: 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 ifvcdopcodis True andvolume_color_updown_dependancyis 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 commentedon Jul 17, 2026
Thanks @DanielGoldfarb! I read #246 — so
vcdopcodcurrently lives in the styledict (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
vcdovcodandvcdopcod.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 allowedvalues:
vcdopcod=TrueFor backward compatibility (so charles/yahoo and existing user styles keep working
unchanged): at plot time, if the new kwarg is unset and
vcdopcodis True (fromkwarg 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
vcdopcodfunctional (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 theprevious/current volume arrays for the "Previous Volume" case — plus a tutorial
notebook and a regression test.
DanielGoldfarb commentedon Jul 17, 2026
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 commentedon Jul 17, 2026
Visual comparison of the three modes on identical data (only the volume bar
colors differ):
DanielGoldfarb commentedon Jul 17, 2026
Looks great. And it is clear from looking at the charts that each mode is working correctly.