Base2Tone vs DuoTone, Clarifications

[tajmone]

Frist of all, thanks for these schemes and project, they are awesome. Well done.

I wanted to ask you some clarifications on the relation between DuoTone themes and Base2Tone schemes. In the README you mention:

The light version of the Morning theme, and dark versions of Evening, Sea, Space, Earth and Forest were converted from DuoTone Themes for Atom by Simurai. Morning and Evening are the default Duotone Light and Duotone Dark schemes, but renamed here in order to have a consistent naming convention.

I've compared the colours in base2tone-earth.yml with those of the (compiled) DuoTone Dark Earth Theme but I've noticed that actual colour values differ.

Or is it me that I've done something wrong in extracting the final colours of the DuoTone themes? i.e. the Base2Tone schemes ported from DuoTone themes should contain all the base colours of the original scheme.

I'm asking because I wanted to create a unified collection of DuoTone schemes, but adopting the Base2Tone convention of storing 32 colours in a YAML file — as opposed to the LESS based approach used in the DuoTone Themes.

If I've understood correctly, the main difference between the two projects is that DuoTone relies entirely on procedural generation of the whole scheme from two base hues via colour formulas (in LESS), whereas Base2Tone schemes are manually edited before release.

What is not clear from the README and Issue #1 is how you actually generate the base scheme from those two hues — i.e. how the actual conversion was achieved:

… and Forest were converted from DuoTone Themes for Atom by Simurai.

I've understood that you manually tweak the colours of the generated Sass scheme until you're pleased with their perceptual appearance, but I'd like to understand better how you manipulate the two base hues to derive the 32 colours scheme in the initial stage — DuoTone themes rely on LESS to generate them.

Also, if I've understood correctly, some of the schemes in this project were ported from @simurai's DuoTone, while others where designed by you. Did you use a same formula/script to generate both types of schemes from two starting hues?

I suggest to update the README regarding the relation between the original DuoTone Themes that have been included in this project with the same name, to avoid confusion.

For example, I originally thought that I could contribute to this project by adding more new DuoTone themes for Atom that I've come across, created by third parties via @simurai's duotone-syntax template, only to discover that they don't fully overlap — in other words, you can't just take the two base hues from a DuoTone based project and auto-magically generate a Base2Tone scheme that will match the exact colours of the upstream project from which they were taken (or so it seems).

[atelierbram]

On different color values between the original Atom themes by Simurai and my converted themes: I'm sure there will be some. Some reasons for this:

• My versions of Simurai's themes are based on the first implementation of the themes in Atom, if there were any changes after this, then my themes won't reflect those.
• The inner consistency of the themes themselves: trying to have the same amount of lightness - as in HSL - difference between 32 color values of the schemes. It's a balance, you want to be true to the original, but at the same time one is creating color schemes that needs to be consistent: they have to relate to each other in tonal contrast.

I'd like to understand better how you manipulate the two base hues to derive the 32 colours scheme in the initial stage

I'm afraid there's no secret here, just keep adjusting color values until it's right, it can take hours manually tweaking and using tools like HSL color picker, but also web developer tools. I always begin in Prism which gives the best insight and most immediate feedback.

Also, if I've understood correctly, some of the schemes in this project were ported from @simurai's DuoTone, while others where designed by you. Did you use a same formula/script to generate both types of schemes from two starting hues?

It was a puzzle, but that's what I like to do: problem solving. I started with the default dark theme, but also with an eye on the other themes, Space, Forest, Earth trying to get them in 32 color values. Made a dark theme out of the default duotone light theme, which was fun.
I already had some ideas of my own, and this setup of 32 color values made it convenient to create those. Again just manually handpicking like I described earlier, no "formula/script" to generate anything, just the naked eye and adjusting until the contrast is right.

I suggest to update the README regarding the relation between the original DuoTone Themes that have been included in this project with the same name, to avoid confusion.

Maybe I keep this issue open for a while for the confused.

in other words, you can't just take the two base hues from a DuoTone based project and auto-magically generate a Base2Tone scheme that will match the exact colours of the upstream project from which they were taken (or so it seems)

That's right, no magic involved here: it will take a dedicated effort to convert these to/with Base2Tone, but not impossible though ;) Base2Tone is just a templating system which uses these 32 colors as variables, one will have to dig in to create their own.

[tajmone]

Thanks a lot for detailed explanation.

I'm a co-maintainer of the Highlight project, and I've already ported all the Base16 schemes and simurai's DutoTone Themes to Highlight themes. Originally I was planning to add your schemes to the (already ported) DuoTone themes, but now I realize I should instead create a new set of themes with the Base2Tone prefix and name — for they are independent themes in their own right, even though they share some base colours in the ported DuoTone schemes.

I'd like you to know that I greatly appreciate your method in working with colour, it brings quality in a world dominated by machine algorithms, and sets a good example on how colours should be treated with respect and "felt" (as opposed to digitally rationalizing them). I'm all-in for the old school approach to colour (feeling them, keep experimenting, tuning them by our inner responses, and trust gut-feelings regarding them), along with a sound (or at least basic) knowledge of colour theory and digital best practices (monitor and other devices calibration, etc.).

By the way, I've come across your name many times in the past years, due to your contributions to Base16 schemes, which have proliferated in a multitude of derivative works (including Highlight themes) which credit you.

Again, thanks! and keep up the good work.