When interviewing Python programming candidates, my wife always likes to ask the simple question, “can you name ten Python standard library modules?” This is harder than most think, as many people will completely blank out and others will be dead wrong. “Requests?” one poor soul answered. It’s a good interview question, as it gives insight onto what people are familiar with and may use regularly. So I sat down and though of of which ones I use and enjoy the most. So here are my top ten(ish) useful, favorite and unordered standard modules.
pathlib
Back in the dark days, you would have to store your path as a string, and call obscure functions under os.path to figure anything out about it. Pathlib removes the headache.
from pathlib import Path
my_path = Path('text_file.txt')
if not my_path.exists():
my_path.write_text('File Content')
assert my_path.exists()
assert my_path.is_file()
There are a boatload of uses for a temporary file or directory. Hence why it’s in the standard library. I find myself using them together, inside context managers more often than not.
from pathlib import Path
from tempfile import TemporaryDirectory, TemporaryFile
with TemporaryDirectory(prefix='Code_', suffix='_Calamity') as temp_dir:
with TemporaryFile(dir=temp_dir) as temp_file:
temp_file.write(b'Test')
temp_file_path = Path(temp_file.name)
assert temp_file_path.exists()
# Make sure file only exists within the context
assert not temp_file_path.exists()
I usually end up using this when a tool or library wants to work with a file rather than standard input, so short lived files in a context manager make life a lot easier. Tempfile python docs.
subprocess
Python is pretty amazing, but sometimes you do need to call other programs. Subprocess makes it easy to execute and interact with other executable across operating systems. Check out my other post on it!
from subprocess import run, PIPE
response = run("echo 'Join the Dark Side!'", shell=True, stdout=PIPE)
print(response.stdout.decode('utf-8'))
# 'Join the Dark Side!'
logging
This is probably the most useful built in library for debugging there is, and I see it either unused or misused more than anything else.
Two very different things for widely different uses, but they have very similar interfaces and easy to talk about at the same time. Quick and dirty difference: Use threading for IO heavy tasks (writing to files, reading websites, etc) and multithreading for CPU heavy tasks.
from multiprocessing.pool import ThreadPool, Pool
def square_it(x):
return x*x
# On Windows, make sure that multiprocessing doesn't start
# until after "if __name__ == '__main__'"
# Pool and ThreadPool are interchangable in this example
with Pool(processes=5) as pool:
results = pool.map(square_it, [5, 4, 3, 2 ,1])
print(results)
# [25, 16, 9, 4, 1]
The Python world would not exist if we didn’t have all the power and functionality these built-ins bring. You really haven’t coded in Python if you haven’t used these yet, so I won’t even bother elaborating them here.
random and uuid
Maybe you’re making a game…
import random
random.choice(['Sneak Attack', 'High Kick', 'Low Kick'])
Or debugging a webserver…
from uuid import uuid4
# Bad example, but not writing out a whole webserver to prove a point
def get(*args):
request = uuid4()
logger.info(f'Request {request} called with args {args}')
Or turning your webserver into your own type of game…
if user_name == 'My Boss':
time.sleep(random.randint(1, 5))
No matter which you are doing, it’s always handy to have randomly generated or unique numbers.
socket
The internet runs because of sockets. Modern technology exists because of sockets. Sockets are life, sockets are….annoying low level at times but its good to know the basics so you can appreciate everything written on top of them.
Need to check a file’s integrity? Hashlib is there with md5 and sha hashes! I created a reusable function to easily reference when I need to do it.
Need to securly store people’s password hashes for a website? Hashlib now has scrypt support! Heck, here is my own function I always use to generate the scrypt hashes.
from collections import namedtuple
import hashlib
import os
Hashed = namedtuple('Hashed', ['hash', 'salt', 'n', 'r', 'p', 'key_length'])
def secure_hash(value: bytes, salt: bytes = None, key_length: int = 128, n: int = 2 ** 16, r: int = 8, p: int = 1):
maxmem = n * r * 2 * key_length
salt = salt or os.urandom(16)
hashed = hashlib.scrypt(value, salt=salt, n=n, r=r, p=p, maxmem=maxmem, dklen=key_length)
return Hashed(hash=hashed.hex(), salt=salt.hex(), n=n, r=r, p=p, key_length=key_length)
venv
You probably only think of it as a command when you run python -m venv python_virtual_env to create your environments, but it’s run that way because it’s a standard library. Every new project you start or Python program you install should be using this library, so it is used a lot!
Summary
There ya go, 10 or so can’t live without standard libraries! Isn’t it so nice that Python comes “batteries included”?
First, straight to the fun, download FastFlix here to try it out! (Windows only builds right now). FastFlix started out to be a small clip and GIF maker for myself, but quickly realized I could expand it for larger usage. And it just so happens that AV1 is an emerging codec that doesn’t have a lot of GUI options yet, it’s like it was meant to be!
The main GUI
Before going out and re-encoing everything with AV1, which will be the next standard codec as everyone is on board with it, there are a few catches, so make sure to read on
What makes FastFlix unique?
AV1 Support for multiple libraries
FastFlix is designed as a general command wrapper, so it can support multiple different programs. Right now it supports both the libaom-av1 and SVT-AV1 libraries.
Totally MIT open source code, reuse to your hearts content!
Unlike most converts that are limited to the GPL license thanks to the libx265/libx264 libraries and others, FastFlix has been designed in a way to keep it legal to steal use any of it’s core code in your own projects without forcing them to be open source.
Extensible
FastFlix was designed to have a plug in architecture. That way anyone can develop or use their own plugins on top of what is already available to bring additional functionally.
What’s the catch?
New program using an experimental codec
There will be bugs. Both on the GUI side and on the codec side. Report anything weird you see and we’ll try to figure out it’s a GUI problem or needs to be passed along to the codec team.
SVT-AV1 makes it difficult to convert videos
Right now SVT-AV1 requires the source input to be broken up to smaller chucks (if it is longer than the segment size) as raw YUV video, which can take up gigabytes of space. They are automatically cleaned up as it goes along, but it is still silly that SVT-AV1 cannot take a regular video file as input yet.
I’m just one guy, and this is a side project
I don’t make any money (nor take donations. $10K+ bribes, please email me 😉) and FastFlix is not something I will spend all my free time on. So I am always looking for help and feedback!
Wrapping up
Please give a github star if you like FastFlix and be sure to send your love to SVT-AV1 as well if you find their program useful!
For those of you interested more in how FastFlix works or was created I hope to do a follow up post that goes into using PySide2 and the full workflow of using Appveyor to deliver releases.
There is currently a serious lack of data on compressing 4K HDR videos out there, so I took it upon myself to get learned in the ways of the x265 encoding world.
I have historically been using the older x264 mp4s for my videos, as it just works on everything. However most devices finally have some native h.265 decoding. (As a heads up h.265 is the specification, and x265 is encoder for it. I may mix it up myself in this article, don’t worry about the letter, just the numbers.)
Updated: 4/14/2019 – New Preset Setting (tl;dr: use slow)
What are the best settings for me to use when encoding x265 videos?
The honest to god true answer is “it depends”, however I find that answer unsuitable for my own needs. I want a setting that I can use on any incoming 4K HDR video I buy.
I mainly use Handbrake to encode my videos, so I went straight to their documentation. It states that for 4K videos with x265 they suggest a Constant Rate Factor (CRF) encoding in the range of 22-28 (the larger the number the lower the quality).
Through some experimentation I found that I personally never can really see a difference between anything lower than 22 using a Slow present. Therefore I played it safe, bump it down a notch and just encode all of my stuff with x265 10-bit at CRF of 20 on Slow preset. That way I know I should never be disappointed.
Then I recently read YouTubes suggest guidelines for bitrates. They claim that a 4K video coming into their site should optimally be 35~45Mbps when encoded with the older x264 codecs.
Now I know that x265 can be around 50% more efficient than x264, and that YouTube needs it higher quality coming in so when they re-compress it it will still look good. But when I looked at the videos I was enjoying just fine at CRF 22, they were mostly coming out with less than a 10Mbps bitrate. So I had to ask myself:
How much better is x265 than x264?
To find out I would need a lot of comparable data. I started with a 4K HDR example video. First thing I did was to chop out a minute segment and promptly remove the HDR. Thus comparing the two encoders via their default 8-bit compressors.
I found this code to convert the 10-bit “HDR” yuv420p10le colorspace down to the standard yuv420p 8-bit colorspace from the colourspace blog so props to them for having a handy guide just for this.
Then I ran multiple two pass ABR runs using ffmpeg for both x264 and x265 using the same target bitrate. Afterwards compared them to the original using the Structural Similarity Index (SSIM). Put simply, the closer the result is to 1 the better. It means there is less differences between the original and the compressed one
Generated via Python and matplotlib (Click to view larger version)
The SSIM result is done frame by frame, so we have to average them all together to see which is best overall. On the section of video I chose, x264 needed considerably more bitrate to achieve the same score. The horizontal line shows this where x264 needs 14Mbps to match x265’s 9Mbps, a 5000kbps difference! If we wanted to go by YouTube’s recommendations for a video file that will be re-encoded again, you would only need a 25Mbps x265 file instead of a 35Mbps x264 video.
However the averages don’t tell the whole story. Because if every frame was that good, we shouldn’t need more than 6Mbps x265 or 10Mbps x264 4K video. So lets take a step back and look at the lowest 1% of the frames.
Generated via Python and matplotlib (Click to view larger version)
Here we can see x264 has a much harder time at lower bitrates. Also note that the highest marker on this chart is 0.98, compared the total average chart’s 0.995.
This information alone confirmed for me that I will only be using x265 or newer encodings (maybe AV1 in 2020) for storing videos going forward.
I have always read to use Constant Rate Factor over Average BitRate for stored video files (and especially over Constant Quality). CRF is the best of both worlds. If you have an easily compressible video, it won’t bloat the encoded video to meet some arbitrary bitrate. And bitrate directly correlates to file size. It also won’t be constrained to that limit if the video requires a lot more information to capture the complex scene.
But that is all hypothetical. We have some hard date, lets use it. So remember, Handbrake recommends a range of 22-28 CRF, and I personally cannot see any visual loss at CRF 20. So where does that show up on our chart?
Generated via Python and matplotlib (Click to view larger version)
Now this is an apples to oranges comparison. The CRF videos were done via Handbrake using x265 10-bit, whereas everything else was done via ffmpeg using x265 or x264 8-bit. Still, we get a good idea of where these show up. At both CRF 24 and CRF 22, even the lowest frames don’t dip below SSIM 0.95. I personally think the extra 2500kbps for the large jump in minimum quality from CRF 24 to CRF 22 is a must. To some, including myself, it could be worth the extra 4000kbps jump from CRF 22 to CRF 20.
So let’s get a little more apples to apples. In this test, I encoded all videos with ffmpeg using the default presents. I did three CRF videos first, at 22, 20, and 18, then using their resulting bitrates created three ABR videos.
Generated via Python and matplotlib (Click to view larger version)
Their overall average SSIM scores were near as identical. However, CRF shows its true edge on the lowest 1%, easily beating out ABR at every turn.
To 10-bit or not to 10-bit?
Thankfully there is a simple answer. If you are encoding to x264 or x265, encode to 10-bit if your devices support it. Even if your source video doesn’t use the HDR color space, it compresses better.
There is only one time to not use it. When the device you are going to watch it on doesn’t support it.
Which preset should I use?
The normal wisdom is to use the the slowest you can stand for the encoding time. Slower = better video quality and compression. However, that does not mean smaller file size at the same CRF.
Even though others have tackled this issue, I wanted to use the same material I was already testing and make sure it held true with 4K HDR video.
Generated via Python and matplotlib (Click to view larger version)
I used a three minute 4K HDR clip, using Handbrake to only modify which present was used. The results were surprising to me to be honest, I was expecting medium to have a better margin between fast and slow. But based on just the average, slow was the obvious choice, as even bumping up the CRF from 18 to 16 didn’t match the quality. Even thought the file size was much larger for the CRF 16 Medium encoding than it was than for the CRF 18 Slow! (We’ll get to that later.)
Okay, okay, lets back up a step and look at the bottom 1% again as well.
Generated via Python and matplotlib (Click to view larger version)
Well well wishing well, that is even more definitive. The jump from medium to slow is very significant in multiple ways. Even though it does cost double the time of medium it really delivers in the quality department. Easily beating out the lowest 1% of even CRF 16 medium, two entire steps away.
Generated via Excel (Click to view larger version)
The bitrates are as expected, the higher quality it gets the more bitrate it will need. What is interesting, is if we put CRF 16 - Medium encoding’s bitrate on this chart it would go shoot off the top at a staggering 15510kbps! Keep in mind that is while still being lesser quality than CRF 18 - Slow.
In this data set, slow is the clear winner in multiple ways. Which is very similar to other’s results as well, so I’m personally sticking too it. (And if I ran these tests first, I would have even used slow for all the other testing!)
Conclusion
If you want a single go to setting for encoding, based on my personal testing CRF 20 with Slow preset looks amazing (but may take too long if you are using older hardware).
Now, if I have a super computer and unlimited storage, I might lean towards CRF 18 or maybe even 16, but still wouldn’t feel the need to take it the whole way to CRF 14 and veryslow or anything crazy.
I hope you found this information as useful as I did, if you have any thoughts or feedback please let me know!
I’m an artist and a python developer, two things that rarely occupy the same worlds, let alone the same sentence. However, I have recently found a way to combine these two passions: Panoramas.
My current smartphone takes excellent pictures. It does a great job at figuring out colors, lighting, and focus, even in low lighting. As an artist, this is important to me because I often use my phone to snap quick pictures of a scene as a reference to take back to my studio. It’s a huge improvement in the technology I had in my hands even five years ago. There is one thing about my old phone that I miss though – its ‘panorama’ photo mode, but not because it was better.
I miss how amazingly awful it used to be, and more importantly, the freedom to make awful pictures it allowed. I’d point the lens out the window of the car as it sped along (as a passenger of course) to make jagged and confusing images of tiny bits of the landscape that the phone struggled to hodgepodge together. I’d tilt and move the phone in random directions to make weird swirls of the horizon. Even when being used ‘as directed’, it would usually struggle with focus and lighting coming up with spontaneously and wonderfully terrible photos with abstract light glare or menacing dark patches. It’s hard to explain, but sometimes as an artist, a terrible photo can be just as inspiring as those picture perfect reference pics I take with me back to the studio.
My current phone is too smart for that though, and it snatches away any joy of bad photography by making consistently beautiful and seamless panoramas. Not only that, but it accomplishes this mostly by yelling at you (“You’re going too fast!”) or by using angry arrows to make sure you can only move the phone in one direction, and then abruptly ending the photograph when you don’t cooperate. So, I did what anyone does when they get nostalgic for awful photography – I made a python script to make my own terrible panoramas.
My plan was simple. First, I would shoot short videos where my phone wouldn’t yell at me for moving, tilting, and spinning the image as much as I wanted. Next, use Python to convert each frame of the video clip to an image, crop the image into a tiny sliver out of the center of the image and then glue them all together. The results are imperfect. And gloriously so.
Side note: Although I used my smartphone to shoot some video, this script could be applied to any video. Think of the wild panoramas you could create from some Russian dash cam footage, or a GoPro strapped to a fish, or a tiny clip from the Lord of the Rings. However, this script works best on videos that are less than 10 seconds long or else it produces mile long panoramic images. Currently, I don’t bother limiting the image size at all, but theoretically I could by using one out of every five frames for instance, or by cutting down the image slice size based on video length.
The Python Image Library is the only other requirement, installed with pip.
pip3 install pillow
The script works by pulling all videos out of a source directory based on file suffix and creating a panorama for each. This could easily be modified to convert just one video at a time by removing the loops and passing the path to the desired video directly to ffmpeg.
directory = Path('my\\videos\\dir')
vids = []
for vid in directory.iterdir():
if vid.suffix.lower() in ('.mp4', '.mkv'):
vids.append(vid)
Every frame pulled out by ffmpeg is stored in a file. I delete the directory and recreate it before ffmpeg runs to delete the old frames from the last run.
for vid in vids:
shutil.rmtree("pics", ignore_errors=True)
os.makedirs("pics", exist_ok=True)
print(f'Creating panoramic {vid.stem}')
result = run(
f'ffmpeg -i {vid.absolute()} '
f'-y pics\\thumb%04d.jpg -hide_banner',
shell=True, stderr=PIPE)
result.check_returncode()
print(result.stderr.decode('utf-8'))
After it finishes pulling out all the frames, I start the panorama by creating an empty image. I need to have the dimensions of the finished image to create it. To get the final width, I multiply the number of frames ffmpeg pulled out by the width of my image slice (40 pixels). For the height, I open up one of the frames and use it size as a reference. I also use the sample image’s dimensions to figure out the center of the image for cropping everything down later.
Then, I loop through all the frame images in reverse order (because … long story short, it usually looks better that way) and then work on slicing each image down to 40 pixels wide to glue into the panorama.
sample = Image.open("pics/{}".format(os.listdir("pics")[0]))
width, height = sample.size
center = width / 2
panoramic = Image.new('RGB', (len(os.listdir("pics")*40), height))
# This offset is so PIL knows where to start adding
# each image slice to the panorama
x_offset = 0
for i in reversed(os.listdir("pics")):
img = Image.open("pics/{}".format(i))
area = (center - 20, 0, center + 20, height)
cropped_img = img.crop(area)
panoramic.paste(cropped_img, (x_offset, 0))
x_offset += 40
panoramic.save(f'{vid.stem}.jpeg')
panoramic.close()
The Painting
So far, I am quite happy with the results of this adorable little script. It has definitely given me the creative inspiration I was missing. In the past two weeks, I have done three series of paintings based on panoramas I have created using it, with plans for many more. Here’s an example of how I used it to create some artwork!
I took this video:
turned it into this panorama:
played with some paint and smudged around some charcoal and pastels:
and came up with this:
Final Thoughts
It feels really amazing to apply Python to unusual problems, even if that challenge is finding a unique way of creating original art. Plus, if the inspiration ever dries up, I have some ideas for making this script even more fun:
grab each slice from a random spot rather than dead center of the image for something much more jumbled and abstract
options to not use every frame for longer videos
PIL ‘effects’, like a black and white mode, over saturation, or extra blurry images
an ‘up and down’ mode for tall panoramas
I hope you enjoyed! Feel free to check out my website or my instagram for more artwork if you are interested.
NZXT Kraken coolers are awesome for CPUs or GPUs. Their CAM software on the other hand is slow, bloated and possibly stealing your data. Thankfully, there are open source alternatives available.
The option that I will walk you through using is a command line tool that doesn’t need to be constantly running in the background, and doesn’t require any internet connection to work.
APRIL 2019 UPDATE: liquidctl now has the best support all around and automated windows builds! Use this and forget about everything below!
UPDATE: I have created a standalone executable for Windows for those that do not want to bother with the steps below. It is available on github. (For x61 and other second gen users, you will still need to update the driver as part of step five below.)
There are a few different libraries to control third generation coolers ( Kraken x62, x72, x52 and x42 ). The only one that supports fan control for second generation ( Kraken x61, x41 and x31 ) as well as third on Windows that I have found is liquidctl (as of 2/6/2019 still in an experimental dev branch, can check on the issue directly for updates ).
Please note: none of this is my own software, and this is only a guide based on my own experience. This is fully “as-is”, no warranty or guarantee it won’t harm your hardware or other software.
I am going to get a little more detailed for these steps than usual, as I want to make this easy for anyone’s skill level. For power users, here are the abbreviated steps:
Kraken x61 / gen two users only – Downloaded zadig and install libusbK driver for the Kraken device
WARNING – CAM will no longer be able to use this device unless you uninstall this new driver
Select Options > List all Devices
Find the device “690LC” in the dropdown list, should have USB ID of 2433 B200
Run liquidctl to change your fan speed!
liquidctl set fan speed 60
As of time of writing their software does not by default include the code for changing the logo color for the second generation Krakens (x61, etc..), but I’ll show you how to add it easily. Checkout the liquidctl repo, that now has great support for older devices, as well as some EVGA and Corsair support!
Download Python
For those of you who do not already have it, we will need to make sure there is a version of Python 3 on your system. Go to the official download page from the Python Software Foundation at https://www.python.org/downloads/windows/. Click on the top link for “Latest Python 3 Release” (version may be newer than shown below.)
Scroll down to the bottom of the next page, and select the “Windows x86 Executable Installer”. Yes, install the x86 version, aka 32-bit , even if you have 64-bit Windows. If you do happen to download and install the x86_64 version instead, you just will have to use a different libusb dll (thankfully included in same download bundle).
After the exe is downloaded, double click on it, and lets make a few changes during the installation to make your life easier. First make sure to add Python to PATH. This will make it possible to run python from the command line without specifying the full path to it’s executable. Then click on “Customize installation”.
Next page we don’t need to touch anything. If you are only going to use python for only this, you can remove Documentation and Python test suite and it will still work fine and reduce bloat.
Final page we just want to make sure it’s installed the program files directory instead of the obscure user app dir that it uses by default. Then hit install.
You should now be able to open python easily in the command prompt. You can open it by hitting the Windows key on your keyboard (or manually opening start menu), typing “Command” and then click on “Command Prompt”.
C:\Users\me>python --version
Python 3.7.2
Create a virtual environment
By creating a virtual environment you isolate the new libraries you are going to install from the system version of Python, eliminating possible future headaches if you need to install conflicting packages.
Thankfully it is super simple to do, open a command prompt, navigate to the directory you want a new folder with the virtual environment in, and type:
python -m venv venv
This is simply saying “Run python, using module venv -m venv to create a virtual env at the venv directory. Then you want to “activate” it so that your command prompt will instead use that new isolated version of Python and Python tools (like pip).
venv\Scripts\activate.bat
This will cause your command prompt to give a nice little notification that you are now using that venv:
Remember the path you installed the virtual env too, we will use it later!
Install libusb DLLs
Just because life has to be a little extra difficult, libusb only pushes their releases in 7z and tar.bz2 archives. Which means, if you don’t already have a tool that can open these type of files, head over to https://www.7-zip.org/download.html and download either the exe or msi for your version of Windows (if you are unsure, just get the 32-bit exe one).
Installing it should be fine with the defaults, feel free to change as you want. When done, go over and download libusb. The developers of liquidctl suggest you use 1.0.21 at time of writing so we are linking directly to that version https://github.com/libusb/libusb/releases/tag/v1.0.21.
After download, extract those files with 7zip.
Then you will want to go into the new directory, and find the proper DLLs for your installed version of Python. If you followed this guide so far, that will be the MS32 folder.
You are going to copy those into your virtual environment directory Scripts directory, as that is by default added to the PATH when you activate the virtual env. So if I was in the C:\Users\me directory when I ran python -m venv venv I would copy those three files into C:\Users\me\venv\Scripts.
They look a little out of place, but meh, it works.
Change the Kraken drivers (x61, x41, x31 Only)
Sadly (or not so sadly) we can’t use the default second gen Kraken drivers installed by CAM. Which also mean that when we switch these, CAM will no longer be able to interface with the Kraken unless this new driver is removed via the Driver Manager.
ONLY FOR KRAKEN x61, x41 and x31! Skip ahead to the next section for anything else.
Run it as an administrator, then go to Options and select “List all Devices”.
Chose 690LC from the drop down list. It’s USB ID should be 2433 B200. Select either the libusb-win32 or libusbK driver from the right hand tiny select buttons. (I had trouble the first time timing out on the libusbdrivers so I switched to libusbK, your mileage may vary.) Then hit ‘Replace Driver’.
This will probably take a while. Hopefully it pops up a success window in a few seconds or minutes. If not, I suggest waiting a full ten minutes, then switching to the other driver type (aka select libusbK if you first tried libusb-win32) and trying again before running to their github for help.
Install liquidctl
We’re almost there!
Switch back to the command prompt and make sure you are in the active virtual env. If you don’t see (venv) at the start of the line, go back and take a look at the “Create a virtual environment” section.
If you are using this for a newer third generation device, like the Kraken x62, you can use the regular module.
pip install liquidctl
However, if you do need second generation support for the Kraken x61, x41 or x31, you will need to grab the experimental branch. Please be aware that this may be at an unstable state at time of your download. You can follow current issues directly in the pull request.
This will install the command in the active virtual environment as liquidctl! Keep in mind, you will need to activate this virtual environment to use this command.
Using liquidctl
You can find the full list of what you can do via --help or from their github. But to start you want to list out devices detected on the system, initialize them, and view their status.
(venv) C:\>liquidctl list
Device 0, Asetek 690LC (NZXT, EVGA or other) (experimental)
(venv) C:\>liquidctl initialize
report: failed to (pre) open (control: open), ignoring
(venv) C:\>liquidctl status
Device 0, Asetek 690LC (NZXT, EVGA or other) (experimental)
report: failed to (pre) open (control: open), ignoring
Liquid temperature 31.2 °C
Fan speed 1320 rpm
Pump speed 3600 rpm
Firmware version 0.7.0.0
For the Kraken x61 and gen-two devices, the only thing you can do* is set the fan speed. (* As of time of writing, could have come a long way by whenever ‘now’ is. Also, you can used my “hack” below to change the logo color.)
(venv) C:\> liquidctl set fan speed 100
If you are using third gen devices, you can have fun with pump speeds or colors as well!
liquidctl set ring color fading 350017 ff2608
liquidctl set logo color spectrum-wave --speed slowest
liquidctl set pump speed 90
Multiple Devices
If you happen to have multiple supported devices on your system, you will have to select which one you want to use. First figure out which device is numbered as which.
(venv) C:\> liquidctl list
Device 0, Asetek 690LC (NZXT, EVGA or other) (experimental)
Device 1, NZXT Kraken X (X42, X52, X62 or X72
Then just append --device <num> to any follow up commands.
liquidctl --device 1 set ring color spectrum-wave
liquidctl --device 0 set fan speed 100
You can see more detailed options including color modes for Kraken devices here.
Getting color working for the Kraken x61
If you don’t code and are never going to use this virtual environment for anything other than this tool, don’t fret. It’s a copy paste operation! (For others that don’t want to modify their site-packages file and know what that means, you can do a local develop mode install via setup.py and play to your heart’s content.)
Okay, so all we need to do is simply add a new section of code to one of the files. You’ll have to navigate a few layers deep into the virtual environment you created: venv\Lib\site-packages\liquidctl\driver there is a file called asetek.py that you need to open. If you installed the full Python suite, you should be able to easily right click and edit in IDLE.
Scroll to the bottom of the file, and paste the following block of code:
def set_color(self, channel, mode, colors, speed):
"""Set the color of the logo."""
modes = ('fixed', 'alternating', 'blinking', 'off')
speeds = {
'fastest': 1,
'faster': 2,
'normal': 3,
'slower': 4,
'slowest': 5
}
try:
speed = int(speed)
except ValueError:
if speed not in speeds:
LOGGER.warning('Speed must be a value between 1 and 255, setting to 1')
speed = 1
else:
speed = speeds[speed]
else:
if speed < 1 or speed > 255:
speed = 1
LOGGER.warning('Speed must be a value between 1 and 255, setting to 1')
if channel != 'logo':
LOGGER.warning('Only "logo" channel supported for this device, falling back to that')
if mode not in modes:
raise NotImplementedError('Modes available are: {}'.format(",".join(modes)))
if mode == 'off':
color1, color2 = [0x00, 0x00, 0x00], [0x00, 0x00, 0x00]
else:
color1, *color2 = colors
if len(color2) > 1:
LOGGER.warning('Only maximum of 2 colors supported, ignoring further colors')
color2 = color2[0] if color2 else [0x00, 0x00, 0x00]
self._begin_transaction()
data = ([0x10] +
color1 +
color2 +
[0xff, 0x00, 0x00, 0x37,
speed,
speed,
0x00 if mode == 'off' else 0x01,
0x01 if mode == 'alternating' else 0x00,
0x01 if mode == 'blinking' else 0x00,
0x01, 0x00, 0x01])
data.to_yaml(filename=self.data_file)
self._write(data)
self._end_transaction_and_read()
Because Python is spacing specific, make sure the def set_color lines up with the def _write above it. It should look something like this (code may change vs what is in the image):
Then, make sure to save the file, by either hitting Ctrl+s or go to File > Save. The options for colors are quite limited for second gen devices versus third gen, but at least you can use them!
Mode
Colors to supply
off
0
fixed
1
alternating
2
blinking
1
liquidctl --device 0 set logo color blinking ffffff --speed 2
Now you can issue a command to set the colors like normal. Provide --speed to set number of seconds between alternating colors or blinking.
If you have any issues with the colors command, please let me know. If you have issues with the program itself, please open an issue directly on liquidctl github page.
Windows Auto-start
Alright, I’ve played around and have everything set perfectly. But wait, I rebooted and it’s all gone! NOOOO!
Thankfully, it’s rather simple to have your configuration auto load on startup. We simply have to put the commands into a script, and put it into the windows auto start directory.
Open your run menu by hitting the Windows Key plus r at the same time (or typing in run to windows search). When the little box pops up, type in shell:startup and hit OK. It will take you to a deep dark folder like C:\Users\me\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
Open your favorite text editor (or if you know what you’re doing, just right click in the folder, create a new text file, then rename it with a .bat extension.) Keep that window open, so we can copy it’s path.
Now to create the small script. This script’s first command is to go into the venv\Scripts directory, so make sure to change to the full path of where that is in your version. Then, simply modify the liquidctl commands to the ones you want to issue.
cd C:\YOUR_OWN_FULL_PATH_HERE_MAKE_SURE_TO_CHANGE\venv\Scripts
call activate.bat
liquidctl --device 0 set logo color fixed ffffff
liquidctl --device 0 set fan speed 30 25 40 50 50 100
liquidctl --device 1 set logo color fixed ffffff
liquidctl --device 1 set ring color fixed ffffff
liquidctl --device 1 set pump speed 30 50 40 75 50 100
liquidctl --device 1 set fan speed 30 25 50 50 60 75 70 100
Now when you go to save this new file, copy that long path from the open shell:startup directory into the save bar so it is saved into that directory. Then save the file as a name you will remember, like kraken_control.bat just make sure it ends in .bat. In notepad, you may have to change the dropdown from Save as type to All files.
You should now see that file in the startup directory. Go ahead and double click on it to make sure it works. Easiest way to test is first manually change your Kraken colors to something different and make sure running the script changes them back.
If it doesn’t work, most likely a command is miss typed. Copy line for line into a cmd prompt and make sure it works for you there. (Or just run the .bat file from an open cmd prompt if you know how so you don’t have to copy-paste.)
That’s all for this tutorial. I hope you found it useful and stress free! If there is something that needs improved please let me know in the comments below.
