October 22, 2017

October 18, 2017

GCompris at KDE-edu sprint 2017

Ten days ago, I spent a week-end in Berlin with a group of KDE friends to have a KDE-edu sprint. I didn’t blog about it yet because we planned to make a group post to summarize the event, but since it takes some time, I decided to write a quick personal report too.

The sprint was hosted in Endocode offices, which was a very nice place to work together.

KDE edu Sprint 2017

Of course I came mostly because of GCompris, but the goal in the end was more to work together to try to redefine the goal and direction of KDE-edu and its website, and to work together on different tasks.

I added appstream links for all KDE-edu apps on their respective pages on KDE website. Those appstream links can be used to install directly applications from linux appstores supporting this standard.
On a side note, we thought it is a bit weird to be redirected from the KDE-edu website to KDE.org when looking at application info. This is one of the things that would need some refactoring. Actually, we discussed a lot about the evolution needed for the website. I guess all the details about this discussion will be on the group-post report, but to give you an idea, I would summarize it as : let’s make KDE-edu about how KDE-applications can be used in educational context, rather than just a collection of specific apps. A lot of great ideas to work on!

For GCompris, I was very happy to can meet Rishabh, who did some work on the server part. I could test the branch with him, and discussed about what needs to be done. Next, I fixed and improved the screenshots available for our appdata info, and started to look at building a new package on Mac with Sanjiban.

I also cleaned an svg file of Ktuberling to help Albert who worked on buiding it for Android.

In the end, I would say it was a productive week-end. Many thanks to KDE e.V. for the travel support, and to Endocode for hosting the event and providing cool drinks.

October 17, 2017

Faces of Open Source


Faces of Open Source

Peter Adams’s Portraits of Revolutionaries

Recently, @houz posted about an amazing project by photographer Peter Adams called Faces of Open Source.

Peter really (ahem) throws a light on many amazing luminaries from not only the Free/Open Source Software community, but in some cases the history and roots of all modern computing. He has managed to coordinate portrait sessions with many people that may be unassuming to a layperson, but take a moment to read any of the short bios on the site and the gravity of the contributions from the subjects to modern computing becomes apparent.

It’s easy for non-technical folks to spot a Bill Gates or Steve Jobs, but what about those who invented the most-used programming language, created the web server that runs the majority of the internet, or mapped the human genome?

Dennis Ritchie, Brian Behlendorf, Jim Kent (From L-R): Dennis Ritchie, Brian Behlendorf, and Jim Kent

He is acutely aware that his subjects represent an important part of the history of Open Source, and in his artist statement for the project he notes:

This project is my attempt to highlight a revolution whose importance is not broadly understood by a world that relies heavily upon the fruits of its labor.

That’s really what Peter has done here. He has collected individuals whose contributions all add up to something far greater than their collective sums to shape the digital world many take for granted these days, and is presenting them in a powerful and thoughtful way more befitting their gifts.

Peter Adams Photography

A Chat with Peter Adams

I was lucky enough to be able to get a little bit of time with Peter recently, and with some help from the community had a few questions to present to him. He was kind enough to take some time out of his day and be patient while I prattled on…

Linus Torvalds by Peter Adams Linus Torvalds, Santa Fe, New Mexico, 2016 by Peter Adams

What was the motivation for this particular project for you? Why these people?

I had a long career working in the tech industry, and kind of grew up on a lot of this software when I was in college.
Then got to apply it throughout a career as senior technologist or CTO at a bunch of different companies in the valley. So I went from learning about it in college, to being someone that used it, to then being somebody that contributed to it and starting my own open source project back in 2006. That open source ethos, the software, and the people that created, maintained and promoted it - it’s something that’s been right there in my face for, really, the last 25 years.

I wanted to marry my knowledge of it with my passion for photography, and shine a light on it. I went through a few different chapters of the story myself in the 80’s and then the mid-90’s with linux. I kind of felt like the story was starting to slip into obscurity, not because it’s less important - in fact I think it’s more important now than it’s ever been.

The software is actually used by more people now than it has ever been. The smartphone revolution, mobile, has brought that to a forefront and all of these mobile platforms are based on this open source technology. Everything Apple does is based on BSD, and everything Google/Android does is based on Linux.

I feel like it’s a more impactful story now than ever, but very few people are telling the story. As a photographer I’ve always cringed at the photographic response to the story. Podium shot after podium shot of these incredible people.

So I wanted to put some faces to names, bring these people to life in a more impactful way than I think anyone has done before. Hopefully that’s what the project is doing!

P: It absolutely does!

Brian Kernighan by Peter Adams Brian Kernighan, New York City, 2015 by Peter Adams

How long have you been shooting the project?

I started this project in 2013/2014, in earnest probably late 2014.

Of all of the people that you’ve shot, I’m curious, who would you say is one that maybe stuck out with you the most, or even better, did you get any cool stories out of some of the subjects?

Everyone that I’ve photographed has been absolutely wonderful. I mean, that’s the first thing about this community: it’s a very gracious community. Everybody was very gracious with their time, and eager to participate. I think people recognize that this is a community they belong to and they really want me to be a part of it, which is really great.

So, I enjoyed my time with everybody. Everybody brought a different, interesting story about things. The UNIX crew from Bell Labs had particularly colorful stories, very interesting sort of historical tidbits about UNIX and Free Software.

I talked to Ken Thompson about going to Russia and flying MIGs right after the collapse of the Soviet Union. Wonderful stories from Doug McIlroy about the team and the engineering - how they worked together at Bell labs. Just a countless list of cool stories and cool people for sure.

Ken Thompson by Peter Adams Ken Thompson, Menlo Park, California, 2016 by Peter Adams
Doug McIlroy by Peter Adams Doug McIlroy, Boston, Massachusetts, 2015 by Peter Adams

P: It must have been fascinating!

It’s been really fun. A lot of these folks, I’ve really looked up to them over the years as sort of heroes, and so when you get people in front of your lens like that, it’s a really wonderful experience. It’s also a challenging experience because you want to do justice to them. Many of these folks that I’ve thought about for 20+ years, finally getting to shoot them is a real treat.

Where are you shooting these? Are you mostly bringing them into your studio in the valley?

I shot a lot of people when I had a studio in Silicon Valley. I brought a lot of people there and that was great. Now typically I’m doing shoots on the coasts. So I’ll do shoots in NY and I’ll rent a studio and bring 6 or 7 people in there or we’ll do a studio up in SF for some people. But I’ve done shoots in back alleyways, I’ve done shoots in tiny little conference rooms, I’ll bring the studio to people if that’s what I have to do. So I’d say so far it’s been about 50-50.

The lighting setups are wonderful and do justice to the subjects, and I think somebody in the community was curious if you had decided on B&W from the beginning for this series of photos? Was this a conscious decision early on?

B&W on a white background was a conscious choice right from the beginning. Knowing the group, I felt like that was going to be the best way to explore the people and the faces. Every one of these faces just tells, I think, a really interesting story. I try to bring the personality of the person into the photo, and B&W has always been my favorite way to do that. The white background just puts the emphasis right on the person.

Camille Fournier by Peter Adams Camille Fournier, New York City, 2017 by Peter Adams

How much of it would you say is you that goes into the final pose and setup of the person, or do you let the subject feel out the room and get comfortable and shoot from there?

It’s a little bit of both. I wish I got to spend a lot of time up front with the person before we started shooting, but the way everybody’s schedule worked is - none of these shoots are more than an hour and many of them are much shorter than an hour. There’s definitely the pleasantries up front and talking for a little bit, but then I try to get people right in front of the camera as quick as possible.

I don’t really pose them. My process is to sit back and observe, and I always tell people “if I’m not taking photos, it’s not because you’re doing anything wrong - I’m just waiting for you to settle or looking, examining”. Which is, for most people, a really uncomfortable process, I try to make it as comfortable as possible. Then we’ll start taking pictures. I may move them a little bit, or we may setup a table so they can rest their hand on their chin or something like that. Generally the photos that come out are not pre-meditated.

It’s very rare that I go into any of these shoots with an actual “I want the person like this, setup like that, etc…”. I’d say 99% of these shots, the expressions, the feeling that comes out, that I’m capturing is organic. It’s something that comes up in the shoot. I just try to capture it whenever I see it by clicking the shutter, that’s basically what I’m doing there.

You list what equipment you shot each portrait with, but I’m curious about the lighting setup. Is there a “go-to” lighting setup that you like to use?

The lighting is literally the same on every shot, though there’s slightly different positions. It’s a six light setup: there are four lights on the background, there’s a beauty dish overhead, and generally a fill light. The fill is either a big Photek or PLM, basically a big umbrella, or a ringflash depending on how small the room is. That’s the same lighting setup on all of them. Four lights on the background, two lights on the subject. I’ll vary the two lights on the subject positionally, but for the most part they’re pretty close.

Do you use Free Software in your normal photographic workflow at all?

I don’t use as much Free Software as I’d like in my own workflow. My workflow, because I shoot with Phase One, the files go into Capture One and then from there they go into Photoshop for final edits. I have used GIMP in the past. I really would like to use more Free Software, so I’m a learner in that regard for what tools would make sense.

Spencer Kimball by Peter Adams Spencer Kimball (co-creator of GIMP), Menlo Park, 2015 by Peter Adams
Peter Mattis by Peter Adams Peter Mattis (co-creator of GIMP), New York City, 2015 by Peter Adams

Did that habit grow out of the professional need of having those tools available to you?

Phase One, which makes the Medium Format digital back and camera that I use for all of my portrait work, also makes Capture One. They have basically customized the software to get the most of their own files. That’s pretty much why I’ve wound up there instead of Lightroom or another tool. It’s just that that software tends to bring out the tonality, especially in the B&W side, better I’ve found than any other tool.

This project was self financed to start with?

Yes, this is a self-financed project. I do hope that we’ll get some sponsors, especially for the book, just because it tends to be a pretty heavy upfront outlay to produce a book. I’m going to think about things like Kickstarter but the corporate sponsors I think will be really helpful for the exhibits and the book.

Speaking of the book, is it ready - have you already gone to print?

No, the book isn’t ready yet. I still have probably another 10-12 people that I need to photograph and then we’ll start producing it. I’ve done some prototypes and things on it but it’s still a little bit of a ways away. The biggest hurdle on this project is actually scheduling and logistics. Getting access to people in a way that is economical. Instead of me flying all over the place for one shot, I try to stack up a number of people into a day. It’s tough - this is a busy crowd, very in demand.

Faces of Open Source Book Promo

Did your working in open source teach you anything beyond computer code in some way? Was there an influence from the people you may have worked around, or the ethos of Free Software in general that stuck with you? Working with this crowd, was there a takeaway for you beyond just the photographic aspects of it?

Absolutely! First of all it’s an incredibly inspiring group of people. This is a group of people that have dedicated, in some cases most of, their lives to the development of software that they give away to the world, and don’t monetize themselves. The work they’re doing is effectively a donation to humanity. That’s incredibly inspiring when you look at how much time goes into these projects and how much time this group of people spends on that. It’s a very humbling thing.

I’d say the other big lesson is that Open Source is such a unique thing. There’s really nothing like it. It’s starting to take over other industries and moving beyond just software - it’s gone into hardware. I’ve started to photograph some of the open source hardware pioneers. It’s going into bio-tech, pharmaceuticals, agriculture (there’s an open source seed project). I think that the lessons that are learned here and that this group of people is teaching is really affecting humanity on a much much larger level than the fact that this stuff is powering your cell phone or is powering your computer.

Limor Fried by Peter Adams Limor Fried, New York City, 2017 by Peter Adams

Open source is really sort of a way of doing business now. Even more than doing business it’s a way of operating in the world. More and more people, industries, and companies are choosing that. In today’s world where all you read is bad news, that’s a lot of really good news. It’s an awesome thing to see that accelerating and catching on. It’s been incredibly inspiring to me.

P: I think even all the way back to the Polio vaccine, is one of those things. The effect that it had on humanity was immeasurable, and the fact that it wasn’t monetized by Salk was amazing.

Look at how many lives were saved because of that. If you think about the acceleration of the innovation we’ve had just in the technology sector - could things like the iPhone or the Android operating system - would these things have happened now, or over the last decade, without this [open source], or would we be looking at those types of innovations happening twenty years from now? I think that’s a question you have to ask.

I don’t think it’s an obvious answer that Apple or Google or somebody else would have just come up with this without the open source [contributions]. This stuff is so fundamental, it’s such a basic building block for everything that’s happening now. It may be responsible for the golden age that we’re seeing now. I think it is.

The average teenager they pick up and post a photo to Instagram - they don’t realize that there’s a hundred open source projects at work to make that possible.

P: And the fact that the people that underlay that entire stack gave it away.

Right. And that giving it away was necessary to create the Instagrams to create all these networks. It wasn’t just this happenstance thing where people didn’t know any better. In some cases obviously that did exist, but it’s the fact that consciously people are contributing into a commons that makes it so powerful and enables all of this innovation to happen. It’s really cool.

David Korn by Peter Adams David Korn, New York City, 2015 by Peter Adams

To close, is there another photographer, book, organization - that you’d like any of the readers to know about and maybe spend some time to go and check out. Something that maybe you’ve long admired or recently discovered?

Sure! You’ve mentioned Martin Schoeller, who is one of my personal favorites and inspirations out there. I’d say the other photographer who has had probably the most impact on my photography over the years has been Richard Avedon. For people that aren’t familiar with his work I’d say definitely go check out the Avedon foundation. Pick up any of his books which are just wonderful. You’ll definitely see that influence on my photography, especially this project, since he shot black and white on white background. Such stunning work. I’d say that those are two great ones to start with.

Alright! Avedon and Schoeller - I can certainly think of worse people to go start a journey with. Thank you so much for taking time with me today!

Hey no problem! It’s been fun to talk to you.


There are many more fascinating portraits awaiting you over on the project site, and every one of them is worth your time! See them all at:

http://facesofopensource.com/

You can also connect with the project on

Find more of Peters work at his website.

All images from “Faces of Open Source” by Peter Adams, licensed CC BY NC SA 4.0.

October 16, 2017

Shaking the tin for LVFS: Asking for donations!

tl;dr: If you feel like you want to donate to the LVFS, you can now do so here.

Nearly 100 million files are downloaded from the LVFS every month, the majority being metadata to know what updates are available. Although each metadata file is very small it still adds up to over 1TB in transfered bytes per month. Amazon has kindly given the LVFS a 2000 USD per year open source grant which more than covers the hosting costs and any test EC2 instances. I really appreciate the donation from Amazon as it allows us to continue to grow, both with the number of Linux clients connecting every hour, and with the number of firmware files hosted. Before the grant sometimes Red Hat would pay the bandwidth bill, and other times it was just paid out my own pocket, so the grant does mean a lot to me. Amazon seemed very friendly towards this kind of open source shared infrastructure, so kudos to them for that.

At the moment the secure part of the LVFS is hosted in a dedicated Scaleway instance, so any additional donations would be spent on paying this small bill and perhaps more importantly buying some (2nd hand?) hardware to include as part of our release-time QA checks.

I already test fwupd with about a dozen pieces of hardware, but I’d feel a lot more comfortable testing different classes of device with updates on the LVFS.

One thing I’ve found that also works well is taking a chance and buying a popular device we know is upgradable and adding support for the specific quirks it has to fwupd. This is an easy way to get karma from a previously Linux-unfriendly vendor before we start discussing uploading firmware updates to the LVFS. Hardware on my wanting-to-buy list includes a wireless network card, a fingerprint scanner and SSDs from a couple of different vendors.

If you’d like to donate towards hardware, please donate via LiberaPay or ask me for PayPal/BACS details. Even if you donate €0.01 per week it would make a difference. Thanks!

Blender Daily Doodles — Day 28

People following me on Instagram have been asking why I do the daily renders. You’re not gonna get better by thinking about it. The arsenal of tools and methods in Blender is giant and over the years I still struggle to call myself proficient in any of them.

 

 

 

Follow me on Instagram to see them come alive. I’m probably not gonna maintain the daily routine, but I will continue doing these.

Interview with Cillian Clifford

Could you tell us something about yourself?

Hi everyone – my name is Cillian Clifford, I’m a 21 year old hobbyist artist and electronic musician, and an occasional animator, writer and game developer. I go by the username of Fatal-Exit online. I live in rural Ireland, a strange place for someone so interested in technology. My interests range from creative projects to tech related fields like engineering, robotics and science. Outside of things like these I enjoy gaming from time to time.

Do you paint professionally, as a hobby artist, or both?

Definitely as a hobby. I consider digital painting to be one of my weakest areas of art skills, so I spend a lot of time trying to improve it. Other areas of digital art I’m interested in include CAD, 3d modeling, digital sculpting, vector animation, and pixel art.

What genre(s) do you work in?

It varies! Hugely, in fact. Over the past two years on my current DeviantArt account I’ve uploaded game fan-art paintings, original fantasy and Sci-Fi pieces, landscapes, pixel art, and renders of 3d pieces. I also occasionally paint textures and UV maps for 3d artwork. Outside of still art, I also animate in vector and pixel art styles. I also occasionally make not-great indie games, but as you might guess, most never get finished.

Whose work inspires you most — who are your role models as an artist?

A wide range of artists, often not particular people but more their combined efforts on projects. I will say that David Revoy and GDQuest in the Krita community are a big inspiration. Youtube artists such as Sycra, Jazza and Borodante are another few I can think of. Lots of my favorite art of all time has come from large game companies such as Blizzard and Hi-Rez Studios. Also game related, the recent rise of more retro and pixel based graphics in indie games is a huge interest of mine, and games like Terraria, Stardew Valley and Hyper-Light Drifter have an art style that truly inspires me.

How and when did you get to try digital painting for the first time?

My first time doing some sort of “digital painting” was when I was about 16-17. I did the graphics design work for a board game a team of us were working on for a school enterprise project, using the free graphics software Paint.net and a mouse. It took ages. However the project ended up taking off and we ended up in the final stage of the competition. After that was over (we didn’t win) I decided digital art might be something to seriously invest in and bought a graphics tablet. For a couple of years I made unimaginably terrible art and in 2015 I decided to shut down my DeviantArt account and start fresh on a new account, with my new style. This was about when I found Krita, I believe.

What makes you choose digital over traditional painting?

A few things: Firstly, I could never paint in a traditional sense, I was absolutely terrible. At school I was considered a C grade artist, and that was even when working on pen and ink drawings, a style I used to be good at but have since abandoned. I never learned to paint traditionally.

Secondly, I can do it anywhere. In my bedroom with a Ugee graphics monitor and my workstation desktop, or lots of other places if I take my aging laptop and Huion graphics tablet with me. Soon I’m looking to buy a mobile tablet similar to the Microsoft Surface Pro, that’ll let me paint absolutely anywhere.

Thirdly, the tech involved. So not only am I able to emulate any media that exists in traditional art with various software, I can also work on art styles that aren’t even possible with traditional. As well as this, functions like undo, zooming in and out of the canvas, layers and blending modes, gradients and bucket fill, the list goes on and on.

I can happily say I never want to “go back” to traditional painting even though I was never any good at it in the first place.

How did you find out about Krita?

That’s a hard question. I’m not absolutely sure, but I’ve an idea that it might have been through David Revoy’s work on the Blender Foundation movies, and Pepper and Carrot. I was looking for a cheap or free piece of software because I didn’t want to use cracked Photoshop/Painter, and I’d already used GIMP and Paint.net, and neither were good for the art I was looking to create. I tried MyPaint but it never worked properly with my tablet. I did buy ArtRage at some point but I wasn’t happy with the tools in that. It came down to probably a choice of Krita or Clip Studio Paint. Krita had the price tag of free so it was the first one I tried. And I stuck with it.

What was your first impression?

Wow.

At least I think it was. When I first tried it everything just seemed to work straight off. It seemed simple enough for me to use efficiently. And the brush engine was simply amazing. I don’t know if there’s any other program with brushes that easy to customize to a huge extent but still so simple to set up. I first tried it in version 2.something so it was before animation was added.

What do you love about Krita?

Mostly, the fact that it works to use for most things you can throw at it. I’ve made game assets, textures, paintings, drawings, pixel art, a couple of test animations with the animation function, pretty much everything. I feel like it’s the Blender of 2d, the free tool that does pretty much everything, maybe not the 100% best at it, but certainly the most economical option.

The brush engine like I said before is one of it’s best assets, it has one of the most useful color pickers I’ve used, the inclusion of what is the feature-set of the paid plugin Lazy Nezumi for Photoshop for free, the fact that the interface can be there when you need it but vanish at the press of the button. Just loads of good things.

The variety of brush packs made by the community are also a great asset. I own GDQuest’s premium bundle and also use Deevad’s pack on a regular basis. I love to then tweak those brushes to suit my needs.

What do you think needs improvement in Krita? Is there anything that really annoys you?

The main current annoyance with Krita is the text tool. I just hate it. It’s the one thing that makes me want to have access to Photoshop. And I know it’s supposedly one of the things being focused on in future updates, so hopefully they don’t take too long to happen.

Another problem I had with Krita happened last year. It’s been fixed since, but it’s certainly nothing I’d like to see happen again with V4 (Which I worry is a possibility). Basically what happened was when the Krita 3 update came out it broke support for my Ugee graphics monitor. Completely broke it. I had to either stick with the old version of Krita 2.9, or when I wanted to use tools from V3 I had to uninstall my screen tablet drivers, install drivers for my tiny old Intuos Small tablet and use that. Luckily, later on, (about 6-8 months down the line) an update for my tablet drivers fixed all problems, and it just worked with my screen tablet from then on.

What sets Krita apart from the other tools that you use?

Ease of use, the brush engine, the speed that it works at (even with 4k documents on my pentium powered laptop), the way it currently works well on all my hardware, the price tag (FREE!), the community, and some great providers of custom brushes (GDQuest and David Revoy’s in particular). Even though I’ve since stopped using Krita for pixel art and moved to Aseprite (only because their pixel animation tools are more sophisticated towards making game assets), I believe it’s the most suitable program I have access to for digital painting, comic art, and traditional 2d animation.

If you had to pick one favourite of all your work done in Krita so far, what would it be, and why?

This is a hard question because I feel I am a terrible critic. If I had to choose it’d probably be Sailing to the Edge of the World II – from my Sailing to the Edge of the world painting series I made for a good colleague of mine. I also included the latest painting in that series, though I believe the second one was the best. Even though it’s been maybe 8 months since I made that painting it’s still one of my best.

What techniques and brushes did you use in it?

If I remember correctly I used mostly David Revoy’s brush-pack. The painterly brushes were used along with the pen and ink brushes and some of the airbrushes. To be honest it’s been so long since I made it I’m not 100% sure. I may have also used some of the default brushes such as the basic round and soft round.

Where can people see more of your work?

My DeviantArt(where I post the majority of my art):
https://fatal-exit.deviantart.com/
My twitter (where I post some of my art):
https://twitter.com/FatalExit
And my newest place: Tumblr (Not much here at all):
https://www.tumblr.com/blog/fatalexit

Anything else you’d like to share?

I’m working on resurrecting my Youtube channel at:
https://www.youtube.com/channel/UCdnUE1bkY2suvUvZhIj9rIQ

As of the time of writing this it’s mostly just home to my music. However I’m looking to expand it into art, animation and game development, with tutorials and process videos. I’m certainly hoping to post some Krita reviews, tutorials and videos on how it can be used in a game development pipeline over the coming months, as well as videos of other software such as Blender, Aseprite, 3d Coat, Moho, Construct 3, Gamemaker Studio 2, Unreal Engine 4, Sunvox, FL Studio Mobile and others.

October 12, 2017

Letter to the New Mexico Public Education Department on Science Standards

For those who haven't already read about the issue in the national press, New Mexico's Public Education Department (a body appointed by the governor) has a proposal regarding new science standards for all state schools. The proposal starts with the national Next Generation Science Standards but then makes modifications, omitting points like references to evolution and embryological development or the age of the Earth and adding a slew of NM-specific standards that are mostly sociological rather than scientific.

You can read more background in the Mother Jones article, New Mexico Doesn’t Want Your Kids to Know How Old the Earth Is. Or why it’s getting warmer, including links to the proposed standards. Ars Technica also covered it: Proposed New Mexico science standards edit out basic facts.

New Mexico residents have until 5.p.m. next Monday, October 16, to speak out about the proposal. Email comments to rule.feedback@state.nm.us or send snail mail (it must arrive by Monday) to Jamie Gonzales, Policy Division, New Mexico Public Education Department, Room 101, 300 Don Gaspar Avenue, Santa Fe, New Mexico 87501.

A few excellent letters people have already written:

I'm sure they said it better than I can. But every voice counts -- they'll be counting letters! So here's my letter. If you live in New Mexico, please send your own. It doesn't have to be long: the important thing is that you begin by stating your position on the proposed standards.


Members of the PED:

Please reconsider the proposed New Mexico STEM-Ready Science Standards, and instead, adopt the nationwide Next Generation Science Standards (NGSS) for New Mexico.

With New Mexico schools ranking at the bottom in every national education comparison, and with New Mexico hurting for jobs and having trouble attracting technology companies to our state, we need our students learning rigorous, established science.

The NGSS represents the work of people in 26 states, and is being used without change in 18 states already. It's been well vetted, and there are many lesson plans, textbooks, tests and other educational materials available for it.

The New Mexico Legislature supports NGSS: they passed House Bill 211 in 2017 (vetoed by Governor Martinez) requiring adoption of the NGSS. The PED's own Math and Science Advisory Council (MSAC) supports NGSS: they recommended in 2015 that it be adopted. Why has the PED ignored the legislature and its own advisory council?

Using the NGSS without New Mexico changes will save New Mexico money. The NGSS is freely available. Open source textbooks and lesson plans are already available for the NGSS, and more are coming. In contrast, the New Mexico Stem-Ready standards would be unique to New Mexico: not only would we be left out of free nationwide educational materials, but we'd have to pay to develop New Mexico-specific curricula and textbooks that couldn't be used anywhere else, and the resulting textbooks would cost far more than standard texts. Most of this money would go to publishers in other states.

New Mexico consistently ranks at the bottom in educational comparisons. Yet nearly 15% of the PED's proposed stem-ready standards are New Mexico specific standards, taught nowhere else, and will take time away from teaching core science concepts. Where is the evidence that our state standards would be better than what is taught in other states? Who are we to think we can write better standards than a nationwide coalition?

In addition, some of the changes in the proposed NM STEM-Ready Science Standards seem to be motivated by political ideology, not science. Science standards used in our schools should be based on widely accepted scientific principles. Not to mention that the national coverage on this issue is making our state a laughingstock.

Finally, the lack of transparency in the NMSRSS proposal is alarming. Who came up with the proposed NMSRSS standards? Are there any experts in science education that support them? Is there any data to indicate they'd be more effective than the NGSS? Why wasn't the development of the NMSRSS discussed in open PED meetings as required by the Open Meetings Act?

The NGSS are an established, well regarded national standard. Don't shortchange New Mexico students by teaching them watered-down science. Please discard the New Mexico Stem-Ready proposal and adopt the Next Generation Science Standards, without New Mexico-specific changes.

October 11, 2017

Have typography, will travel

Howdy!

I realize that I’m a bit late in publishing this news but, to be honest, I never was great about the blogging regularly anyway.

In any case, this post is a bit of a public announcement: I’m happy to say that I recently completed an extremely busy year working on my Master of Arts in Typeface Design (MATD) degree at the University of Reading. Consequently, I am now back out in the real world, and I am looking for interesting and engaging employment opportunities. Do get in touch if you have ideas!

For a bit of additional detail, the MATD program combines in-depth training about letterforms, writing, non-Latin scripts, and typeface development with rigorous academic research. On the practical side, we each developed a large, multi-style, mutli-script family of fonts (requiring the inclusion of at least one script that we do not read).

My typeface is named Sark; you can see a web and PDF specimen of it here at the program’s public site. It covers Latin, Greek, Cyrillic, and Bengali; there is a serif subfamily tailored for long-form documents and there is a sans-serif subfamily that incorporates features to make it usable on next-generation display systems like transparent screens and HUDs.

My dissertation was research into software models for automatic (and semi-automatic) spacing and kerning of fonts. It’s not up for public consumption yet (in any formal way), as we are still awaiting the marking and review process. But if you’re interested in the topic, let me know.

Anyway, it was a great experience and I’m glad to have done it. I’m also thrilled that it’s over, because it was intense.

Moving ahead from here, I am looking forward to reconnecting with the free-software community, which I only had tangential contact with during my studies. That was hard; I spent more than thirteen years working full-time as a journalist exclusively covering the free-and-open-source software movement. I did get to see a lot of my friends who work on typography and font-related projects, because I still overlapped with those circles; I look forward to seeing the rest of you at the next meetup, conference, hackathon, or online bikeshedding session.

As for what sort of work I’m looking for, I’m keeping an open mind. What I would really love to find is a way (or ways) to help improve the state of type, typography, and documents within free-software systems. The proprietary software world has typefaces and text-rendering technology that is determined by things like sales figures; free software has no such limitations. The best typesetting systems in the world (like TeX and SILE) are free software; our documents and screens and scripts have no reason to look second-best, compared to anyone.

So if I can do that, I’ll be a happy camper. But by all means, I’m still going to remain a camper with a lot of diverse and peculiar interests, so if there’s a way I can help you out in some other fashion, don’t be shy; let me know.

I have a few contract opportunities I’m working on at the moment, and I am contributing to LWN (the best free-software news source in the dimension) as time allows. And I’m gearing up to tell you all about the next editions of Texas Linux Fest and Libre Graphics Meeting. Oh, and there are some special secret projects that I’m saving for next time….

So that’s it from me; how are you?

Krita 3.3.1

Today we are releasing Krita 3.3.1, a bugfix release for Krita 3.3.0. This release fixes two important regressions:

  • Krita would crash if you would restart Krita after closing Krita with the reference images docker set to floating
  • Krita 3.3.0 could not read .kra backup files or .kra files that were unzipped, then zipped up manually.

Additionally, there are the following fixes and improvements:

  • Fix a crash when creating a swap file on OSX (Bernhard Liebl).
  • Merge down does not remove locked layers anymore (Nikita Smirnov)
  • Various performance improvements, especially for macOS (Bernhard Liebl)
  • Improve the look and feel of dragging and dropping layers (Bernhard Liebl)
  • Improve the tooltips in the brush preset selector (Bernhard Liebl)
  • Fix a memory leak in the color selectors (Boudewijn Rempt)
  • Fix rotation and tilt when using the Windows Ink api (Alvin Wong)
  • Don’t allow the fill tool to be used on group layers (Boudewijn Rempt)
  • Add brightness and contrast sliders for textured brushes (Rad)
  • Add paste-at-cursor (Dmitry Kazakov)
  • Improve performance of the cpu canvas (Alvin Wong)
  • Fix a crash on closing Krita when there is something on the clipboard (Dmitry Kazakov)
  • Add a button to open a file layer’s image in Krita (Wolthera van Hövell tot Westerflier)

Download

Windows

Note for Windows users: if you encounter crashes, please follow these instructions to use the debug symbols so we can figure out where Krita crashes.

Linux

(If, for some reason, Firefox thinks it needs to load this as text: to download, right-click on the link.)

When it is updated, you can also use the Krita Lime PPA to install Krita 3.3.1 on Ubuntu and derivatives. There is also an updated snap.

OSX

Note: the gmic-qt and pdf plugins are not available on OSX.

Source code

md5sums

For all downloads:

Key

The Linux appimage and the source tarball are signed. You can retrieve the public key over https here:
0x58b9596c722ea3bd.asc
. The signatures are here.

Support Krita

Krita is a free and open source project. Please consider supporting the project with donations or by buying training videos or the artbook! With your support, we can keep the core team working on Krita full-time.

October 10, 2017

Announce: Entangle “Lithium“ release 1.0 – an app for tethered camera control & capture

I am pleased to announce a new release 1.0 of Entangle is available for download from the usual location:

  https://entangle-photo.org/download/

This release brings some significant changes to the application build system and user interface

  • Requires Meson + Ninja build system instead of make
  • Switch to 2-digit version numbering
  • Fix corruption of display when drawing session browser
  • Register application actions for main operations
  • Compile UI files into binary
  • Add a custom application menu
  • Switch over to using header bar, instead of menu bar and tool bar.
  • Enable close button for about dialog
  • Ensure plugin panel fills preferences dialog
  • Tweak UI spacing in supported cameras dialog
  • Add keyboard shortcuts overlay

Ta-Nehisi Coates on The Ezra Klein Show

This interview with Ta-Nehisi Coates on The Ezra Klein Show actually made me stop washing the dishes and just stand there in the kitchen.

October 09, 2017

fwupd hits 1.0.0

Today I released fwupd version 1.0.0, a version number most Open Source projects seldom reach. Unusually it bumps the soname so any applications that link against libfwupd will need to be rebuilt. The reason for bumping is that we removed a lot of the cruft we’ve picked up over the couple of years since we started the project, and also took the opportunity to rename some public interfaces that are now used differently to how they were envisaged. Since we started the project, we’ve basically re-architected the way the daemon works, re-imagined how the metadata is downloaded and managed, and changed core ways we’ve done the upgrades themselves. It’s no surprise that removing all that crufty code makes the core easier to understand and maintain. I’m intending to support the 0_9_X branch for a long time, as that’s what’s going to stay in Fedora 26 and the upcoming Fedora 27.

Since we’ve started we now support 72 different kinds of hardware, with support for another dozen-or-so currently being worked on. Lots of vendors are now either using the LVFS to distribute firmware, or are testing with one or two devices in secret. Although we have 10 (!) different ways of applying firmware already, vendors are slowly either switching to a more standard mechanism for new products (UpdateCapsule/DFU/Redfish) or building custom plugins for fwupd to update existing hardware.

Every month 165,000+ devices get updated using fwupd using the firmware on the LVFS; possibly more as people using corporate mirrors and caching servers don’t show up in the stats. Since we started this project there are now at least 600,000 items of hardware with new firmware. Many people have updated firmware, fixing bugs and solving security issues without having to understand all the horrible details involved.

I guess I should say thanks; to all the people both uploading firmware, and the people using, testing, and reporting bugs. Dell have been a huge supporter since the very early days, and now smaller companies and giants like Logitech are also supporting the project. Red Hat have given me the time and resources that I need to build something as complicated and political as shared infrastructure like this. There is literally no other company on the planet that I would rather work for.

So, go build fwupd 1.0.0 in your distro development branch and report any problems. 1.0.1 will follow soon with fixes I’m sure, and hopefully we can make some more vendor announcements in the near future. There are a few big vendors working on things in secret that I’m sure you’ll all know :)

October 07, 2017

Planetary features: Call to translators

Dear translators and users!

Thank you very much for your efforts for make Stellarium available to non-English community!

We incorporated into main package a long awaited feature - support of nomenclature for planetary features. All nomenclature items are translatable and this is a big problem now for translators, because we added over 15000 new lines for translation.

All those lines was extracted in the separate category - stellarium-planetary-features. If you can assist with translation to any of the 140 languages which Stellarium supports, please go to Launchpad Translations and help us out: https://translations.launchpad.net/stellarium

Thank you!

October 06, 2017

Tarantula Under Glass, and Micro-Centipedes

Every fall, Dave and I eagerly look for tarantulas. They only show up for a few weeks a year -- that's when the males go out searching for females (the females stay snug in their burrows). In the bay area, there were a few parks where we used to hunt for them: Arastradero, Mt Hamilton, occasionally even Alum Rock. Here in semi-rural New Mexico, our back yard is as good a place to hunt as anywhere else, though we still don't see many: just a couple of them a year.

But this year I didn't even have to go out into the yard. I just looked over from my computer and spotted a tarantula climbing up our glass patio door. I didn't know they could do that!

Unfortunately it got to the top before I had the camera ready, so I didn't get a picture of tarantula belly. Right now he's resting on the sill: [Tarantula, resting after climbing up our glass patio door] I don't think it's very likely he's going to find any females up there. I'm hoping he climbs back down the same way and I can catch a photo then. (Later: nope, he disappeared when I wasn't watching.)

In other invertebrate news: we have a sporadic problem with centipedes here in White Rock. Last week, a seven-inch one dropped from the ceiling onto the kitchen floor while I was making cookies, and it took me a few minutes to chase it down so I could toss it outside.

[Tiny baby centipede] But then a few days later, Dave spotted a couple of these little guys on the patio, and I have to admit they're pretty amazing. Just like the adults only in micro-miniature.

Though it doesn't make me like them any better in the house.

October 02, 2017

Interview with Emily Wei

Could you tell us something about yourself?

Hi! My name is Emily Wei, and I’m 19 years old. I was born in Taiwan, but I grew up in New Jersey. Right now, I’m back in Taiwan juggling university, freelance work, sleep, and a one-year course I’m taking at Kadokawa International Edutainment (Advanced Commercial Illustration).

Do you paint professionally, as a hobby artist, or both?

I suppose I’d be considered a hobbyist as of now since I’m not making money off art yet, but I aim to do it professionally in the near future!

What genre(s) do you work in?

My main love is in illustration, but a lot of the things I’ve been working on lately fall under concept design, so things like characters and 2D game assets, among others. Stylewise, I’m somewhere between anime, fantasy/RPG video games, and emotional surrealism. Basically, I’m kind of all over the place since I’m trying different things to get a feel for what my likes and dislikes are; I’ve recently fallen in love with doing background illustrations, for example!

Whose work inspires you most — who are your role models as an artist?

That’s really tough; there are too many! Pretty much everyone I’m following on Twitter/DeviantArt/Artstation, masters like Sargent and Mucha as well as my friends and mentors.

How and when did you get to try digital painting for the first time?

I think I was about 9 or 10 when I started? I was a hardcore Neopets user at the time, and at some point, I stumbled upon the art community there. That led to me discovering How to Draw ____ in Photoshop tutorials by an artist I really looked up to (shameless plug: her social media handle name is droidnaut across various platforms! Do check her out ^^)

It really amazed me how versatile digital art was, and I’ve never stopped since.

What makes you choose digital over traditional painting?

Short version: CTRL+Z!

Long version: Digital art is much more forgiving than traditional medias, and you don’t really need to keep buying art supplies (not counting Adobe CC subscriptions, hardware upgrades, plugins, etc.) There are a lot of tools you can use that save you a boatload of time, and it’s easier to make changes to your work as needed.

That said, I do love traditional art. There’s nothing quite like the feeling of putting pen on paper! It’s also easier in some aspects; for
example, drawing decent circles (and most geometric shapes in general) freehand is ridiculously harder with a tablet. Limited supplies also makes you be more economic and decisive about what goes where, which is a mindset I’d like to carry over into my digital work more.

How did you find out about Krita?

I don’t really remember, actually! I think I might’ve seen a thread about it on Neopets or a post on tumblr. It was some time after the Kickstarter for Krita 3.0 ended, and the “faster than Photoshop” part of the campaign despite all the tools the program offered had me intrigued.

What was your first impression?

“Wow! This is almost just like Photoshop!” The UI is very similar, haha.

What do you love about Krita?

The brush engines are really fantastic. There are a lot of traditional media-esque brushes for people who like a little roughness/texture as well as the standard digital round opacity brushes and soft airbrushes. Here’s one of the first few sketches I did with Krita back in 2015:

There’s also the option to convert your artwork to CMYK if you want to make prints and merch, which is really convenient.

What do you think needs improvement in Krita? Is there anything that really annoys you?

I suppose my only qualm is that the text tool and I don’t really seem to get along, haha. Text input and changing the font size is oddly challenging. It’s not that big of a deal, though.

This might have changed in version 3, but I’m still using version two-point-something since my computer can’t quite handle the newest
version.

What sets Krita apart from the other tools that you use?

I find it amazing how much you can do with a program that is legitimately free to download! It’s basically Photoshop condensed down to just the tools and functions a CG illustrator would use. I think this is especially nice for people who are new to digital art since they can get into it without putting a huge dent into your wallet (or pirating 🙂 ).

And again, the brushes are great.

If you had to pick one favourite of all your work done in Krita so far, what would it be, and why?

Probably “No”!

It’s not the most technically advanced work I’ve done, and the story behind it isn’t exactly happy, but I still like the colors, the clothing folds, and the overall composition.

What techniques and brushes did you use in it?

I don’t really remember what brushes I used, actually! I do have a favorite brushes preset, though, so they’re probably among them.

As for techniques, nothing super fancy beyond simple digital painting and blending.

Where can people see more of your work?

Twitter: https://twitter.com/waytooemily
Tumblr: http://waytooemily.tumblr.com
Plurk: http://plurk.com/waytooemily
Pixiv: http://pixiv.me/waytooemily
DeviantArt: http://waytooemily.deviantart.com
Instagram: https://instagram.com/waytooemily
Facebook: https://www.facebook.com/waytooemily
Artstation: https://www.artstation.com/artist/waytooemily

Feel free to follow me, come say hi, ask me questions, whatever! I’m most active on Twitter, Tumblr, and Plurk.

(I’m still in the process of updating my Facebook page, Artstation, and Instagram, so hopefully there will be things for you to look at there by the time you read this.)

Anything else you’d like to share?

In a nutshell, people always say how tools do not a craftsman make, and the same thing is true with digital art. The most expensive programs and tablets in the world will not make you a master overnight, nor do you need them to make art. Explore different options (like Krita!), learn as much as you can, and just have fun with it 😀

October 01, 2017

FreeCAD Arch development news - September 2017

Hi everybody! Here we are for another monthly report about the development of BIM tools for FreeCAD, our favorite open-source 3D CAD modeling platform. The coding I am doing for FreeCAD is now more and more heavily supported and funded by many of you via my Patreon page, thanks once more to everybody who contributes...

September 30, 2017

Bullet 2.87 with pybullet robotics Reinforcement Learning environments

Bullet 2.87 has improved support for robotics, reinforcement learning and VR. In particular, see the “Reinforcement Learning” section in the pybullet quickstart guide at http://pybullet.org . There are also preliminary C# bindings to allow the use of pybullet inside Unity 3D for robotics and reinforcement learning. In addition, vectorunit Beach Buggy Racing using Bullet has been released for the Nintendo Switch!

beach-buggy-racing

You can download the release from https://github.com/bulletphysics/bullet3/releases
Here are some videos of some Bullet reinforcement learning environments trained using TensorFlow Agents PPO:

See also KUKA grasping
and pybullet Ant

September 29, 2017

Stellarium 0.16.1

Version 0.16.1 is based on Qt 5.6.2, but it can still be built from sources with Qt 5.4.
This version is bugfix release with some important features:
- Added moons of Saturn, Uranus and Pluto
- Added improvements for AstroCalc tool
- DSO catalog was updated to version 3.2:
-- Added support 'The Strasbourg-ESO Catalogue of Galactic Planetary Nebulae' (Acker+, 1992)
-- Added support 'A catalogue of Galactic supernova remnants' (Green, 2014)
-- Added support 'A Catalog of Rich Clusters of Galaxies' (Abell+, 1989)
- Added support asterisms and outlines for DSO
- Added improvements for the GUI

A huge thanks to the people who helped us a lot by reporting bugs!

Full list of changes:
- Added two notations for unit of measurement of surface brightness
- Added improvement for hide/unhide lines and grids in Oculars plugin
- Added few moons of Saturn (Phoebe, Janus, Epimetheus, Helene, Telesto, Calypso, Atlas, Prometheus, Pandora, Pan) with classic elliptical orbits
- Added few moons of Uranus (Cordelia, Cressida, Desdemona, Juliet, Ophelia) with classic elliptical orbits
- Added 2 moons of Pluto (Kerberos and Styx) with classic elliptical orbits
- Added code to avoid conflicts for names of asteroids and moons
- Added support of IAU moon numbers
- Added angular size into AstroCalc/Positions tool
- Added option to allow users to choose output formatting of coordinates of objects
- Added optional debug info for HDPI devices
- Added optional calculations of resolution limits for Oculars plugin
- Added new data from IAU Catalog of Star Names (LP: #1705111)
- Added support download zip archives with TLE data to Satellites plugin
- Added link to the Mike McCants' classified TLE data into the default list of TLE sources
- Added link to AMSAT TLE data into the default list of TLE sources
- Added support 'The Strasbourg-ESO Catalogue of Galactic Planetary Nebulae' (Acker+, 1992) [DSO catalog version 3.2]
- Added support 'A catalogue of Galactic supernova remnants' (Green, 2014) [DSO catalog version 3.2]
- Added support 'A Catalog of Rich Clusters of Galaxies' (Abell+, 1989) [DSO catalog version 3.2]
- Added export the predictions of Iridium flares (LP: #1707390)
- Added meta information about version and edition into file of Stellarium DSO Catalog to avoid potential crash of Stellarium in the future (validation the version of catalog before loading)
- Added support of extra physical data for asteroids
- Added support of outlines for DSO
- Added new time step: saros
- Added new time step: 7 sidereal days
- Added more checks to the network connections
- Added support of comments for constellations_boundaries.dat file (LP: #1711433)
- Added support for small asterisms with lines by the equatorial coordinates
- Added support for ray helpers
- Added new feature (crossed lines and output string near mouse cursor) to the Pointer Coordinates plugin
- Added missing cross-id data
- Added support an images within description of landscapes
- Added support Visual Studio 2017 in StelLogger
- Added tool to save list of objects in AstroCalc/WUT tool
- Added tool to save celestial positions of objects in AstroCalc/Positions tool
- Added temporary solution for bug 1498616 (LP: #1498616)
- Fixed wrong rendering Neptune and Uranus (LP: #1699648)
- Fixed Vector3 compilation error in unit tests (LP: #1700095)
- Fixed a conflict around landscape autoselection (LP: #1700199)
- Fixed HMS formatting
- Fixed generating ISS script
- Fixed tooltips for AstroCalc/Positions tool
- Fixed dark nebulae parameters for AstroCalc/Positions tool
- Fixed tool for saving options
- Fixed crash when we on the spaceship
- Fixed Solar system class to avoid conflicts and undefined behaviour
- Fixed orientation angle and its data rendering (LP: #1704561)
- Fixed wrong shadows on Jupiter's moons (Added special case for Jupiter's moons when they are in the shadow of Jupiter for compute magnitudes from Expl. Suppl. 2013 item) (LP: #1704421)
- Fixed work AstroCalc/AltVsTime tool for artificial satellites (a bit slow solution though)
- Fixed search by lists of DSO
- Fixed translation switch issue for AstroCalc/Graphs tool (LP: #1705341)
- Fixed trackpad behaviour on macOS though workaround
- Fixed couple stupid bugs in InnoSetup script
- Fixed morphology for SNR
- Fixed issue in parsing of date format in AstroCalc/Phenomena tool
- Fixed link for fileStructure.html file in README (LP: #1709523)
- Fixed the calculation for drawing a reticle on a HiDPI display (Oculars plugin)
- Fixed default option of units of measure for surface brighness to avoid possible artifacts on the macOS (LP: #1699643)
- Fixed crash when comments is added into constellations_boundaries.dat file (LP: #1711229)
- Fixed behaviour of 'Center on selected object' button (LP: #1712101)
- Fixed impossibility to select a planet after Astronomical Calculations is activated (LP: #1712652)
- Fixed crash with unknown star in asterism
- Fixed cross-ids of 42 bright double stars (LP: #1655493)
- Fixed magnitude computation for Jupiter's satellites
- Fixed crash of Stellarium when answer of freegeoip.net has wrong format (for example this host blocked by firewall or DNS server with HTML answer) (LP: #1706187)
- Fixed translations issue in Script Console
- Fixed illumination in Scenery3D plugin: Take eclipseFactor into account
- Fixed potential crash in DSO outlines
- Fixed various issues in ray helpers, asterisms and constellations support
- Updated InfoString feature
- Updated sky brightness during solar eclipse (really, there are only few stars visible.)
- Updated Maori sky culture
- Updated list of names of deep-sky objects
- Updated list of asterisms
- Updated selection behaviour in Oculars plugin (avoid selection of objects outside ocular circle in eyepiece mode)
- Updated behaviour of methods getEnglishName() and getNameI18n() for minor bodies
- Updated behaviour of planetarium for support a new format of asteroid names
- Updated behaviour of filters for DSO catalogs
- Updated Solar System Editor plugin (support new format of asteroid names)
- Updated RTS2 telecope driver in Telescope Control plugin.
- Updated API docs
- Updated limit of magnitude for Oculars plugin (Improvements)
- Updated AstroCalc/WUT tool
- Updated AstroCalc/Ephemeris tool
- Updated rules for storing default settings
- Updated rules for computation visibility of DSO hints
- Updated plugins
- Updated default values for material fade-in/fade-out times
- Updated stellarium.appdata.xml file
- Updated tab rules in the GUI
- Reduce warnings to one when loading OBJ with non-default w texture/vertex coordinates

Keep the Raws Coming


Keep the Raws Coming

Moar samples!

Our friendly neighborhood @LebedevRI pointed out to me a little while ago that we had reached some nice milestones for https://raw.pixls.us. Not surprisingly I had spaced out and not written anything about it (or really any sort of social posts). Bad Pat!

So let’s talk about raw.pixls.us (RPU) a bit!

Recap

For anyone not familiar with RPU, a quick recap (we had previously written about raw.pixls.us earlier this year). There used to be a website for housing a repository of raw files for as many digital cameras as possible called rawsamples.ch. It was created by Jakob Rohrbach and had been running since March of 2007. Back in 2016 the site was hit with a SQL injection attack that left the Joomla database corrupted (in a teachable moment, the site also didn’t have a database backup).

With the rawsamples.ch site down, @LebedevRI and @andabata worked to get a replacement option in-place and working: https://raw.pixls.us!

Sexy Stats

We grabbed all the files we could salvage from rawsamples.ch and @andabata setup the new page. We’ve had a slowly growing response as folks have filled in gaps for camera models we still don’t have.

For reference, we currently have count of unique cameras in the archive unique cameras, and total count of unique samples unique samples.

RPU samples graph
RPU cameras graph

Moar samples!

As @LebedevRI has said, we still really need folks to check RPU and send us more samples!

  • We currently only have about 77% coverage.
  • We want to replace any non-CC0 (public domain) samples with CC0 licensed samples.
  • We are still missing some rarer samples like any medium-format or Sigma samples.

Our hope is that some casual reader out there might look at the list and say “Hey! I’ve got that camera lying around - let me submit a sample!”.

Here’s the current list of missing camera samples:

Canon EOS Kiss Digital F
Canon EOS Kiss X7
Canon EOS Kiss X70
Canon EOS Kiss X80
Canon EOS Kiss X9
Canon EOS Rebel SL2
Canon EOS Kiss Digital
Canon EOS Kiss Digital X
Canon Kiss Digital X2
Canon Kiss X2
Canon EOS 5DS
Canon EOS Kiss X5
Canon EOS Kiss X6i
Canon EOS Rebel T4i
Canon EOS Kiss X7i
Canon EOS Kiss X8i
Canon EOS 8000D
Canon EOS Rebel T6s
Canon EOS 9000D
Canon EOS Kiss X9i
Canon EOS M10
Canon EOS M2
Canon PowerShot G9 X
Canon PowerShot S95
Canon PowerShot SX260 HS
Fujifilm FinePix HS30EXR
Fujifilm FinePix HS50EXR
Fujifilm FinePix S100FS
Fujifilm FinePix S5200
Fujifilm FinePix S5500
Fujifilm FinePix S6000fd
Fujifilm FinePix S9000
Fujifilm FinePix S9600fd
Fujifilm IS-1
Fujifilm XF1
Fujifilm XQ2
Kodak EasyShare Z980
Kodak P880
Leaf Aptus-II 5
Leaf Credo 40
Leaf Credo 60
Leaf Credo 80
Leica D-LUX 4
Leica D-LUX 5
Leica D-LUX 6
Leica X2
Minolta DiMAGE 5
Minolta Alpha 5D
Minolta Maxxum 5D
Minolta Alpha 7D
Minolta Maxxum 7D
Nikon 1 J3
Nikon 1 J4
Nikon 1 S1
Nikon 1 V3
Nikon Coolpix A
Nikon Coolpix P7700
Nikon D1H
Nikon D2H
Nikon D2Hs
Nikon D3S
Nikon D4S
Nokia Lumia 1020
Olympus E-10
Olympus E-400
Olympus E-PL1
Olympus E-PL2
Olympus SP320
Olympus SP570UZ
Olympus Stylus1
Olympus XZ-10
Panasonic DMC-FZ80
Panasonic DMC-FZ85
Panasonic DC-FZ91
Panasonic DC-FZ92
Panasonic DC-FZ93
Panasonic DC-ZS70
Panasonic DMC-FX150
Panasonic DMC-FZ100
Panasonic DMC-FZ35
Panasonic DMC-FZ40
Panasonic DMC-FZ50
Panasonic DMC-G5
Panasonic DMC-G8
Panasonic DMC-G85
Panasonic DMC-GF2
Panasonic DMC-GM5
Panasonic DMC-LX9
Panasonic DMC-TZ110
Panasonic DMC-ZS110
Panasonic DMC-ZS40
Panasonic DMC-ZS50
Panasonic DMC-TZ85
Panasonic DMC-ZS60
Pentax 645Z
Pentax K2000
Pentax Q10
Pentax Q7
Phase One IQ250
Ricoh GR
Ricoh GR II
Samsung EK-GN120
Samsung GX10
Samsung GX20
Samsung NX10
Samsung NX1000
Samsung NX11
Samsung NX1100
Samsung NX20
Samsung NX2000
Samsung NX210
Samsung NX5
Sinar Hy6
Sony DSC-RX1
Sony DSC-RX1R
Sony DSLR-A230
Sony DSLR-A290
Sony DSLR-A380
Sony DSLR-A390
Sony DSLR-A450
Sony DSLR-A500
Sony DSLR-A560
Sony ILCE-3000
Sony ILCE-3500
Sony NEX-5N
Sony NEX-C3
Sony NEX-F3
Sony SLT-A33

If you have any of the cameras on this list and don’t mind spending a few minutes uploading a sample file, we would be very grateful for the help!

Don’t forget that we are looking for:

  • Lens mounted on the camera, cap off
  • Image in focus and properly exposed
  • Landscape orientation

and we are not looking for:

  • Series of images with different ISO, aperture, shutter, wb, lighting, or different lenses
  • DNG files created with Adobe DNG Converter
  • Photographs of people, for legal reasons.

If you don’t see your camera on this list, you’re not off the hook yet! We are also looking for files that are licensed very freely…

Non Creative-Commons Zero (CC0)

We have many raw samples that were not licensed as freely as we would like. Ideally we are looking for images that have been released Creative Commons Zero (CC0). This list is all samples we already have that are not licensed CC0, so if you happen to have one of the cameras listed below please consider uploading some new samples for us!

Canon IXUS900Ti
Canon PowerShot A550
Canon PowerShot A570 IS
Canon PowerShot A610
Canon PowerShot A620
Canon PowerShot A630
Canon Powershot A650
Canon PowerShot A710 IS
Canon PowerShot G7
Canon PowerShot S2 IS
Canon PowerShot S5 IS
Canon PowerShot SD750
Canon Powershot SX110IS
Canon EOS 10D
Canon EOS 1200D
Canon EOS-1D
Canon EOS-1D Mark II
Canon EOS-1D Mark III
Canon EOS-1D Mark II N
Canon EOS-1D Mark IV
Canon EOS-1Ds
Canon EOS-1Ds Mark II
Canon EOS-1Ds Mark III
Canon EOS-1D X
Canon EOS 300D
Canon EOS 30D
Canon EOS 400D
Canon EOS 40D
Canon EOS 760D
Canon EOS D2000C
Canon EOS D60
Canon EOS Digital Rebel XS
Canon EOS M
Canon EOS Rebel T3
Canon EOS Rebel T6i
Canon PowerShot A3200 IS
Canon Powershot A720 IS
Canon PowerShot G10
Canon PowerShot G11
Canon PowerShot G12
Canon PowerShot G15
Canon PowerShot G1
Canon PowerShot G1 X Mark II
Canon PowerShot G2
Canon PowerShot G3
Canon PowerShot G5
Canon PowerShot G5 X
Canon PowerShot G6
Canon PowerShot Pro1
Canon PowerShot Pro70
Canon PowerShot S30
Canon PowerShot S40
Canon PowerShot S45
Canon PowerShot S50
Canon PowerShot S60
Canon PowerShot S70
Canon PowerShot S90
Canon PowerShot SD450
Canon Powershot SX110IS
Canon PowerShot SX130 IS
Canon PowerShot SX1 IS
Canon PowerShot SX50 HS
Canon PowerShot SX510 HS
Canon PowerShot SX60 HS
Canon Poweshot S3IS
Epson R-D1
Fujifilm FinePix E550
Fujifilm FinePix E900
Fujifilm FinePix F600EXR
Fujifilm FinePix F700
Fujifilm FinePix F900EXR
Fujifilm FinePix HS10 HS11
Fujifilm FinePix HS20EXR
Fujifilm FinePix S200EXR
Fujifilm FinePix S2Pro
Fujifilm FinePix S3Pro
Fujifilm FinePix S5000
Fujifilm FinePix S5600
Fujifilm FinePix S6500fd
Fujifilm FinePix X100
Fujifilm X100S
Fujifilm X-A2
Fujifilm XQ1
Hasselblad CF132
Hasselblad CFV
Hasselblad H3D
Kodak DC120
Kodak DC50
Kodak DCS460D
Kodak DCS560C
Kodak DCS Pro SLR/n
Kodak EOS DCS 1
Kodak Kodak C330
Kodak Kodak C603 / Kodak C643
Kodak Z1015 IS
Leaf Aptus 75
Leaf Leaf Aptus 22
Leica Leica Digilux 2
Leica Leica D-LUX 3
Leica M8
Leica M (Typ 240)
Leica V-LUX 1
Mamiya ZD
Minolta DiMAGE 7
Minolta DiMAGE 7Hi
Minolta DiMAGE 7i
Minolta DiMAGE A1
Minolta DiMAGE A200
Minolta DiMAGE A2
Minolta Dimage Z2
Minolta Dynax 5D
Minolta Dynax 7D
Minolta RD-175
Minolta RD-175
Nikon 1 S2
Nikon 1 V1
Nikon Coolpix P340
Nikon Coolpix P6000
Nikon Coolpix P7000
Nikon Coolpix P7100
Nikon D100
Nikon D1
Nikon D1X
Nikon D2X
Nikon D300S
Nikon D3
Nikon D3X
Nikon D40
Nikon D60
Nikon D70
Nikon D800
Nikon D80
Nikon D810
Nikon E5400
Nikon E5700
Nikon LS-5000
Nokia Lumia 1020
Olympus C5050Z
Olympus C5060WZ
Olympus C8080WZ
Olympus E-1
Olympus E-20
Olympus E-300
Olympus E-30
Olympus E-330
Olympus E-3
Olympus E-420
Olympus E-450
Olympus E-500
Olympus E-510
Olympus E-520
Olympus E-5
Olympus E-600
Olympus E-P1
Olympus E-P2
Olympus E-P3
Olympus E-PL5
Olympus SP350
Olympus SP500UZ
Olympus XZ-1
Panasonic DMC-FZ150
Panasonic DMC-FZ18
Panasonic DMC-FZ200
Panasonic DMC-FZ28
Panasonic DMC-FZ30
Panasonic DMC-FZ38
Panasonic DMC-FZ70
Panasonic DMC-FZ72
Panasonic DMC-FZ8
Panasonic DMC-G1
Panasonic DMC-G3
Panasonic DMC-GF3
Panasonic DMC-GF5
Panasonic DMC-GF7
Panasonic DMC-GH2
Panasonic DMC-GH3
Panasonic DMC-GH4
Panasonic DMC-GM1
Panasonic DMC-GX7
Panasonic DMC-L10
Panasonic DMC-L1
Panasonic DMC-LF1
Panasonic DMC-LX1
Panasonic DMC-LX2
Panasonic DMC-LX3
Panasonic DMC-LX5
Panasonic DMC-LX7
Panasonic DMC-TZ60
Panasonic DMC-TZ71
Pentax *ist D
Pentax *ist DL2
Pentax *ist DS
Pentax K100D Super
Pentax K10D
Pentax K20D
Pentax K-50
Pentax K-m
Pentax K-r
Pentax K-S1
Pentax Optio S4
Polaroid x530
Ricoh GR DIGITAL 2
Samsung EX2F
Samsung NX100
Samsung NX300
Samsung NX300M
Samsung NX500
Samsung WB2000
Sigma DP2 Quattro
Sigma DP1s
Sigma DP2 Merrill
Sigma SD10
Sigma SD14
Sigma SD9
Sony DSC-R1
Sony DSC-RX100
Sony DSC-RX100M2
Sony DSC-RX100M3
Sony DSC-RX100M4
Sony DSC-RX10
Sony DSC-RX10M2
Sony DSLR-A100
Sony DSLR-A200
Sony DSLR-A300
Sony DSLR-A330
Sony DSLR-A350
Sony DSLR-A550
Sony DSLR-A580
Sony DSLR-A700
Sony DSLR-A850
Sony DSLR-A900
Sony NEX-3
Sony NEX-5R
Sony NEX-7
Sony SLT-A35
Sony SLT-A58
Sony SLT-A77
Sony SLT-A99

We are really working hard to make sure we are a good resource of freely available raw samples for all Free Software imaging projects to use. Thank you so much for helping out if you can!

September 28, 2017

Audio Output from a Raspberry Pi Zero

Someone at our makerspace found a fun Halloween project we could do at Coder Dojo: a motion sensing pumpkin that laughs evilly when anyone comes near. Great! I've worked with both PIR sensors and ping rangefinders, and it sounded like a fun project to mentor. I did suggest, however, that these days a Raspberry Pi Zero W is cheaper than an Arduino, and playing sounds on it ought to be easier since you have frameworks like ALSA and pygame to work with.

The key phrase is "ought to be easier". There's a catch: the Pi Zero and Zero W don't have an audio output jack like their larger cousins. It's possible to get analog audio output from two GPIO pins (use the term "PWM output" for web searches), but there's a lot of noise. Larger Pis have a built-in low-pass filter to screen out the noise, but on a Pi Zero you have to add a low-pass filter. Of course, you can buy HATs for Pi Zeros that add a sound card, but if you're not super picky about audio quality, you can make your own low-pass filter out of two resistors and two capacitors per channel (multiply by two if you want both the left and right channels).

There are lots of tutorials scattered around the web about how to add audio to a Pi Zero, but I found a lot of them confusing; e.g. Adafruit's tutorial on Pi Zero sound has three different ways to edit the system files, and doesn't specify things like the values of the resistors and capacitors in the circuit diagram (hint: it's clearer if you download the Fritzing file, run Fritzing and click on each resistor). There's a clearer diagram in Sudomod Forums: PWM Audio Guide, but I didn't find that until after I'd made my own, so here's mine.

Parts list:

  • 2 x 270 Ω resistor
  • 2 x 150 Ω resistor
  • 2 x 10 nF or 33nF capacitor
  • 2 x 1μF electrolytic capacitor
  • 3.5mm headphone jack, or whatever connection you want to use to your speakers

And here's how to wire it: [Adding audio to the Raspberry Pi Zero]
(Fritzing file, pi-zero-audio.fzz.)

This wiring assumes you're using pins 13 and 18 for the left and right channels. You'll need to configure your Pi to use those pins. Add this to /boot/config.txt:

dtoverlay=pwm-2chan,pin=18,func=2,pin2=13,func2=4

Testing

Once you build your circuit up, you need to test it. Plug in your speaker or headphones, then make sure you can play anything at all:

aplay /usr/share/sounds/alsa/Front_Center.wav

If you need to adjust the volume, run alsamixer and use the up and down arrow keys to adjust volume. You'll have to press up or down several times before the bargraph actually shows a change, so don't despair if your first press does nothing.

That should play in both channels. Next you'll probably be curious whether stereo is actually working. Curiously, none of the tutorials address how to test this. If you ls /usr/share/sounds/alsa/ you'll see names like Front_Left.wav, which might lead you to believe that aplay /usr/share/sounds/alsa/Front_Left.wav might play only on the left. Not so: it's a recording of a voice saying "Front left" in both channels. Very confusing!

Of course, you can copy a music file to your Pi, play it (omxplayer is a nice commandline player that's installed by default and handles MP3) and see if it's in stereo. But the best way I found to test audio channels is this:

speaker-test -t wav -c 2

That will play those ALSA voices in the correct channel, alternating between left and right. (MythTV has a good Overview of how to use speaker-test.

Not loud enough?

I found the volume plenty loud via earbuds, but if you're targeting something like a Halloween pumpkin, you might need more volume. The easy way is to use an amplified speaker (if you don't mind putting your nice amplified speaker amidst the yucky pumpkin guts), but you can also build a simple amplifier. Here's one that looks good, but I haven't built one yet: One Transistor Audio for Pi Zero W

Of course, if you want better sound quality, there are various places that sell HATs with a sound chip and line or headphone out.

Krita 3.3.0

Less than a month after Krita 3.2.1, we’re releasing Krita 3.3.0. We’re bumping the version because there are some important changes, especially for Windows users in this version!

Alvin Wong has implemented support for the Windows 8 event API, which means that Krita now supports the n-trig pen in the Surface line of laptops (and similar laptops from Dell, HP and Acer) natively. This is still very new, so you have to enable this in the tablet settings:

And he also refactored Krita’s hardware-accelerated display functionality to optionally use Angle on Windows instead of native OpenGL. That means that many problems with Intel display chips and broken driver versions are worked around because Krita now can use Direct3D indirectly.

There are more changes in this release, of course:

  • Some visual glitches when using hi-dpi screens are fixed (remember: on Windows and Linux, you need to enable this in the settings dialog).
  • If you create a new image from clipboard, the image will have a title
  • Favorite blending modes and favorite brush presets are now loaded correctly on startup
  • GMIC
    • the plugin has been updated to the latest version for Windows and Linux.
    • the configuration for setting the path to the plugin has been removed. Krita looks for the plugin in the folder where the krita executable is, and optionally inside a folder with a name that starts with ‘gmic’ next to the krita executable.
    • there are several fixes for handling layers and communication between Krita and the plugin
  • Some websites save jpeg images with a .png extension: that used to confuse Krita, but Krita now first looks inside the file to see what kind of file it really is.
  • PNG:
    • 16 and 32 bit floating point images are now converted to 16 bit integer when saving the images as PNG.
    • It’s now possible to save the alpha channel to PNG images even if there are no (semi-) transparent pixels in the image
  • When hardware accelerated display is disabled, the color picker mode of the brush tool showed a broken cursor; this has been fixed.
  • The Reference Images docker now only starts loading images when it is visible, instead on Krita startup. Note: the reference images docker uses Qt’s imageio plugins to load images. If you are running on Linux, remove all Deepin desktop components. Deepin comes with severely broken qimageio plugins that will crash any Qt application that tries to display images.
  • File layers now correctly reload on change again
  • Add several new commandline options:
    • –nosplash to start Krita without showing the splash screen
    • –canvasonly to start Krita in canvas-only mode
    • –fullscreen to start Krita full-screen
    • –workspace Workspace to start Krita with the given workspace
  • Selections
    • The Select All action now first clears the selection before selecting the entire image
    • It is now possible to extend selections outside the canvas boundary
  • Performance improvements: in several places superfluous reads from the settings were eliminated, which makes generating a layer thumbnail faster and improves painting if display acceleration is turned off.
  • The smart number input boxes now use the current locale to follow desktop settings for numbers
  • The system information dialog for bug reports is improved
  • macOS/OSX specific changes:
    • Bernhard Liebl has improved the tablet/stylus accuracy. The problem with circles having straight line segments is much improved, though it’s not perfect yet.
    • On macOS/OSX systems with and AMD gpu, support for hardware accelerated display is disabled because saving to PNG and JPG hangs Krita otherwise.

Download

Windows

Note for Windows users: if you encounter crashes, please follow these instructions to use the debug symbols so we can figure out where Krita crashes.

Linux

(If, for some reason, Firefox thinks it needs to load this as text: to download, right-click on the link.)

When it is updated, you can also use the Krita Lime PPA to install Krita 3.3.0 on Ubuntu and derivatives.

OSX

Note: the gmic-qt and pdf plugins are not available on OSX.

Source code

md5sums

For all downloads:

Key

The Linux appimage and the source tarball are signed. You can retrieve the public key over https here:
0x58b9596c722ea3bd.asc
. The signatures are here.

Support Krita

Krita is a free and open source project. Please consider supporting the project with donations or by buying training videos or the artbook! With your support, we can keep the core team working on Krita full-time.

September 27, 2017

Enabling New Contributors

I had a random idea today and wanted to share it in case anybody has thought about this too, or tried something like it, or could add on to the idea.

How We Onboard Today

I onboard, mentor, and think a lot about enabling new contributors to open source software. Traditionally in Fedora, we’ve called out a ‘join’ process for people to join Fedora. If you visit join.fedoraproject.org, you’ll get redirected to a wiki page that gives broad categories of skill sets and suggests Fedora teams you might want to look at to see if you could join them.

I started thinking about this because I’m giving a keynote about open source and UX at Ohio Linux Fest this weekend. One of the sections of the talk basically reviews where / how to find UX designers to help open source projects. Some of the things I mention that have proven effective are internships (Outreachy, formal Red Hat intern program, etc.), training, and design bounties / job boards. Posting UX assistance on say join.fedoraproject.org? Didn’t come up. I can’t tell you if I’ve actually onboarded folks from that workflow – certainly possible. My best success ratio in onboarding contributors in terms of them feeling productive and sticking around the community for a while, though, is with the methods I listed above – not a general call for folks of a certain discipline to come to the design team.

In fact, one of the ways we onboard people to the design team is to assign them a specific task, with the thought that they can learn how our team / processes / tools work by doing, and have a task to focus on for getting help from another member of the team / mentor.

Successful Onboarding Methods are Task-Oriented

Thinking about this, these successful recruitment methods of new contributors all focus on tasks, not skills:

  • Internships – internships have a set time period focused on the completion of a particular project, scoped for that duration and complexity, that has been documented for the intern. This is such that digging through archives of proposed Outreachy and GSoC projects unearths (if it were still current) a great set of directions that any new contributor could use to get started.
  • Training – in my experience, when training folks without UX experience in UX, they had a specific task they were working on already, knew they needed the skill to complete it, and sought out help with the skill. A task was the driver to seek out the skill.
  • Job board postings – (e.g., like opensourcedesign.net/jobs) – they are focused on a specific task / thing to do.
  • Bounties – super task-focused!

If onboarding new contributors works well when those new contributors are put to work right away on a specific, assigned task with a well-defined scope, why do we attempt to recruit by categories of skills with loose pointers to teams (that get out of date), instead of tasks? You might have someone fired up to do *something*, but they’re redirected to a wiki page, to a mailing list, to wait a few days for something to respond and tell them “hi, welcome!” without actually helping them figure out what it is they could do.

An Idea For join.fedoraproject.org

If you’re with me here, up to this point… here’s the idea. I haven’t done it yet. I want to hear your feedback on it first.

I thought about redoing join.fedoraproject.org as a bounty board, really a job posting board, but let’s call it a bounty board. Bounties are very well defined tasks. I did a talk on how to create an effective bounty a while back, here’s the high-level crash-course:

  1. Set the Stage. Give the narrative around the task / project. What is the broader story around what the software / website / project / etc. does? Who does it help? How does it make the world a better place? Most importantly, what’s the problem to be solved that the bounty taker will work on, and how does it fit into that broader narrative?
  2. State the Mission. Make a clear statement at what exactly the bounty is – state what the successful completion of the bounty would look like / work.
  3. Provide a Specification with Clear Examples. Give all the details needed – the specification – for the completion of the work. Is there a specific process with steps they should follow? Provide those steps. A specific language,or a specific length, or a certain number of items? Make this all clear.
  4. Provide Resources and Tools. What are the resources that would be the most useful in completing this bounty? Where is the IRC channel for the project? The mailing list? Are there any design asset / source files they will need? How about style guidelines / specifications to follow? Will they need to create any accounts to submit their work? Where? Are there any tutorials / videos / documentation / blog posts that explains the technology of interest that they could refer to in order to familiarize themselves with the domain they’ll be working in? Link out to all this stuff.
  5. Outline the Benefits. Clearly and explicitly state what’s in it for them to take on this bounty. Job sites do (or at least, they try) this too. You’ll become a Fedora contributor! You’ll get a Fedora account and membership in the team, which will get you an email forward! When I did bounties, I sent handwritten thank you notes with some swag through the mail. You’ll gain skills in X, Y, or Z. You’ll make life better for our users. Some of this is obvious, but it helps to state it explicitly!
  6. Ground Rules and Contact Info. How does someone claim the bounty? Do they need to get an account and assign it to themselves? What happens if they don’t do anything and time has passed, can it be opened up to others interested? (We had a 48-hour rule before we passed on to the next person when we did this on the Design Team.) Who is the contact person / mentor for the assignment? How can they contact that person?
  7. Show Off the Work! – After a bounty is completed, show off the work! Make a post, on a blog or mailing list or wherever, to tell the story of how the person who took the bounty completed it and give a demo or show off their work. (This is a big part of the benefits too 🙂 ) This not only gives the new contributor a boost, it’s encouraging to other potential new contributors as they can see that new contributors are valued and can achieve cool things, and it’s also helpful in that it shows folks who haven’t set up bounties that maybe they should because it works!

I was thinking about setting this up as a pagure repo, and using the issues section for the actual bounty posting. The notion of status that applies to bugs / issues also applies to bounties, as well as assigning, etc. So maybe it would work well. Issues don’t explicitly manage the queue of bounty takers (should the 1st claimer fall through) but that could be managed through the comments. Any one from any Fedora team could post a bounty in this system. The git repo part of the pagure repo could be used for hosting some general bounty assets / resources – maybe a guide on how to write a good bounty with templates and cool graphics to include, maybe some basic instructions that would be useful for all bounty takers like how to create a new FAS account.

What about easy fix?

We do have a great resource, fedoraproject.org/easyfix, that is similar to this idea in that it uses issues/tickets in a manner geared towards new contributors. It provides a list of bugs that have been denoted as easy to fix by project owners all in one place.

The difference here though, is that these are raw bugs. They don’t have all the components of a bounty as explained above, and looking through some of the active and open ones, you could not get started right away without flagging down the right person and getting an explanation of how to proceed or going back and forth on the ticket. I think one of the things that makes bounties compelling is that you can read them and get started right away.

Bounties *do* take a long time to formulate and document. It is a very similar process to proposing a project for an internship program like Outreachy or Google Summer of Code. I bet, though, I could go around different teams in Fedora and find projects that would fit this scope quite well and start building out a list. Maybe as teams have direct success with a program like this, they’d continue to use it and it’d become self-sustaining. I don’t know, though. Clearly, I stopped doing the design team bounties after 4 or 5 because of the amount of work involved. 🙂 But maybe if it was a regular thing, we did one every month or something… not sure.

What do you think?

Does this idea make sense? Did I miss something (or totally miss the point)? Do you have a great idea to make it better? Let me know in the comments. 🙂

Title Design: from Wonder Woman to xXx

Joseph Conover is a 3D artist at Greenhaus GFX, where he created graphics for several high profile film credit sequences such as Wonder Woman, xXx: Return of Xander Cage, Guardians of the Galaxy Vol. 2 and more. As he stepped into the industry and picked up other creative tools, Joseph found that Blender often gave him an edge in terms of workflow.

Text by Joseph Conover, Greenhaus GFX

I started using Blender about ten years ago and still implement it in my workflow for modeling, simulation, texturing, sculpting, and various other general tasks. The software is so comprehensive that it lets me picture the final product from a wide viewpoint. It offers a big advantage in eliminating guesswork and time wasted when jumping between different programs.

The largest project I’ve worked on at Greenhaus so far is the Wonder Woman’s end title sequence.

I did too many random things to count, but these are screenshots of notable parts:

Patty Jenkins (Wonder Woman’s director) thought that many scenes in our sequence were too warlike and wanted some uplifting moments, so I 3D projected this view of Themyscira (home to Wonder Woman and the Amazons) based on a painted version created by my boss, Jason Doherty.

Here are several of my more notable models that were used in various scenes. The woman was based on actress Gal Gadot – sculpted in Zbrush and refined in Blender. For the plane, I took inspiration from the WWII German Biplane. My favorite thing to work on was the Sword structure, in which I used arrays and curve modifiers to create a rotating structure effect.

This was one of the environments I got to develop from start to finish. It was a mix of kitbashing and modeling in Blender. The whole process only took me an afternoon to finish because I was able to quickly duplicate the pieces and fill in the space. This scene was also repurposed in different shots throughout the sequence.

Guardians of the Galaxy Vol. 2’s logo was a different story, because it started off in Blender but ended in C4D. This was the logo our client liked at first, which was done in Blender with some 80’s style comping in After Effects:

While Guardians of the Galaxy Vol. 2’s final product didn’t use much of Blender other than the animation, this promotional ad for the 2017 NHL All-Star Weekend did.

This was a great example of Blender’s versatility. For the two shots below, I had to hand model the scenes to match the Cinerama Dome and the Hollywood Sign. Blender allowed me to quickly draft out my ideas from animation to the final lighting before I exported it to Maya and rendered in V-ray.

So what are your thoughts? Hit me up at josephconover.com if you want to chat about Blender or just talk art!

September 26, 2017

fwupd about to break API and ABI

Soon I’m going to merge a PR to fwupd that breaks API and ABI and bumps the soname. If you want to use the stable branch, please track 0_9_X. The API break removes all the deprecated API and cruft we’ve picked up in the months since we started the project, and with the upcoming 1.0.0 version coming up in a few weeks it seems a sensible time to have a clean out. If it helps, I’m going to put 0.9.x in Fedora 26 and F27, so master branch probably only for F28/rawhide and jhbuild at this point.

In other news, 4 days ago I became a father again, so expect emails to be delayed and full of confusion. All doing great, but it turns out sleep is for the weak. :)

September 25, 2017

Blender Daily Doodles

If you follow me on Instagram or Youtube, you’ve probably noticed all my spare time has been consumed by flying racing drones recently. Winter is approaching, so I’d rather spare my fingers from freezing and focus on my other passion, 3D doodling.

Modifier stack explorations Modifier stack explorations

This blog post is the equivalent of a new year’s resolution. I’ll probably be overwhelmed by duties and will drop out from this, but at least being public about it creates some pressure to keep trying. Feel free to help out with the motivation :)

Animation Nodes is amazing Animation Nodes is amazing

September 21, 2017

Krita 3.3.0 – first release candidate

Less than a month after Krita 3.2.1, we’re getting ready to release Krita 3.3.0. We’re bumping the version because there are some important changes for Windows users in this version!

Alvin Wong has implemented support for the Windows 8 event API, which means that Krita now supports the n-trig pen in the Surface line of laptops (and similar laptops from Dell, HP and Acer) natively. This is still very new, so you have to enable this in the tablet settings:

And he also refactored Krita’s hardware-accelerated display functionality to optionally use Angle on Windows instead of native OpenGL. That means that many problems with Intel display chips and broken driver versions are worked around because Krita now indirectly uses Direct3D.

There are more changes in this release, of course:

  • Some visual glitches when using hi-dpi screens are fixed (remember: on Windows and Linux, you need to enable this in the settings dialog).
  • If you create a new image from clipboard, the image will have a title
  • Favorite blending modes and favorite brush presets are now loaded correctly on startup
  • GMIC
    • the plugin has been updated to the latest version for Windows and Linux.
    • the configuration for setting the path to the plugin has been removed. Krita looks for the plugin in the folder where the krita executable is, and optionally inside a folder with a name that starts with ‘gmic’ next to the krita executable.
    • there are several fixes for handling layers and communication between Krita and the plugin
  • Some websites save jpeg images with a .png extension: that used to confuse Krita, but Krita now first looks inside the file to see what kind of file it really is.
  • PNG:
    • 16 and 32 bit floating point images are now converted to 16 bit integer when saving the images as PNG.
    • It’s now possible to save the alpha channel to PNG images even if there are no (semi-) transparent pixels in the image
  • When hardware accelerated display is disabled, the color picker mode of the brush tool showed a broken cursor; this has been fixed.
  • The Reference Images docker now only starts loading images when it is visible, instead on Krita startup. Note: the reference images docker uses Qt’s imageio plugins to load images. If you are running on Linux, remove all Deepin desktop components. Deepin comes with severely broken qimageio plugins that will crash any Qt application that tries to display images.
  • File layers now correctly reload on change again
  • Add several new commandline options:
    • –nosplash to start Krita without showing the splash screen
    • –canvasonly to start Krita in canvas-only mode
    • –fullscreen to start Krita full-screen
    • –workspace Workspace to start Krita with the given workspace
  • Selections
    • The Select All action now first clears the selection before selecting the entire image
    • It is now possible to extend selections outside the canvas boundary
  • Performance improvements: in several places superfluous reads from the settings were eliminated, which makes generating a layer thumbnail faster and improves painting if display acceleration is turned off.
  • The smart number input boxes now use the current locale to follow desktop settings for numbers
  • The system information dialog for bug reports is improved
  • macOS/OSX specific changes:
    • Bernhard Liebl has improved the tablet/stylus accuracy. The problem with circles having straight line segments is much improved, though it’s not perfect yet.
    • On macOS/OSX systems with and AMD gpu, support for hardware accelerated display is disabled because saving to PNG and JPG hangs Krita otherwise.

Download

Windows

Note for Windows users: if you encounter crashes, please follow these instructions to use the debug symbols so we can figure out where Krita crashes. There are no 32 bits packages at this point, but there will be for the final release.

Linux

(If, for some reason, Firefox thinks it needs to load this as text: to download, right-click on the link.)

When it is updated, you can also use the Krita Lime PPA to install Krita 3.3.0-rc.1 on Ubuntu and derivatives.

OSX

Note: the gmic-qt and pdf plugins are not available on OSX.

Source code

md5sums

For all downloads:

Key

The Linux appimage and the source tarball are signed. You can retrieve the public key over https here:
0x58b9596c722ea3bd.asc
. The signatures are here.

Support Krita

Krita is a free and open source project. Please consider supporting the project with donations or by buying training videos or the artbook! With your support, we can keep the core team working on Krita full-time.

September 20, 2017

Bluetooth on Fedora: joypads and (more) security

It's been a while since I posted about Fedora specific Bluetooth enhancements, and even longer that I posted about PlayStation controllers support.

Let's start with the nice feature.

Dual-Shock 3 and 4 support

We've had support for Dual-Shock 3 (aka Sixaxis, aka PlayStation 3 controllers) for a long while, but I've added a long-standing patchset to the Fedora packages that changes the way devices are setup.

The old way was: plug in your joypad via USB, disconnect it, and press the "P" button on the pad. At this point, and since GNOME 3.12, you would have needed the Bluetooth Settings panel opened for a question to pop up about whether the joypad can connect.

This is broken in a number of ways. If you were trying to just charge the joypad, then it would forget its original "console" and you would need to plug it in again. If you didn't have the Bluetooth panel opened when trying to use it wirelessly, then it just wouldn't have worked.

Set up is now simpler. Open the Bluetooth panel, plug in your device, and answer the question. You just want to charge it? Dismiss the query, or simply don't open the Bluetooth panel, it'll work dandily and won't overwrite the joypad's settings.


And finally, we also made sure that it works with PlayStation 4 controllers.



Note that the PlayStation 4 controller has a button combination that allows it to be visible and pairable, except that if the device trying to connect with it doesn't behave in a particular way (probably the same way the 25€ RRP USB adapter does), it just wouldn't work. And it didn't work for me on a number of different devices.

Cable pairing for the win!

And the boring stuff

Hey, do you know what happened last week? There was a security problem in a package that I glance at sideways sometimes! Yes. Again.

A good way to minimise the problems caused by problems like this one is to lock the program down. In much the same way that you'd want to restrict thumbnailers, or even end-user applications, we can forbid certain functionality from being available when launched via systemd.

We've finally done this in recent fprintd and iio-sensor-proxy upstream releases, as well as for bluez in Fedora Rawhide. If testing goes well, we will integrate this in Fedora 27.

September 18, 2017

Screen Brightness on an Asus 1015e (and other Intel-based laptops)

When I upgraded my Asus laptop to Stretch, one of the things that stopped working was the screen brightness keys (Fn-F5 and Fn-F6). In Debian Jessie they had always just automagically worked without my needing to do anything, so I'd never actually learned how to set brightness on this laptop. The fix, like so many things, is easy once you know where to look.

It turned out the relevant files are in /sys/class/backlight/intel_backlight. cat /sys/class/backlight/intel_backlight/brightness tells you the current brightness; write a number to /sys/class/backlight/intel_backlight/brightness to change it.

That at least got me going (ow my eyes, full brightness is migraine-inducing in low light) but of course I wanted it back on the handy function keys.

I wrote a script named "dimmer", with a symlink to "brighter", that goes like this:

#!/bin/zsh

curbright=$(cat /sys/class/backlight/intel_backlight/brightness)
echo dollar zero $0
if [[ $(basename $0) == 'brighter' ]]; then
  newbright=$((curbright + 200))
else
  newbright=$((curbright - 200))
fi
echo from $curbright to $newbright

sudo sh -c "echo $newbright > /sys/class/backlight/intel_backlight/brightness"

That let me type "dimmer" or "brighter" to the shell to change the brightness, with no need to remember that /sys/class/whatsit path. I got the names of the two function keys by running xev and typing Fn and F5, then Fn and F6. Then I edited my Openbox ~/.config/openbox/rc.xml, and added:

<keybind key="XF86MonBrightnessDown">
  <action name="Execute">
    <execute>dimmer<execute>
  </action>
</keybind>
<keybind key="XF86MonBrightnessUp">
  <action name="Execute">
    <execute>brighter<execute>
  </action>
</keybind>

September 16, 2017

David Revoy teaches Krita course at university in Paris

This past week artist David Revoy visited the Université Cergy-Pontoise in Paris France to give a Krita training. The university’s teacher, Nicolas Priniotakis, has been using linux and other open source technology such as Blender. This was the first time the students have been exposed to Krita…and the results were a success with the help of David!

You can read more about David’s trip and see what was taught during the class from his blog: https://www.davidrevoy.com/article335/krita-digital-painting-courses-at-university-cergy-pontoise

 

September 11, 2017

tl;dr: You need an application icon of at least 64×64 in size

At the moment the appstream-builder in Fedora requires a 48x48px application icon to be included in the AppStream metadata. I’m sure it’s no surprise that 48×48 padded to 64×64 and then interpolated up to 128×128 (for HiDPI screens) looks pretty bad. For Fedora 28 and higher I’m going to raise the minimum icon size to 64×64 which I hope people realize is actually a really low bar.

For Fedora 29 I think 128×128 would be a good minimum. From my point of view the best applications in the software center already ship large icons, and the applications with tiny icons are usually of poor quality, buggy, or just unmaintained upstream. I think it’s fine for a software center to do the equivalent of “you must be this high to ride” and if we didn’t keep asking more of upstreams we’d still be in a world with no translations, no release information and no screenshots.

Also note, applications don’t have to do this; it’s not like they’re going to fall out of the Fedora — they’re still installable on the CLI using DNF, although I agree this will impact the number of people installing and using a specific application. Comments welcome.

September 10, 2017

Urban sketchers meeting in São Paulo

4 days sketching through São Paulo with 250 people from whole Brazil and beyond...

September 09, 2017

WebDriver support in WebKitGTK+ 2.18

WebDriver is an automation API to control a web browser. It allows to create automated tests for web applications independently of the browser and platform. WebKitGTK+ 2.18, that will be released next week, includes an initial implementation of the WebDriver specification.

WebDriver in WebKitGTK+

There’s a new process (WebKitWebDriver) that works as the server, processing the clients requests to spawn and control the web browser. The WebKitGTK+ driver is not tied to any specific browser, it can be used with any WebKitGTK+ based browser, but it uses MiniBrowser as the default. The driver uses the same remote controlling protocol used by the remote inspector to communicate and control the web browser instance. The implementation is not complete yet, but it’s enough for what many users need.

The clients

The web application tests are the clients of the WebDriver server. The Selenium project provides APIs for different languages (Java, Python, Ruby, etc.) to write the tests. Python is the only language supported by WebKitGTK+ for now. It’s not yet upstream, but we hope it will be integrated soon. In the meantime you can use our fork in github. Let’s see an example to understand how it works and what we can do.

from selenium import webdriver

# Create a WebKitGTK driver instance. It spawns WebKitWebDriver 
# process automatically that will launch MiniBrowser.
wkgtk = webdriver.WebKitGTK()

# Let's load the WebKitGTK+ website.
wkgtk.get("https://www.webkitgtk.org")

# Find the GNOME link.
gnome = wkgtk.find_element_by_partial_link_text("GNOME")

# Click on the link. 
gnome.click()

# Find the search form. 
search = wkgtk.find_element_by_id("searchform")

# Find the first input element in the search form.
text_field = search.find_element_by_tag_name("input")

# Type epiphany in the search field and submit.
text_field.send_keys("epiphany")
text_field.submit()

# Let's count the links in the contents div to check we got results.
contents = wkgtk.find_element_by_class_name("content")
links = contents.find_elements_by_tag_name("a")
assert len(links) > 0

# Quit the driver. The session is closed so MiniBrowser 
# will be closed and then WebKitWebDriver process finishes.
wkgtk.quit()

Note that this is just an example to show how to write a test and what kind of things you can do, there are better ways to achieve the same results, and it depends on the current source of public websites, so it might not work in the future.

Web browsers / applications

As I said before, WebKitWebDriver process supports any WebKitGTK+ based browser, but that doesn’t mean all browsers can automatically be controlled by automation (that would be scary). WebKitGTK+ 2.18 also provides new API for applications to support automation.

  • First of all the application has to explicitly enable automation using webkit_web_context_set_automation_allowed(). It’s important to know that the WebKitGTK+ API doesn’t allow to enable automation in several WebKitWebContexts at the same time. The driver will spawn the application when a new session is requested, so the application should enable automation at startup. It’s recommended that applications add a new command line option to enable automation, and only enable it when provided.
  • After launching the application the driver will request the browser to create a new automation session. The signal “automation-started” will be emitted in the context to notify the application that a new session has been created. If automation is not allowed in the context, the session won’t be created and the signal won’t be emitted either.
  • A WebKitAutomationSession object is passed as parameter to the “automation-started” signal. This can be used to provide information about the application (name and version) to the driver that will match them with what the client requires accepting or rejecting the session request.
  • The WebKitAutomationSession will emit the signal “create-web-view” every time the driver needs to create a new web view. The application can then create a new window or tab containing the new web view that should be returned by the signal. This signal will always be emitted even if the browser has already an initial web view open, in that case it’s recommened to return the existing empty web view.
  • Web views are also automation aware, similar to ephemeral web views, web views that allow automation should be created with the constructor property “is-controlled-by-automation” enabled.

This is the new API that applications need to implement to support WebDriver, it’s designed to be as safe as possible, but there are many things that can’t be controlled by WebKitGTK+, so we have several recommendations for applications that want to support automation:

  • Add a way to enable automation in your application at startup, like a command line option, that is disabled by default. Never allow automation in a normal application instance.
  • Enabling automation is not the only thing the application should do, so add an automation mode to your application.
  • Add visual feedback when in automation mode, like changing the theme, the window title or whatever that makes clear that a window or instance of the application is controllable by automation.
  • Add a message to explain that the window is being controlled by automation and the user is not expected to use it.
  • Use ephemeral web views in automation mode.
  • Use a temporal user profile in application mode, do not allow automation to change the history, bookmarks, etc. of an existing user.
  • Do not load any homepage in automation mode, just keep an empty web view (about:blank) that can be used when a new web view is requested by automation.

The WebKitGTK client driver

Applications need to implement the new automation API to support WebDriver, but the WebKitWebDriver process doesn’t know how to launch the browsers. That information should be provided by the client using the WebKitGTKOptions object. The driver constructor can receive an instance of a WebKitGTKOptions object, with the browser information and other options. Let’s see how it works with an example to launch epiphany:

from selenium import webdriver
from selenium.webdriver import WebKitGTKOptions

options = WebKitGTKOptions()
options.browser_executable_path = "/usr/bin/epiphany"
options.add_browser_argument("--automation-mode")
epiphany = webdriver.WebKitGTK(browser_options=options)

Again, this is just an example, Epiphany doesn’t even support WebDriver yet. Browsers or applications could create their own drivers on top of the WebKitGTK one to make it more convenient to use.

from selenium import webdriver
epiphany = webdriver.Epiphany()

Plans

During the next release cycle, we plan to do the following tasks:

  • Complete the implementation: add support for all commands in the spec and complete the ones that are partially supported now.
  • Add support for running the WPT WebDriver tests in the WebKit bots.
  • Add a WebKitGTK driver implementation for other languages in Selenium.
  • Add support for automation in Epiphany.
  • Add WebDriver support to WPE/dyz.

September 05, 2017

security things in Linux v4.13

Previously: v4.12.

Here’s a short summary of some of interesting security things in Sunday’s v4.13 release of the Linux kernel:

security documentation ReSTification
The kernel has been switching to formatting documentation with ReST, and I noticed that none of the Documentation/security/ tree had been converted yet. I took the opportunity to take a few passes at formatting the existing documentation and, at Jon Corbet’s recommendation, split it up between end-user documentation (which is mainly how to use LSMs) and developer documentation (which is mainly how to use various internal APIs). A bunch of these docs need some updating, so maybe with the improved visibility, they’ll get some extra attention.

CONFIG_REFCOUNT_FULL
Since Peter Zijlstra implemented the refcount_t API in v4.11, Elena Reshetova (with Hans Liljestrand and David Windsor) has been systematically replacing atomic_t reference counters with refcount_t. As of v4.13, there are now close to 125 conversions with many more to come. However, there were concerns over the performance characteristics of the refcount_t implementation from the maintainers of the net, mm, and block subsystems. In order to assuage these concerns and help the conversion progress continue, I added an “unchecked” refcount_t implementation (identical to the earlier atomic_t implementation) as the default, with the fully checked implementation now available under CONFIG_REFCOUNT_FULL. The plan is that for v4.14 and beyond, the kernel can grow per-architecture implementations of refcount_t that have performance characteristics on par with atomic_t (as done in grsecurity’s PAX_REFCOUNT).

CONFIG_FORTIFY_SOURCE
Daniel Micay created a version of glibc’s FORTIFY_SOURCE compile-time and run-time protection for finding overflows in the common string (e.g. strcpy, strcmp) and memory (e.g. memcpy, memcmp) functions. The idea is that since the compiler already knows the size of many of the buffer arguments used by these functions, it can already build in checks for buffer overflows. When all the sizes are known at compile time, this can actually allow the compiler to fail the build instead of continuing with a proven overflow. When only some of the sizes are known (e.g. destination size is known at compile-time, but source size is only known at run-time) run-time checks are added to catch any cases where an overflow might happen. Adding this found several places where minor leaks were happening, and Daniel and I chased down fixes for them.

One interesting note about this protection is that is only examines the size of the whole object for its size (via __builtin_object_size(..., 0)). If you have a string within a structure, CONFIG_FORTIFY_SOURCE as currently implemented will make sure only that you can’t copy beyond the structure (but therefore, you can still overflow the string within the structure). The next step in enhancing this protection is to switch from 0 (above) to 1, which will use the closest surrounding subobject (e.g. the string). However, there are a lot of cases where the kernel intentionally copies across multiple structure fields, which means more fixes before this higher level can be enabled.

NULL-prefixed stack canary
Rik van Riel and Daniel Micay changed how the stack canary is defined on 64-bit systems to always make sure that the leading byte is zero. This provides a deterministic defense against overflowing string functions (e.g. strcpy), since they will either stop an overflowing read at the NULL byte, or be unable to write a NULL byte, thereby always triggering the canary check. This does reduce the entropy from 64 bits to 56 bits for overflow cases where NULL bytes can be written (e.g. memcpy), but the trade-off is worth it. (Besdies, x86_64’s canary was 32-bits until recently.)

IPC refactoring
Partially in support of allowing IPC structure layouts to be randomized by the randstruct plugin, Manfred Spraul and I reorganized the internal layout of how IPC is tracked in the kernel. The resulting allocations are smaller and much easier to deal with, even if I initially missed a few needed container_of() uses.

randstruct gcc plugin
I ported grsecurity’s clever randstruct gcc plugin to upstream. This plugin allows structure layouts to be randomized on a per-build basis, providing a probabilistic defense against attacks that need to know the location of sensitive structure fields in kernel memory (which is most attacks). By moving things around in this fashion, attackers need to perform much more work to determine the resulting layout before they can mount a reliable attack.

Unfortunately, due to the timing of the development cycle, only the “manual” mode of randstruct landed in upstream (i.e. marking structures with __randomize_layout). v4.14 will also have the automatic mode enabled, which randomizes all structures that contain only function pointers.

A large number of fixes to support randstruct have been landing from v4.10 through v4.13, most of which were already identified and fixed by grsecurity, but many were novel, either in newly added drivers, as whitelisted cross-structure casts, refactorings (like IPC noted above), or in a corner case on ARM found during upstream testing.

lower ELF_ET_DYN_BASE
One of the issues identified from the Stack Clash set of vulnerabilities was that it was possible to collide stack memory with the highest portion of a PIE program’s text memory since the default ELF_ET_DYN_BASE (the lowest possible random position of a PIE executable in memory) was already so high in the memory layout (specifically, 2/3rds of the way through the address space). Fixing this required teaching the ELF loader how to load interpreters as shared objects in the mmap region instead of as a PIE executable (to avoid potentially colliding with the binary it was loading). As a result, the PIE default could be moved down to ET_EXEC (0x400000) on 32-bit, entirely avoiding the subset of Stack Clash attacks. 64-bit could be moved to just above the 32-bit address space (0x100000000), leaving the entire 32-bit region open for VMs to do 32-bit addressing, but late in the cycle it was discovered that Address Sanitizer couldn’t handle it moving. With most of the Stack Clash risk only applicable to 32-bit, fixing 64-bit has been deferred until there is a way to teach Address Sanitizer how to load itself as a shared object instead of as a PIE binary.

early device randomness
I noticed that early device randomness wasn’t actually getting added to the kernel entropy pools, so I fixed that to improve the effectiveness of the latent_entropy gcc plugin.

That’s it for now; please let me know if I missed anything. As a side note, I was rather alarmed to discover that due to all my trivial ReSTification formatting, and tiny FORTIFY_SOURCE and randstruct fixes, I made it into the most active 4.13 developers list (by patch count) at LWN with 76 patches: a whopping 0.6% of the cycle’s patches. ;)

Anyway, the v4.14 merge window is open!

© 2017, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

September 04, 2017

Jumpstarting the Raspberry Pi Zero W: Now Available via Humble Bundle!

[Raspberry Pi Zero W] My new book is now shipping! And it's being launched via a terrific Humble Bundle of books on electronics, making, Raspberry Pi and Arduino.

Humble Bundles, if you haven't encountered them before, let you pay what you want for a bundle of books on related subjects. The books are available in ePub, Mobi, and PDF formats, without DRM, so you can read them on your choice of device. If you pay above a certain amount, they add additional books. My book is available if you pay $15 or more.

You can also designate some of the money you pay for charity. In this case the charity is Maker Ed, a crowdfunding initiative that supports Maker programs primarily targeted toward kids in schools. (I don't know any more about them than that; check out their website for more information.)

Jumpstarting the Raspberry Pi Zero W is a short book, with only 103 pages in four chapters:

  1. Getting Started: includes tips on headless setup and the Linux command line;
  2. Blink an LED: includes ways to blink and fade LEDs from the shell and from several different Python libraries;
  3. A Temperature Notifier and Fan Control: code and wiring instructions for three different temperature sensors (plus humidity and barometric pressure), and a way to use them to control your house fan or air conditioner, either according to the temperature in the room or through a Twitter command;
  4. A Wearable News Alert Light Show: wire up NeoPixels or DotStars and make them respond to keywords on Twitter or on any other web page you choose, plus some information on powering a Pi portably with batteries.

All the code and wiring diagrams from the book, plus a few extras, are available on Github, at my Raspberry Pi Zero Book code repository.

To see the book bundle, go to the Electronics & Programming Humble Bundle and check out the selections. My book, Jumpstarting the Raspberry Pi Zero W, is available if you pay $15 or more -- along with tons of other books you'll probably also want. I already have Make: Electronics and it's one of the best introductory electronics books I've seen, so I'm looking forward to seeing the followup volume. Plus there are books on atmospheric and environmental monitoring, a three-volume electronic components encyclopedia, books on wearable electronics and drones and other cool stuff.

I know this sounds like a commercial, but this bundle really does look like a great deal, whether or not you specifically want my Pi book, and it's a limited-time offer, only good for six more days.

Interview with Miri


Could you tell us something about yourself?

Hi there, I’m Miri. I’ve been drawing ever since I could pick up a pencil and switched to digital in the past 3 or so years, currently enrolled in college to grind out credits and hopefully become an animator.

Do you paint professionally, as a hobby artist, or both?

At this moment in time I’m just a hobbyist who does volunteer work for the Smite Community Magazine, but I’d love to be a professional someday.

What genre(s) do you work in?

Mainly fantasy and mythology gods and gaming fanart, I really love drawing characters.

Whose work inspires you most — who are your role models as an artist?

Oh man, I really love Araki Hirohiko’s figure style, the way he draws poses is just fascinating and what really kickstarted my interest in drawing people. Jaguddada on DeviantArt is absolutely hands down my favorite digital painter, the way he handles colors and how his digital paint strokes look like oil on canvas just fascinates me, I’d love to learn color theory and his painting skills one day. Baby steps!

How and when did you get to try digital painting for the first time?

I think it was in 2014 with Paint Tool Sai, I had interest in making fanart of some band I was into, it was rough and blocky and simple, but really fun.

What makes you choose digital over traditional painting?

The ability to just erase mistakes like they never even happened, and being able to redline things without it smudging, just having so many ways to fix mistakes like they weren’t even there to begin with, and the non-messy cleanup when you’re finished drawing. No pencils littered everywhere or shavings, no drying out markers to replace, etc.

How did you find out about Krita?

I made the switch to Linux in early 2016, finding out that Sai and CS6 wouldn’t be available unless I used WINE to emulate them, I just started looking for a free software that fit my taste. GIMP was okay, but it had a few quirks I couldn’t really iron out, and it was a bit simple for me. I think I found out about Krita through an art thread on some imageboard for taking requests, tried it out, it ran like a smoother SAI and I haven’t looked back.

What was your first impression?

I was like “Wow, this is a lot to take in and learn.” I’m still trying to figure out everything! There’s so many buttons I’m still unsure on what they do, I am just a simpleton!

What do you love about Krita?

I really love how it’s Linux friendly, and how it’s like a great replacement for Sai, like, I can actually make cool things in it without too much effort, and then there’s even levels further that I haven’t even explored yet that will probably even improve my stuff even more in the future. Also the opacity slider right above layers? Found that the first time I opened it, and it’s been my best friend ever since, took me a while on other programs to figure out what that bar did.

What do you think needs improvement in Krita? Is there anything that really annoys you?

There was one bug in the past when I used my left handed script that it would reset the pen size and opacity and brush type once you flipped it over from using the eraser, and it was my burden. Also the unexpected crashes. But the bug got fixed so I finally got to update my Krita again and that was a very good day. Also, not sure if it exists and I just haven’t found it yet, but Sai had a clipping tool that made it so you could clip layers to other layers so if you colored out of one of the layers it wouldn’t bleed to the rest of the drawing, that’s something I’ve googled but haven’t found the answer to yet, but it would
be a godsend to find.

What sets Krita apart from the other tools that you use?

Free Software and Linux compatible. Cannot stress it enough. Linux support is a dealmaker and the fact I don’t have to pay out of pocket for a program that works just as good if not even better than the paid ones is really awesome.

If you had to pick one favourite of all your work done in Krita so far, what would it be, and why?

Every new piece beomes my favorite for a certain time, until I start pointing out flaws in it, and then go back to an older piece. I’m really into my Ra + Thoth piece, though, just because of the details and shading coming out so nice, not to mention a background I was really pleased with.

What techniques and brushes did you use in it?

Oh god it’s been so long, I believe I used the paint settings marker brush with it’s slight opacity for shading, one of the square brushes under blending for lighting, and the pencil tool from Deevad’s set for outlining. I’m really obsessed with the paint set of default pens for the basics.

Where can people see more of your work?

Deviantart: Pluuck
Twitter: Hikkikomiri
(Or if you like MOBAs, check out the latest SMITE community gaming magazine!)

Anything else you’d like to share?

Honestly, never give up. Accept critique but don’t let it eat you away
to make you fear picking up a pen again. What may be something you find
a struggle, may be even harder for someone else. Be unique, be creative,
and always keep improving.

September 03, 2017

Do you have dmidecode 42?

Dear Lazyweb, I need your help. Does anyone have a newish server system (it’s not going to work on Laptops) that has any output from sudo dmidecode | grep "DMI type 42"? If you do, can you tar up the contents of /sys/firmware/dmi/tables and send it to me via email. If I can get this code working then I’ll have another more exciting blog post coming up. Thanks!

August 31, 2017

FreeCAD Arch development news - August 2017

Time for our monthly development report, explaining a bit of what I did this month. Thanks again to everybody who help me on Patreon, each month we're getting higher! If you don't know about it yet, you can help me to spend more time working on FreeCAD by href="https://www.patreon.com/yorikvanhavre">sponsoring me with any amount you want...

August 30, 2017

darktable for Windows

A long time ago there was a post about why we don't have a Windows port. While I still stand by what I wrote six years ago, the times they are a changing.

Then two years ago there was yet another post regarding Windows. The gist of it was that the real blocker for a Windows release isn't so much a technical one but the lack of a person (or several) dedicated to maintaining it. Not just for the moment until all the patches got merged but for the foreseeable future.

Then Peter Budai came along. Like some people before he managed to compile darktable on Windows and offered us the patches he had to do, but other than what we had seen before he stuck around, helped fix bugs and was open to suggestions how to solve things in a better way. Eventually we became confident that the lack of Windows maintainership might be solved.

To cut a long story short, we are extremely pleased – albeit wary – to announce a very first official pre-alpha development snapshot for 64 bit Windows. We know it's still buggy, but as a sign of goodwill and request for help in testing it we would like to ask you to give it a try. Please report useful bugs in our bug tracker.

You can find the link to the binary on the pixls.us forum (a great place btw., you should check it out).

GRUB and LUKS

I got myself stuck yesterday with GRUB running from an ext4 /boot/grub, but with /boot inside my LUKS LVM root partition, which meant GRUB couldn’t load the initramfs and kernel.

Luckily, it turns out that GRUB does know how to mount LUKS volumes (and LVM volumes), but all the instructions I could find talk about setting this up ahead of time (“Add GRUB_ENABLE_CRYPTODISK=y to /etc/default/grub“), rather than what the correct manual GRUB commands are to get things running on a failed boot.

These are my notes on that, in case I ever need to do this again, since there was one specific gotcha with using GRUB’s cryptomount command (noted below).

Available devices were the raw disk (hd0), the /boot/grub partition (hd0,msdos1), and the LUKS volume (hd0,msdos5):

grub> ls
(hd0) (hd0,msdos1) (hd0,msdos5)

Used cryptomount to open the LUKS volume (but without ()s! It says it works if you use parens, but then you can’t use the resulting (crypto0)):

grub> insmod luks
grub> cryptomount hd0,msdos5
Enter password...
Slot 0 opened.

Then you can load LVM and it’ll see inside the LUKS volume:

grub> insmod lvm
grub> ls
(crypto0) (hd0) (hd0,msdos1) (hd0,msdos5) (lvm/rootvg-rootlv)

And then I could boot normally:

grub> configfile $prefix/grub.cfg

After booting, I added GRUB_ENABLE_CRYPTODISK=y to /etc/default/grub and ran update-grub. I could boot normally after that, though I’d be prompted twice for the LUKS passphrase (once by GRUB, then again by the initramfs).

To avoid this, it’s possible to add a second LUKS passphrase, contained in a file in the initramfs, as described here and works for Ubuntu and Debian too. The quick summary is:

Create the keyfile and add it to LUKS:

# dd bs=512 count=4 if=/dev/urandom of=/crypto_keyfile.bin
# chmod 0400 /crypto_keyfile.bin
# cryptsetup luksAddKey /dev/sda5 /crypto_keyfile.bin
*enter original password*

Adjust the /etc/crypttab to include passing the file via /bin/cat:

sda5_crypt UUID=4aa5da72-8da6-11e7-8ac9-001cc008534d /crypto_keyfile.bin luks,keyscript=/bin/cat

Add an initramfs hook to copy the key file into the initramfs, keep non-root users from being able to read your initramfs, and trigger a rebuild:

# cat > /etc/initramfs-tools/hooks/crypto_keyfile <<EOF
#!/bin/bash
if [ "$1" = "prereqs" ] ; then
    cp /crypto_keyfile.bin "${DESTDIR}"
fi
EOF
# chmod a+x /etc/initramfs-tools/hooks/crypto_keyfile
# chmod 0700 /boot
# update-initramfs -u

This has the downside of leaving a LUKS passphrase “in the clear” while you’re booted, but if someone has root, they can just get your dm-crypt encryption key directly anyway:

# dmsetup table --showkeys sda5_crypt
0 155797496 crypt aes-cbc-essiv:sha256 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 0 8:5 2056

And of course if you’re worried about Evil Maid attacks, you’ll need a real static root of trust instead of doing full disk encryption passphrase prompting from an unverified /boot partition. :)

© 2017, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

August 28, 2017

GUADEC 2017 Manchester

Really enjoyed this year’s GUADEC. Thanks everyone for coming and the local team for pulling off a perfectly organized conference.

GUADEC 2017 Manchester from jimmac on Vimeo.

Check out a few photos too.

Total Eclipse

[2017 Solar eclipse with corona] My first total eclipse! The suspense had been building for years.

Dave and I were in Wyoming. We'd made a hotel reservation nine months ago, by which time we were already too late to book a room in the zone of totality and settled for Laramie, a few hours' drive from the centerline.

For visual observing, I had my little portable 80mm refractor. But photography was more complicated. I'd promised myself that for my first (and possibly only) total eclipse, I wasn't going to miss the experience because I was spending too much time fiddling with cameras. But I couldn't talk myself into not trying any photography at all.

Initially, my plan was to use my 90mm Mak as a 500mm camera lens. It had worked okay for the the 2012 Venus transit.

[Homemade solar finder for telescope] I spent several weeks before the eclipse in a flurry of creation, making a couple of solar finders, a barn-door mount, and then wrestling with motorizing the barn-door (which was a failure because I couldn't find a place to buy decent gears for the motor. I'm still working on that and will eventually write it up). I wrote up a plan: what equipment I would use when, a series of progressive exposures for totality, and so forth.

And then, a couple of days before we were due to leave, I figured I should test my rig -- and discovered that it was basically impossible to focus on the sun. For the Venus transit, the sun wasn't that high in the sky, so I focused through the viewfinder. But for the total eclipse, the sun would be almost overhead, and the viewfinder nearly impossible to see. So I had planned to point the Mak at a distant hillside, focus it, then slip the filter on and point it up to the sun. It turned out the focal point was completely different through the filter.

[Solar finder for DSLR, made from popsicle sticks] With only a couple of days left to go, I revised my plan. The Mak is difficult to focus under any circumstances. I decided not to use it, and to stick to my Canon 55-250mm zoom telephoto, with the camera on a normal tripod. I'd skip the partial eclipse (I've photographed those before anyway) and concentrate on getting a few shots of the diamond ring and the corona, running through a range of exposures without needing to look at the camera screen or do any refocusing. And since I wasn't going to be usinga telescope, my nifty solar finders wouldn't work; I designed a new one out of popsicle sticks to fit in the camera's hot shoe.

Getting there

We stayed with relatives in Colorado Saturday night, then drove to Laramie Sunday. I'd heard horror stories of hotels canceling people's longstanding eclipse reservations, but fortunately our hotel honored our reservation. WHEW! Monday morning, we left the hotel at 6am in case we hit terrible traffic. There was already plenty of traffic on the highway north to Casper, but we turned east hoping for fewer crowds. A roadsign sign said "NO PARKING ON HIGHWAY." They'd better not try to enforce that in the totality zone!

[Our eclipse viewing pullout on Wyoming 270] When we got to I-25 it was moving and, oddly enough, not particularly crowded. Glendo Reservoir had looked on the map like a nice spot on the centerline ... but it was also a state park, so there was a risk that everyone else would want to go there. Sure enough: although traffic was moving on I-25 at Wheatland, a few miles north the freeway came to a screeching halt. We backtracked and headed east toward Guernsey, where several highways went north toward the centerline.

East of Glendo, there were crowds at every highway pullout and rest stop. As we turned onto 270 and started north, I kept an eye on OsmAnd on my phone, where I'd loaded a GPX file of the eclipse path. When we were within a mile of the centerline, we stopped at a likely looking pullout. It was maybe 9 am. A cool wind was blowing -- very pleasant since we were expecting a hot day -- and we got acquainted with our fellow eclipse watchers as we waited for first contact.

Our pullout was also the beginning of a driveway to a farmhouse we could see in the distance. Periodically people pulled up, looking lost, checked maps or GPS, then headed down the road to the farm. Apparently the owners had advertised it as an eclipse spot -- pay $35, and you can see the eclipse and have access to a restroom too! But apparently the old farmhouse's plumbing failed early on, and some of the people who'd paid came out to the road to watch with us since we had better equipment set up.

[Terrible afocal view of partial eclipse] There's not much to say about the partial eclipse. We all traded views -- there were five or six scopes at our pullout, including a nice little H-alpha scope. I snapped an occasional photo through the 80mm with my pocket camera held to the eyepiece, or with the DSLR through an eyepiece projection adapter. Oddly, the DSLR photos came out worse than the pocket cam ones. I guess I should try and debug that at some point.

Shortly before totality, I set up the DSLR on the tripod, focused on a distant hillside and taped the focus with duct tape, plugged in the shutter remote, checked the settings in Manual mode, then set the camera to Program mode and AEB (auto exposure bracketing). I put the lens cap back on and pointed the camera toward the sun using the popsicle-stick solar finder. I also set a countdown timer, so I could press START when totality began and it would beep to warn me when it was time to the sun to come back out. It was getting chilly by then, with the sun down to a sliver, and we put on sweaters.

The pair of eclipse veterans at our pullout had told everybody to watch for the moon's shadow racing toward us across the hills from the west. But I didn't see the racing shadow, nor any shadow bands.

And then Venus and Mercury appeared and the sun went away.

Totality

[Solar eclipse diamond ring] One thing the photos don't prepare you for is the color of the sky. I expected it would look like twilight, maybe a little darker; but it was an eerie, beautiful medium slate blue. With that unworldly solar corona in the middle of it, and Venus gleaming as bright as you've ever seen it, and Mercury shining bright on the other side. There weren't many stars.

We didn't see birds doing anything unusual; as far as I can tell, there are no birds in this part of Wyoming. But the cows did all get in a line and start walking somewhere. Or so Dave tells me. I wasn't looking at the cows.

Amazingly, I remembered to start my timer and to pull off the DSLR's lens cap as I pushed the shutter button for the diamond-ring shots without taking my eyes off the spectacle high above. I turned the camera off and back on (to cancel AEB), switched to M mode, and snapped a photo while I scuttled over to the telescope, pulled the filter off and took a look at the corona in the wide-field eyepiece. So beautiful! Binoculars, telescope, naked eye -- I don't know which view was best.

I went through my exposure sequence on the camera, turning the dial a couple of clicks each time without looking at the settings, keeping my eyes on the sky or the telescope eyepiece. But at some point I happened to glance at the viewfinder -- and discovered that the sun was drifting out of the frame. Adjusting the tripod to get it back in the frame took longer than I wanted, but I got it there and got my eyes back on the sun as I snapped another photo ...

and my timer beeped.

I must have set it wrong! It couldn't possibly have been two and a half minutes. It had been 30, 45 seconds tops.

But I nudged the telescope away from the sun, and looked back up -- to another diamond ring. Totality really was ending and it was time to stop looking.

Getting Out

The trip back to Golden, where we were staying with a relative, was hellish. We packed up immediately after totality -- we figured we'd seen partials before, and maybe everybody else would stay. No such luck. By the time we got all the equipment packed there was already a steady stream of cars heading south on 270.

A few miles north of Guernsey the traffic came to a stop. This was to be the theme of the afternoon. Every small town in Wyoming has a stop sign or signal, and that caused backups for miles in both directions. We headed east, away from Denver, to take rural roads down through eastern Wyoming and Colorado rather than I-25, but even so, we hit small-town stop sign backups every five or ten miles.

We'd brought the Rav4 partly for this reason. I kept my eyes glued on OsmAnd and we took dirt roads when we could, skirting the paved highways -- but mostly there weren't any dirt roads going where we needed to go. It took about 7 hours to get back to Golden, about twice as long as it should have taken. And we should probably count ourselves lucky -- I've heard from other people who took 11 hours to get to Denver via other routes.

Lessons Learned

Dave is fond of the quote, "No battle plan survives contact with the enemy" (which turns out to be from Prussian military strategist Helmuth von Moltke the Elder).

The enemy, in this case, isn't the eclipse; it's time. Two and a half minutes sounds like a lot, but it goes by like nothing.

Even in my drastically scaled-down plan, I had intended exposures from 1/2000 to 2 seconds (at f/5.6 and ISO 400). In practice, I only made it to 1/320 because of fiddling with the tripod.

And that's okay. I'm thrilled with the photos I got, and definitely wouldn't have traded any eyeball time for more photos. I'm more annoyed that the tripod fiddling time made me miss a little bit of extra looking. My script actually worked out better than I expected, and I was very glad I'd done the preparation I had. The script was reasonable, the solar finders worked really well, and the lens was even in focus for the totality shots.

Then there's the eclipse itself.

I've read so many articles about solar eclipses as a mystical, religious experience. It wasn't, for me. It was just an eerily beautiful, other-worldly spectacle: that ring of cold fire staring down from the slate blue sky, bright planets but no stars, everything strange, like nothing I'd ever seen. Photos don't get across what it's like to be standing there under that weird thing in the sky.

I'm not going to drop everything to become a globe-trotting eclipse chaser ... but I sure hope I get to see another one some day.

Photos: 2017 August 21 Total Solar Eclipse in Wyoming.

August 26, 2017

Angle and Windows Ink – a new test version of Krita for Windows

We’ve created a special version of Krita 4.0 pre-alpha for Windows users to test. This version contains two big new features that should solve the biggest problems Krita has on the Windows platform:

  • Support for ANGLE. This is really technical, but basically, ANGLE is a technology that presents an OpenGL API but lets Direct3D do the work. On Windows, many OpenGL drivers are very buggy, and that could lead to crashes, black or blank screens. It’s the most-hated issue we have, and it is not even a bug in Krita! If you’re a Windows user and had to disable OpenGL in the Configure Krita dialog, then you should test this build!
  • Support for Windows Ink/Windows 8 Pointer Events. That’s to say, native support for the n-trig pen technology in Microsoft’s Surface line of products — also used by Asus, Dell and HP in their convertibles that can use a pen.

Note: that this is a build from our development branch. It has got all kinds of nifty, but highly unstable features, like scripting, saving in the background, svg graphics… If you load a Krita 3.x file with vector layers and save it with this version of Krita, you will NOT be able to open it in your regular, stable Krita. This build is purely experimental! Do NOT use it for real work. DO help us with testing!

Test Instructions for Angle

  • Open the survey in your browser: https://goo.gl/forms/vYxPMbqGyVhPCc2q2
  • Download the test build and debug symbols
  • Open the first zipfile in Windows Explorer, and drag the krita_4.0-prealpha_angle_ink-1-x64 folder to your desktop
  • Open the second zipfile in Windows Explorer and drag the bin, lib and share folders into the krita_4.0-prealpha_angle_ink-1-x64 folder on your desktop.
  • With Windows Explorer, navigate into the krita_4.0-prealpha_angle_ink-1-x64 folder on your desktop
  • Start Krita by double-clicking on the krita link or on the bin\krita.exe file
  • You will now be given a choice:
  • Please first choose Test Desktop OpenGL. Create a new image and try to draw for a bit. Fill in the results in the survey: whether you experienced a crash or not.
  • Next, restart Krita and choose Test ANGLE. Create a new image and draw for a bit. Fill in the results in the survey.

NOTE: You won’t be able to enable/disable OpenGL/Angle in Krita’s Settings/Configure Krita/Display settings dialog; it will be forced enabled for this test.

Test Instructions for Windows Ink/Windows Pointer API

This is only relevant for Windows 8 and 10: Windows 7 does not support this API (and Krita does not support Windows 95, 98, XP or Vista). You should be using a Surface Pro with a pen or another convertible that uses Microsoft’s n-trig pen technology. It does not matter whether you have the wintab driver installed.

  • Open the survey in your browser: https://goo.gl/forms/N5Exyx8aKSOeAUmu2
  • If you haven’t performed the previous test for Angle, download the test build and debug symbols
  • Open the first zipfile in Windows Explorer, and drag the krita_4.0-prealpha_angle_ink-1-x64 folder to your desktop
  • Open the second zipfile in Windows Explorer and drag the bin, lib and share folders into the krita_4.0-prealpha_angle_ink-1-x64 folder on your desktop.
  • With Windows Explorer, navigate into the krita_4.0-prealpha_angle_ink-1-x64 folder on your desktop
  • Start Krita by double-clicking on the krita link or on the bin\krita.exe file
  • Press either Test Desktop OpenGL or Test ANGLE when you see the dialog discussed above: this does not matter
  • Go to Settings/Configure Krita/Tablet and check the experimental pointer api/windows ink support checkbox:
  • Close Krita and start Krita again
  • Create a new document and draw with the default brush. Check whether pressure gives a variation in size and opacity. Note your findings in the survey: https://goo.gl/forms/5TSCWNZvvjN5SVoq1

Thanks!

Thanks for helping to test this important new features.

August 25, 2017

Announce: Entangle “Bottom“ release 0.7.2 – an app for tethered camera control & capture

I am pleased to announce a new release 0.7.2 of Entangle is available for download from the usual location:

  http://entangle-photo.org/download/

The this is mostly a bug fix release, but there was a little internal refactoring work to prepare for future support of timelapse / animation video display and possible webcam support.

  • Requires Gtk >= 3.10.0
  • Fix some introspection annotations
  • Use GdkSeat APIs if available
  • Use GtkOverlay and GtkRevealer in preference to custom widgets
  • Refactoring to prepare to support display of video files
  • Draw symbolic icons for video/image files while waiting for thumbnails to load
  • Ensure session highlight has a min 1 pixel visible border
  • Ensure session browser scrolls fully to right
  • Check for Adwaita icon theme which now includes symbolic icons
  • Remove left over check for DBus GLib
  • Remove use of deprecated GDK monitor functions
  • Remove use of deprecated GTK API for loading URIs
  • Fix handling of motion-notify event that broke client side window dragging
  • Fix warning when setting size of settings viewport
  • Update bug reporting address
  • Turn off over-zealous compiler warning about loop optimizations
  • Add ability to enter IP address of network camera
  • Fix URI pattern used to locate gphoto gvfs mounts
  • Add example plugin for bracketing photos of a total eclipse

Krita 3.2.1 Released

Krita 3.2.1 is a bug fix release. The following issues were fixed:

  • Crash on startup if only OpenGL 2.1 is found: if you had to disable opengl for 3.2.0, you can try to enable it again
  • A crash when changing layer types in the gmic-qt plugin
  • A bug where gmic-qt could crash on odd-sized images
  • A regression where using the text tool would break the brush tool
  • The option to use the native platform’s file dialogs was restored
  • A bug where selecting the line tool would disable the flow slider
  • Some issues with the LUT docker were fixed

Download

Windows

Note for Windows users: if you encounter crashes, please follow these instructions to use the debug symbols so we can figure out where Krita crashes.

Linux

(If, for some reason, Firefox thinks it needs to load this as text: to download, right-click on the link.)

When it is updated, you can also use the Krita Lime PPA to install Krita 3.2.1 on Ubuntu and derivatives.

OSX

Note: the gmic-qt and pdf plugins is not available on OSX.

Source code

md5sums

For all downloads:

Key

The Linux appimage and the source tarball are signed. You can retrieve the public key over https here:
0x58b9596c722ea3bd.asc
. The signatures are here.

Support Krita

Krita is a free and open source project. Please consider supporting the project with donations or by buying training videos or the artbook! With your support, we can keep the core team working on Krita full-time.

Google Summer of Code: Help Alexey Kapustin by Testing His Work!

The Google Summer of Code is nearly at an end. One of our students, Alexey Kapustin, has made a Windows build of his work. Alexey has created a version of Krita that helps us figure out how people actually use Krita by aggregating anonymous data on how often Krita is started, how long it’s used, which tools are used, which options and filters are most popular and so on.

Of course, this is still an experimental version: if it becomes part of the regular release it will be opt-in, not opt-out.  Within the KDE community we have created a policy for this kind of thing: https://community.kde.org/Policies/Telemetry_Policy .

If you want to help Alexey and are a Windows user, please download his special version of Krita 4.0 pre-alpha and play with it. There’s still a lot of work to do, of course, but first we need testers!

https://files.kde.org/krita/4/windows/krita-4.0.0-prealpha-telemetry2.zip

August 24, 2017

Krita’s Updated Vision

In 2010, during a developer sprint in Deventer, the Krita team sat down together with Peter Sikking to hammer out a vision statement for the project. Our old goal, be KDE’s Gimp/Photoshop, didn’t reflect what we really wanted to do. Here are some documents describing the creation of Krita’s vision:

Creating the vision took a lot of good, hard work, and this was the result (you need to read this as three paragraphs, givings answers to “what is it”, “for whom is it” and “what’s the value”):

Krita is a KDE program for sketching and painting, offering an end–to–end solution for creating digital painting files from scratch by masters.

Fields of painting that Krita explicitly supports are concept art, creation of comics and textures for rendering.

Modeled on existing real-world painting materials and workflows, Krita supports creative working by getting out of the way and with a snappy response.

Seven years later, this needed updating. We’ve added new fields that Krita supports, such as animation, and real-world painting materials and workflows — that never really materialized because as soon as we sat down with real-world artists, we learned that they couldn’t care less: they cared about being productive. So, after discussion on the mailing list and during our weekly meetings, we modified the vision document:

Krita is a free and open source cross-platform application that offers an end-to-end solution for creating digital art files from scratch. Krita is optimized for frequent, prolonged and focused use.

Explicitly supported fields of painting are illustrations, concept art, matte painting, textures, comics and animations.

Developed together with users, Krita is an application that supports their actual needs and workflow. Krita supports open standards and interoperates with other applications.

Let’s go through the changes.

We now mention “free and open source” instead of KDE because with expansion of Krita on Windows and OSX, we now have many users who do not know that KDE stands for Free Software that respects your privacy and the way you want to work. We considered “Free Software” instead, but this is really a moment where we need to make clear that “free software” is not “software for free”.

We still mention “files” explicitly; we’ve never really been interested in what you do with those files, but, for instance, printing from Krita just doesn’t have any priority for us. Krita is for creating your artwork, not for publishing it.

We replaced the “for masters” with “frequent, prolonged and focused use”. The meaning is the same: to get the most out of Krita you have to really use it. Krita is not for casually adding scribbles to a screenshot. But the “for masters” often made people wonder whether Krita could be used by beginning artists. The answer is of course “yes” — but you’ll have to master an application with thousands of possibilities.

In the second paragraph, we’ve added animations and matte painting. Animation was introduced for the third time in 2016; it’s clearly something a lot of people love to do. Matte painting gets close to photo manipulation, which isn’t in our vision, but focused on creating a new artwork. We’ve always felt that Krita could be used for that, as well. Note: no 3d, no webpage design, no product design, no wedding albums, no poster or other print design.

Finally, the last paragraph got almost completely rewritten. Gone is real-world materials as an inspiration, and in are our users as inspiration: we won’t let you dictate what Krita can do, or how Krita lets you do stuff, UX design isn’t something that can be created by voting. But we do listen, and for the past years we’ve let you vote for which features you would find most useful, while still keeping the direction of Krita as a whole in our hands. But we want to create an application that lets you get stuff done. We removed the “snappy” response, since that’s pretty much a given. We’re not going to try to create an application that’s ponderous or works against you all the way. Finally, we do care about interoperability and standards, and have spent countless hours of work on improving that, so we felt it needed to be said.

August 23, 2017

GIMP 2.9.6 Released

After more than a year of hard work we are excited to release GIMP 2.9.6 featuring many improvements, some new features, translation updates for 23 languages, and 204 bug fixes.

As usual, for a complete list of changes please see NEWS. Here we’d like to focus on the most important changes.

Performance

GIMP now has support for experimental multi-threading in GEGL and will try to use as many cores as are available on your computer.

We know GIMP can explode when using more than one core, but we keep it that way so that we get as many bug reports as possible for this officially unstable development version. This is because we really, really want to ship GIMP 2.10 with usable parallel processing.

On the other hand, you can always set the amount of cores to 1 if you couldn’t be bothered to report bugs. For that, please tweak the amount of threads on the System Resources page of the Preferences dialog.

Setting amount of threads in GIMP 2.9.6

GUI, Usability, and Configurability

Benoit Touchette improved mask creation workflow for users who use a ton of masks in their projects. Now GIMP remembers the last type of mask initialization, and you can use key modifiers + mouse click on layer previews to create, apply, or remove masks. There’s a new button in the Layers dockable dialog for that as well.

Easily create new mask with GIMP 2.9.6

To make that feature possible, Michael Natterer introduced saving of last dialogs’ settings across sessions and made these defaults configurable via the new Interface / Dialog Defaults page in the Preferences dialog.

Configurable Dialog Defaults in GIMP 2.9.6

Additionally, the Preferences dialog got a vertical scrollbar where applicable to keep its height more sensible, and settings on individual pages of the dialog can be reset separately now.

The Quit dialog got a few updates: automatically exiting when all the images in the list have been saved, and a Save As button for every opened image (clicking an image in the list will raise it easy checks).

Configurable Fill With option in GIMP 2.9.6

Yet another new feature is an option (on the screenshot above) to choose fill color or pattern for empty spaces after resizing the canvas.

Better Hi-DPI Support

While most changes for better Hi-DPI displays support are planned for v3.0, when GIMP is expected to be based on either GTK+3 or GTK+4, we were able to remove at least some of the friction by introducing icon sizes at different resolutions and a switch for icon sizes on the Icon Theme page of the Preferences dialog.

Configurable icon size in GIMP 2.9.6

On-canvas Interaction Changes

Michael Natterer did a huge under-the-hood work that is likely to affect user interaction with GIMP bigly. Simply put, he moved a lot of on-canvas code from tools like Rectangle Select, Measure and Path into reusable code.

The effect of that is multifold:

  • New tools can reuse on-canvas elements of other tools (adding shape drawing tools should be easier now, although we are not planning that for 2.10, unless someone sends a clean patch).
  • GEGL-based filters can be interacted with directly on the canvas (Spiral and Supernova so far as test case).

So far one still needs to write C code to make a GEGL-based filter use on-canvas interaction. We expect to spend some time figuring out a way to simplify this, possibly using the GUM language (see below).

Layers, Linear and Perceptual Workflows

Since we want to make workflows in linear color spaces more prominent in GIMP, it was time to update the blend modes code. You can now switch between two sets of layer modes: legacy (perceptual) and default (linear). The user interface for switching was a quick design, we’d like to come up with something better, so we are interested in your input.

Moreover, we made both compositing of layers and blending color space configurable, should you have the need to use that for advanced image manipulation.

We also added a new Colors -> Linear Invert command to provide radiometrically correct color inversion. And the histogram dialog now features a toggle between gamma and linear modes—again, it’s a design we’d like to improve.

Thanks to Øyvind Kolås and his Patreon supporters, GIMP now also has a simple ‘blendfun’ framework that greatly simplifies implementing new color modes. Ell made use of that by adding Linear Burn, Vivid Light, Linear Light, Pin Light, Hard Mix, Exclusion, Merge, Split, and Luminance (RGB) blending modes (most of them now also supported in the PSD plug-in).

Another prominent change is the introduction of the Pass Through mode for layer groups. When this mode is used instead of any other one, GIMP mixes layers inside that group directly to the layers below, skipping creation of the group projection. The feature was implemented by Ell. The screenshot below features a user-submitted PSD file that has TEXTURES layer group in the Pass Through mode, as opened in GIMP 2.9.4 (left) and GIMP 2.9.6 (right).

Pass Through mode vs no Pass Through mode

Newly added color tags simplify managing large projects with a lot of layers and layer groups. The screenshot below is a real-life PSD file opened in GIMP 2.9.6.

New User Interface Themes

To make more use of that feature, we need someone to step up and implement multiple layers selection. For an initial research, see this wiki page.

For full access to all the new features, we updated the Layer Attributes dialog to provide the single UI for setting layer’s name, blending mode, opacity, and offset, toggling visibility, link status, various locks, color tags.

Updated Layer Attributes dialog

CIE LCH and CIE LAB

Under the influence of Elle Stone (and with her code contributions), CIE LCH and CIE LAB color spaces are finding more use in GIMP now.

Color dialogs now have an LCH color selector that, in due time, will most likely replace outdated HSV selector for reasons outlined by Elle in this article. The LCH selector also supports gamut checking.

A new Hue-Chroma filter in the Colors menu works much like Hue-Saturation, but operates in CIE LCH color space. Moreover, the Fuzzy Select and the Bucket Fill tool now can select colors by CIE L, C, and H.

Finally, both the Color Picker and the Sample Points dialog now display pixel values in CIE LAB and CIE LCH.

Sample points in LCH and LAB, GIMP 2.9.6

Tools

New Handle Transform tool contributed by Johannes Matschke in 2015 has been finally cleaned up by Michael Natterer and available by default. It’s a little tricky to get used to, but we hear reports that once you get the hang of it, you love it.

Thanks to Ell, the Warp Transform tool is now a lot faster, partially thanks to a switch that toggles high-quality preview that isn’t always necessary.

All transformation tools don’t display grid by default anymore, and during an interactive transformation the original layer gets hidden now. The latter greatly simplifies transforming upper layer in relation to a lower layer. Before that, the original layer used to block the view.

Free Select tool now waits for Enter being pressed to confirm selection, which enables you to tweak positions of polygonal selection.

Painting

An important new feature that is somewhat easy to overlook is being able to paint on transparent layers with modes other than normal.

Thanks to shark0r, the Smudge tool now has a Flow control that allows mixing in both constant and gradient color while smudging. There’s another new option to never decrease alpha of existing pixels while smudging in the tools options now as well. For more on this, please read this forum thread.

Canvas rotation has been improved: it got snappier in certain cases, and rulers, scrollbars, as well as the Navigation dialog follow the rotation now.

Alexia introduced some improvements to the brush engine. For bitmap brushes, GIMP now caches hardness and disables dynamic change of hardness to improve painting performance. Bitmap brushes also don’t get clipped anymore, when hardness is less than 100. Plus there’s a specialized convolution algorithm for the hardness blur to make it faster now.

Processing Raw Images

Since 2.9.4, GIMP is capable of opening raw (digital camera) images via darktable, and the plan was to open it up to more plug-in developers, because nothing sparks a thoughtful, civil conversation like a raw processor of choice.

This is now possible: 2.9.6 ships with a RawTherapee plug-in (v5.2 or newer should be installed) and a new file-raw-placeholder plug-in that registers itself for loading all raw formats, but does nothing except returning an error message pointing to darktable and RawTherapee, if neither is installed.

Moreover, you can now choose preferred raw plug-in, when multiple options are available on your computer. For this, open the Preferences dialog and go to the Image Import page, then click on the plug-in you prefer and click OK to confirm your choice. You will need to restart GIMP.

Better PSD Support

The PSD plug-in now supports a wider range of blending modes for layers, at both importing and exporting: Linear Burn, Linear Light, Vivid Light, Pin Light, and Hard Mix blending modes. It also finally supports exporting layer groups and reads/writes the Pass Through mode in those. Additionally, GIMP now imports and exports color tags from/to PSD files.

WebP support

We already shipped GIMP 2.9.2 with initial support for opening and exporting WebP files, however the plug-in was missing a number of essential features. Last year, we replaced it with a pre-existing plug-in initially written by Nathan Osman back in 2011 and maintained through the years. We now ship it by default as part of GIMP.

WebP exporting in GIMP 2.9.6

The new plug-in received additional contributions from Benoit Touchette and Pascal Massimino and supports both ICC profiles, metadata loading/exporting, and animation.

Metadata Viewing and Editing

Thanks to Benoit Touchette, GIMP now ships a new metadata viewer that uses Exiv2 to display Exif, XMP, IPTC, and DICOM metadata (the latter is displayed on the XMP tab).

Metadata viewer in GIMP 2.9.6

Moreover, Benoit implemented a much anticipated metadata editor that supports adding/editing writing XMP, IPTC, DICOM, and GPS/Exif metadata, as well as loading/exporting metadata from/to XMP files.

Metadata editor in GIMP 2.9.6

Filters

Thanks to contributions from Thomas Manni and Ell, GIMP now has 9 more GEGL-based filters, including much anticipated Wavelet Decompose, as well as an Extract Component plug-in that simplifies fetching e.g. CMYK’s K channel or LAB’s L* channel from an image.

Another new feature that we expect to develop further is GUM—a simple metadata language that helps automatically building more sensible UI for GEGL filters. Here’s a quick video:

Resources and Presets

To make GIMP more useful by default, we now ship it with some basic presets for the Crop tool: 2×3, 3×4, 16:10, 16:9, and Square.

Documents templates have been updated and now feature popular, contemporary presets for both print and digital media.

What’s Next

We still have a bunch of bugs to fix before we can release 2.10 and we appreciate all the huge and tiny useful patches contributors send us to that effect.

GIMP 2.9.8 is expected to ship with more bug fixes and an updated Blend (Gradient Fill) tool that works completely on canvas, including adding and removing color stops and assigning colors.

August 21, 2017

Parametric IFC files

The title of this article sucks, I know, couldn't think of anything better... This is a concept I wanted to play with since a long time, and last month I was finally able to setup a proof of concept. The only missing part was to write an article explaining it, so here it goes. For who is...

August 18, 2017

Shipping PKCS7 signed metadata and firmware

Over the last few days I’ve merged in the PKCS7 support into fwupd as an optional feature. I’ve done this for a few reasons:

  • Some distributors of fwupd were disabling the GPG code as it’s GPLv3, and I didn’t feel comfortable saying just use no signatures
  • Trusted vendors want to ship testing versions of firmware directly to users without first uploading to the LVFS.
  • Some firmware is inherently internal use only and needs to be signed using existing cryptographic hardware.
  • The gpgme code scares me.

Did you know GPGME is a library based around screen scraping the output of the gpg2 binary? When you perform an action using the libgpgme APIs you’re literally injecting a string into a pipe and waiting for it to return. You can’t even use libgcrypt (the thing that gpg2 uses) directly as it’s way too low level and doesn’t have any sane abstractions or helpers to read or write packaged data. I don’t want to learn LISP S-Expressions (yes, really) and manually deal with packing data just to do vanilla X509 crypto.

Although the LVFS instance only signs files and metadata with GPG at the moment I’ve added the missing bits into python-gnutls so it could become possible in the future. If this is accepted then I think it would be fine to support both GPG and PKCS7 on the server.

One of the temptations for X509 signing would be to get a certificate from an existing CA and then sign the firmware with that. From my point of view that would be bad, as any firmware signed by any certificate in my system trust store to be marked as valid, when really all I want to do is check for a specific (or a few) certificates that I know are going to be providing certified working firmware. Although I could achieve this to some degree with certificate pinning, it’s not so easy if there is a hierarchical trust relationship or anything more complicated than a simple 1:1 relationship.

So this is possible I’ve created a LVFS CA certificate, and also a server certificate for the specific instance I’m running on OpenShift. I’ve signed the instance certificate with the CA certificate and am creating detached signatures with an embedded (signed-by-the-CA) server certificate. This seems to work well, and means we can issue other certificates (or CRLs) if the server ever moves or the trust is compromised in some way.

So, tl;dr: (should have been at the top of this page…) if you see a /etc/pki/fwupd/LVFS-CA.pem appear on your system in the next release you can relax. Comments, especially from crypto experts welcome. Thanks!

August 17, 2017

Krita 3.2.0 Released

Later than planned, here’s Krita 3.2.0! With the new G’Mic-qt plugin integration, the smart patch tool, finger painting on touch screens, new brush presets and a lot of bug fixes.

Read the full release notes for more information!. Here’s GDQuest’s video introducing 3.2.0:

Note: the gmic-qt plugin is not available on OSX. Krita now ships with a pre-built gmic-qt plugin on Windows and the Linux AppImage. If you have tested the beta or release candidate builds, you might need to reset your configuration.

Changes since the last release candidate:

  • Don’t reset the LUT docker when moving the Krita window between moitors
  • Correctly initialize the exposure display filter in the LUT docker
  • Add the missing pan tool a ction
  • Improve the “Normal” blending mode performance by 30% (first patch for Krita by Daria Scherbatyuk!)
  • Fix a crash when creating a second view on an image
  • Fix a possible crash when creating a second window
  • Improve finding the gmic-qt plugin: Krita now first looks whether there is one available in the same place as the Krita executable
  • Fix scroll wheel behaviour if Krita is built with Qt 5.7.1. or later
  • Fix panning in gmic-qt when applying gmic-qt to a non-RGBA image
  • Scale channel values correctly when using a non-RGBA image with gmic-qt
  • Fix the default setting for allowing multiple krita instances

    Download

    Windows

    Note for Windows users: if you encounter crashes, please follow these instructions to use the debug symbols so we can figure out where Krita crashes.

    Linux

    (If, for some reason, Firefox thinks it needs to load this as text: to download, right-click on the link.)

    When it is updated, you can also use the Krita Lime PPA to install Krita 3.2.0 on Ubuntu and derivatives.

    OSX

    Note: the gmic-qt and pdf plugins is not available on OSX.

    Source code

    md5sums

    For all downloads:

    Key

    The Linux appimage and the source tarball are signed. You can retrieve the public key over https here:
    0x58b9596c722ea3bd.asc
    . The signatures are here.

    Support Krita

    Krita is a free and open source project. Please consider supporting the project with donations or by buying training videos or the artbook! With your support, we can keep the core team working on Krita full-time.

August 16, 2017

Thank you all!

When we went public with our troubles with the Dutch tax office two weeks ago, the response was overwhelming. The little progress bar on krita.org is still counting, and we’re currently at 37,085 euros, and 857 donators. And that excludes the people who sent money to the bank directly. It does include Private Internet Access‘ sponsorship. Thanks to all you! So many people have supported us, we cannot even manage to send out enough postcards.

So, even though we’re going to get another accountant’s bill of about 4500 euros, we’ve still got quite a surplus! As of this moment, we have €29,657.44 in our savings account!

That means that we don’t need to do a fund raiser in September. Like we said, we’ve still got some features to finish. Dmitry and I are currently working on

  • Make Krita save and autosave in the background (done)
  • Improved animation rendering speed (done)
  • Improve Krita’s brush engine multi-core adaptability (under way)
  • Improve the general concurrency in Krita (under way)
  • Add touch functionality back (under way)
  • Implement the new text tool (under way)
  • Lazy brush: plug in a faster algorithm
  • Stacked brushes: was done, but needs to be redone
  • Replace the reference images docker with a reference images tool (under way)
  • Add patterns and filters to the vector support

All of that should be done before the end of the year. After that, we want to spend 2018 working on stability, polish and performance. So much will have changed that from 3.0 to 4.0 is a bigger step than from 2.9 to 3.0, even though that included the port to a new version of Qt! We will be doing new fund raisers in 2018, but we’re still discussing what the best approach would be. Kickstarters with stretch goals are very much feature oriented, and we’ve all decided that it’s time to improve what we have, instead of adding still more features, at least, for a while…

In the meantime, we’re working on the 3.2 release. We wanted to have it released yesterday, but we found a regression, which Dmitry is working hard on fixing right now. So it’ll probably be tomorrow.

August 14, 2017

A Homemade Solar Finder, for the Eclipse

While I was testing various attempts at motorizing my barn-door mount, trying to get it to track the sun, I had to repeatedly find the sun in my telescope.

In the past, I've generally used the shadow of the telescope combined with the shadow of the finderscope. That works, more or less, but it's not ideal: it doesn't work as well with just a telescope with no finder, which includes both of the scopes I'm planning to take to the eclipse; and it requires fairly level ground under the telescope: it doesn't work if there are bushes or benches in the way of the shadow.

For the eclipse, I don't want to waste any time finding the sun: I want everything as efficient as possible. I decided to make a little solar finderscope. One complication, though: since I don't do solar observing very often, I didn't want to use tape, glue or, worse, drill holes to mount it.

So I wanted something that could be pressed against the telescope and held there with straps or rubber bands, coming off again without leaving a mark. A length of an angled metal from my scrap pile seemed like a good size to be able to align itself against a small telescope tube.

[Constructing a solar sight] Then I needed front and rear sights. For the front sight, I wanted a little circle that could project a bulls-eye shadow onto a paper card attached to the rear sight. I looked at the hardware store for small eye-bolts, but no dice. Apparently they don't come that small.I settled for the second-smallest size of screw eye.

The screw eye, alas, is meant to screw into wood, not metal. So I cut a short strip of wood a reasonable size to nestle into the inside of the angle-iron. (That ripsaw Dave bought last year sure does come in handy sometimes.) I drilled some appropriately sized holes and fastened screw eyes on both ends, adding a couple of rubber grommets as spacers because the screw eyes were a little too long and I didn't want the pointy ends of the screws getting near my telescope tube.

I added some masking tape on the sides of the angle iron so it wouldn't rub off the paint on the telescope tube, then bolted a piece of cardboard cut from an old business card to the rear screw eye.

[Homemade solar sight] Voila! A rubber-band-attached solar sight that took about an hour to make. Notice how the shadow of the front sight exactly fits around the rear sight: you line up the shadow with the rear sight to point the scope. It seems to work pretty well, and it should be adaptable to any telescope I use.

I used a wing nut to attach the rear cardboard: that makes it easy to replace it or remove it. With the cardboard removed, the sight might even work for night-time astronomy viewing. That is, it does work, as long as there's enough ambient light to see the rings. Hmm... maybe I should paint the rings with glow-in-the-dark paint.

August 11, 2017

A Barn-Door Mount for the Eclipse

[Curved rod barn-door mount] I've been meaning forever to try making a "barn door" tracking mount. Used mainly for long-exposure wide-field astrophotography, the barn door mount, invented in 1975, is basically two pieces of wood with a hinge. The bottom board mounts on a tripod and is pointed toward the North Star; "opening" the hinge causes the top board to follow the motion of the sky, like an equatorial telescope mount. A threaded rod and a nut control the angle of the "door", and you turn the nut manually every so often. Of course, you can also drive it with a motor.

We're off to view the eclipse in a couple of weeks. Since it's my first total eclipse, my plan is to de-emphasize photography: especially during totality, I want to experience the eclipse, not miss it because my eyes are glued to cameras and timers and other equipment. But I still want to take photos every so often. Constantly adjusting a tripod to keep the sun in frame is another hassle that might keep my attention away from the eclipse. But real equatorial mounts are heavy and a time consuming to set up; since I don't know how crowded the area will be, I wasn't planning to take one. Maybe a barn door would solve that problem.

Perhaps more useful, it would mean that my sun photos would all be rotated approximately the right amount, in case I wanted to make an animation. I've taken photos of lunar and partial solar eclipses, but stringing them together into an animation turned out to be too much hassle because of the need to rotate and position each image.

I've known about barn-door mounts since I was a kid, and I knew the basic theory, but I'd never paid much attention to the details. When I searched the web, it sounded complicated -- it turned out there are many types that require completely different construction techniques.

The best place to start (I found out after wasting a lot of time on other sites) is the Wikipedia article on "Barn door tracker", which gives a wonderfully clear overview, with photos, of the various types. I had originally been planning a simple tangent or isosceles type; but when I read construction articles, it seemed that those seemingly simple types might not be so simple to build: the angle between the threaded rod and the boards is always changing, so you need some kind of a pivot. Designing the pivot looked tricky. Meanwhile, the pages I found on curved-rod mounts all insisted that bending the rod was easy, no trouble at all. I decided to try a curved-rod mount first.

The canonical reference is a 2015 article by Gary Seronik: A Tracking Platform for Astrophotography. But I found three other good construction guides: Optical Ed's "Making a Curve Bolt Barn Door", a Cloudy Nights discussion thread "Motorized Barn Door Mount Kit", and Massapoag Pond Photography's "Barn Door Tracker". I'm not going to reprise all their construction details, so refer to those sites if you try making your own mount.

[Barn-door mount, showing piano hinge] The crucial parts are a "piano hinge", a long hinge that eliminates the need to line up two or more hinges, and the threaded rod. Buying a piano hinge in the right size proved impossible locally, but the folks at Metzger's assured me that piano hinges can be cut, so I bought one longer than I needed and cut it to size. I used a 1/4-20 rod, which meant (per the discussions in the Cloudy Nights discussion linked above) that a 11.43-inch radius from the hinge to the holes the rod passes through would call for the nut to turn at a nice round number of 1 RPM.

I was suspicious of the whole "it's easy to bend the threaded rod ina 11.43-inch circle" theory, but it turned out to be true. Draw the circle you want on a sheet of newspaper, put on some heavy gloves and start bending, frequently comparing your rod to the circle you drew. You can fine-tune the curvature later.

I cut my boards, attached the hinge, measured about 11.4" and drilled a hole for the threaded rod. The hole needed to be a bit bigger than 5/8" to let the curved rod pass through without rubbing. Attach the curved rod to the top wood piece with a couple of nuts and some washers, and then you can fine-tune the rod's curvature, opening and closing the hinge and re-bending the rod a little in any place it rubs.

A 5/8" captive nut on the top piece lets you attach a tripod head which will hold your camera or telescope. A 1/4" captive nut on the bottom piece serves to attach the mount to a tripod -- you need a 1/4", not 3/8": the rig needs to mount on a tripod head, not just the legs, so you can align the hinge to the North Star. (Of course, you could build a wedge or your own set of legs, if you prefer.) The 3/4" plywood I was using turned out to be thicker than the captive nuts, so I had to sand the wood thinner in both places. Maybe using half-inch plywood would have been better.

[Wing nut on barn-door mount] The final piece is the knob/nut you'll turn to make the mount track. I couldn't find a good 1/4" knob for under $15. A lot of people make a wood circle and mount the nut in the center, or use a gear so a motor can drive the mount. I looked around at things like jam-jar lids and the pile of metal gears and sprinkler handles in my welding junkpile, but I didn't see anything that looked quite right, so I decided to try a wing nut just for testing, and worry about the knob later. Turns out a wing nut works wonderfully; there's no particular need for anything else if you're driving your barn-door manually.

Testing time! I can't see Polaris from my deck, and I was too lazy to set up anywhere else, so I used a protractor to set the hinge angle to roughly 36° (my latitude), then pointed it approximately north. I screwed my Pro-Optic 90mm Maksutov (the scope I plan to use for my eclipse photos) onto the ball head and pointed it at the moon as soon as it rose. With a low power eyepiece (20x), turning the wing nut kept the moon more or less centered in the field for the next half-hour, until clouds covered the moon and rain began threatening. I didn't keep track of how many turns I was making, since I knew the weather wasn't going to allow a long session, and right now I'm not targeting long-exposure photography, just an easy way of keeping an object in view.

A good initial test! My web searches, and the discovery of all those different types of barn-door mounts and pivots and flex couplings and other scary terms, had seemed initially daunting. But in the end, building a barn-door mount was just as easy as people say it is, and I finished it in a day.

And what about a motor? I added one a few days later, with a stepper and an Arduino. But that's a separate article.

August 10, 2017

Announcement: Clojure.spec implementation for Node.js

A few months ago I started implementing Speculaas, a Clojure.spec implementation for Node.js. This is the  announcement of a series of blog posts on this site in which I will show how to use this npm package for specification based testing of your code.

Have fun,

Maurits


Forward only binary patching

A couple of weeks ago I’ve added some new functionality to dfu-tool which is shipped in fwupd. The dfu-tool utility (via libdfu) now has the ability to forward-patch binary files, somewhat like bsdiff does. To do this it compares the old firmware with the new firmware, finding blocks of data that are different and storing the new content and the offset in a .dfup file. The reason for storing the new content rather than a binary diff (like bsdiff) is that you can remove non-free and non-redistributable code without actually including it in the diff file (which, you might be doing if you’re neutering/removing the Intel Management Engine). This does make reversing the binary patch process impossible, but this isn’t a huge problem if we keep the old file around for downgrades.

$ sha1sum ~/firmware-releases/colorhug-1.1.6.bin
955386767a0108faf104f74985ccbefcd2f6050c  ~/firmware-releases/colorhug-1.1.6.bin

$ sha1sum ~/firmware-releases/colorhug-1.1.7.bin
9b7dbb24dbcae85fbbf045e7ff401fb3f57ddf31  ~/firmware-releases/colorhug-1.1.7.bin

$  dfu-tool patch-create ~/firmware-releases/colorhug-1.1.6.bin
~/firmware-releases/colorhug-1.1.7.bin colorhug-1_1_6-to-1_1_7.dfup
-v
Dfu-DEBUG: binary growing from: 19200 to 19712
Dfu-DEBUG: add chunk @0x0000 (len 3)
Dfu-DEBUG: add chunk @0x0058 (len 2)
Dfu-DEBUG: add chunk @0x023a (len 19142)
Dfu-DEBUG: blob size is 19231

$ dfu-tool patch-dump colorhug-1_1_6-to-1_1_7.dfup
checksum-old: 955386767a0108faf104f74985ccbefcd2f6050c
checksum-new: 9b7dbb24dbcae85fbbf045e7ff401fb3f57ddf31
chunk #00     0x0000, length 3
chunk #01     0x0058, length 2
chunk #02     0x023a, length 19142

$ dfu-tool patch-apply ~/firmware-releases/colorhug-1.1.6.bin
colorhug-1_1_6-to-1_1_7.dfup new.bin -v
Dfu-DEBUG: binary growing from: 19200 to 19712
Dfu-DEBUG: applying chunk 1/3 @0x0000 (length 3)
Dfu-DEBUG: applying chunk 2/3 @0x0058 (length 2)
Dfu-DEBUG: applying chunk 3/3 @0x023a (length 19142)

$ sha1sum new.bin
9b7dbb24dbcae85fbbf045e7ff401fb3f57ddf31  new.bin

Perhaps a bad example here, the compiler changed between 1.1.6 and 1.1.7 so lots of internal offsets changed and there’s no partitions inside the image; but you get the idea. For some system firmware where only a BIOS default was changed this can reduce the size of the download from megabytes to tens of bytes; the largest thing in the .cab then becomes the XML metadata (which also compresses rather well). Of course in this case you can also use bsdiff if it’s already installed — I’ve not yet decided if it makes sense for fwupd to runtime require tools like bspatch as these could be needed by the firmware builder bubblewrap functionality, or if it could just be included as statically linked binaries in the .cab file. Comments welcome.

August 08, 2017

Building local firmware in fwupd

Most of the time when you’re distributing firmware you have permission from the OEM or ODM to redistribute the non-free parts of the system firmware, e.g. Dell can re-distribute the proprietary Intel Management Engine as part as the firmware capsule that gets flashed onto the hardware. In some cases that’s not possible, for example for smaller vendors or people selling OpenHardware. In this case I’m trying to help Purism distribute firmware updates for their hardware, and they’re only able to redistribute the Free Software coreboot part of the firmware. For reasons (IFD, FMAP and CBFS…) you need to actually build the target firmware on the system you’re deploying onto, where build means executing random low-level tools to push random blobs of specific sizes into specific unnecessarily complex partition formats rather than actually compiling .c into executable code. The current solution is a manually updated interactive bash script which isn’t awesome from a user-experience or security point of view. The other things vendors have asked for in the past is a way to “dd” a few bytes of randomness into the target image at a specific offset and also to copy the old network MAC address into the new firmware. I figured fwupd should probably handle this somewhat better than a random bash script running as root on your live system.

I’ve created a branch that allows you to ship an archive (I’m suggesting using the simple .tar format, as the .cab file will be compressed already) within the .cab file as the main “release”. Within the .tar archive will be a startup.sh file and all the utilities or scripts needed to run the build operation, statically linked if required. At firmware deploy time fwupd will explode the tar file into a newly-created temp directory, create a bubblewrap container which has no network and limited file-system access and then run the startup.sh script. Once complete, fwupd will copy out just the firmware.bin file and then destroy the bubblewrap container and the temporary directory. I’ve not yet worked out how to inject some things into the jail, for instance we sometimes need the old system firmware blob if we’re applying a bsdiff rather than just replacing all the data. I’m tempted to just mount /var/lib/fwupd/builder/ into the jail as read-only and then get the fwupd plugin to create the required data there at startup before the jail gets created.

Not awesome, but more reliable and secure than just running random bash files as root. Comments welcome.

August 07, 2017

Krita 3.2.0: We Have a Release Candidate!

After last week’s rollercoaster ride (if you haven’t seen it, check the news, then the update!), it was hard to get back into making releases and writing code. Yet, here is the release candidate for Krita 3.2.0. Fixes since the second beta include:

  • Some cleanups when handling OpenGL
  • Show a clearer error when loading the wintab32.dll file fails on Windows
  • Fix a regression where bezier tools couldn’t close the curve and couldn’t create a second curve
  • Fixes for working with multiple windows in subwindow mode where one of the documents is set to “stays on top”
  • Fix resetting the Level of Detail cache when changing the visibility of a layer: this fixes an issue where after changing the visibility of a layer, the color picker would pick from an older version of the layer.
  • Save the last used folder in the Reference Images Docker
  • Don’t create nested autosave documents.
  • Add recognizing uc-logic tablets on Linux
  • Improve the stabilizer
  • Improve the communication between Krita and the gmic-qt plugin
  • Fix progress reporting after the gmic-qt filter returns
  • Fix loading a custom brush preset that uses the text brush
  • Update the new brush preset set

Download

Windows

Note for Windows users: if you encounter crashes, please follow these instructions to use the debug symbols so we can figure out where Krita crashes.

Linux

(If, for some reason, Firefox thinks it needs to load this as text: to download, right-click on the link.)

When it is updated, you can also use the Krita Lime PPA to install Krita 3.2.0-rc.1 on Ubuntu and derivatives.

OSX

Source code

md5sums

For all downloads:

Key

The Linux appimage and the source tarball are signed. You can retrieve the public key over https here:
0x58b9596c722ea3bd.asc
. The signatures are here.

Support Krita

Krita is a free and open source project. Please consider supporting the project with donations or by buying training videos or the artbook! With your support, we can keep the core team working on Krita full-time.

August 05, 2017

Keeping Git Branches in Sync

I do most of my coding on my home machine. But when I travel (or sit in boring meetings), sometimes I do a little hacking on my laptop. Most of my code is hosted in GitHub repos, so when I travel, I like to update all the repos on the laptop to make sure I have what I need even when I'm offline.

That works great as long as I don't make branches. I have a variable $myrepos that lists all the github repositories where I want to contribute, and with a little shell alias it's easy enough to update them all:

allgit() {
    pushd ~
    foreach repo ($myrepos)
        echo $repo :
        cd ~/src/$repo
        git pull
    end
    popd
}

That works well enough -- as long as you don't use branches.

Git's branch model seems to be that branches are for local development, and aren't meant to be shared, pushed, or synchronized among machines. It's ridiculously difficult in git to do something like, "for all branches on the remote server, make sure I have that branch and it's in sync with the server." When you create branches, they don't push to the server by default, and it's remarkably difficult to figure out which of your branches is actually tracking a branch on the server.

A web search finds plenty of people asking, and most of the Git experts answering say things like "Just check out the branch, then pull." In other words, if you want to work on a branch, you'd better know before you go offline exactly which branches in which repositories might have been created or updated since the last time you worked in that repository on that machine. I guess that works if you only ever work on one project in one repo and only on one or two branches at a time. It certainly doesn't work if you need to update lots of repos on a laptop for the first time in two weeks.

Further web searching does find a few possibilities. For checking whether there are files modified that need to be committed, git status --porcelain -uno works well. For checking whether changes are committed but not pushed, git for-each-ref --format="%(refname:short) %(push:track)" refs/heads | fgrep '[ahead' works ... if you make an alias so you never have to look at it.

Figuring out whether branches are tracking remotes is a lot harder. I found some recommendations like git branch -r | grep -v '\->' | while read remote; do git branch --track "${remote#origin/}" "$remote"; done and for remote in `git branch -r`; do git branch --track ${remote#origin/} $remote; done but neither of them really did what I wanted. I was chasing down the rabbit hole of writing shell loops using variables like

  localbranches=("${(@f)$(git branch | sed 's/..//')}")
  remotebranches=("${(@f)$(git branch -a | grep remotes | grep -v HEAD | grep -v master | sed 's_remotes/origin/__' | sed 's/..//')}")
when I thought, there must be a better way. Maybe using Python bindings?

git-python

In Debian, the available packages for Git Python bindings are python-git, python-pygit2, and python-dulwich. Nobody on #python seemed to like any of them, but based on quick attempts with all three, python-git seemed the most straightforward. Confusingly, though Debian calls it python-git, it's called "git-python" in its docs or in web searches, and it's "import git" when you use it.

It's pretty straightforward to use, at least for simple things. You can create a Repo object with

from git import Repo
repo = Repo('.')
and then you can get lists like repo.heads (local branches), repo.refs (local and remote branches and other refs such as tags), etc. Once you have a ref, you can use ref.name, check whether it's tracking a remote branch with ref.tracking_branch(), and make it track one with ref.set_tracking_branch(remoteref). That makes it very easy to get a list of branches showing which ones are tracking a remote branch, something that had proved almost impossible with the git command line.

Nice. But now I wanted more: I wanted to replace those baroque git status --porcelain and git for-each-ref commands I had been using to check whether my repos needed committing or pushing. That proved harder.

Checking for uncommitted files, I decided it would be easiest stick with the existing git status --porcelain -uno. Which was sort of true. git-python lets you call git commands, for cases where the Python bindings aren't quite up to snuff yet, but it doesn't handle all cases. I could call:

    output = repo.git.status(porcelain=True)
but I never did find a way to pass the -uno; I tried u=False, u=None, and u="no" but none of them worked. But -uno actually isn't that important so I decided to do without it.

I found out later that there's another way to call the git command, using execute, which lets you pass the exact arguments you'd pass on the command line. It didn't work to call for-each-ref the way I'd called repo.git.status (repo.git.for_each_ref isn't defined), but I could call it this way:

    foreachref = repo.git.execute(['git', 'for-each-ref',
                                   '--format="%(refname:short) %(push:track)"',
                                   'refs/heads'])
and then parse the output looking for "[ahead]". That worked, but ... ick. I wanted to figure out how to do that using Python.

It's easy to get a ref (branch) and its corresponding tracking ref (remote branch). ref.log() gives you a list of commits on each of the two branches, ordered from earliest to most recent, the opposite of git log. In the simple case, then, what I needed was to iterate backward over the two commit logs, looking for the most recent SHA that's common to both. The Python builtin reversed was useful here:

    for i, entry in enumerate(reversed(ref.log())):
        for j, upstream_entry in enumerate(reversed(upstream.log())):
            if entry.newhexsha == upstream_entry.newhexsha:
                return i, j

(i, j) are the number of commits on the local branch that the remote hasn't seen, and vice versa. If i is zero, or if there's nothing in ref.log(), then the repo has no new commits and doesn't need pushing.

Making branches track a remote

The last thing I needed to do was to make branches track their remotes. Too many times, I've found myself on the laptop, ready to work, and discovered that I didn't have the latest code because I'd been working on a branch on my home machine, and my git pull hadn't pulled the info for the branch because that branch wasn't in the laptop's repo yet. That's what got me started on this whole "update everything" script in the first place.

If you have a ref for the local branch and a ref for the remote branch, you can verify their ref.name is the same, and if the local branch has the same name but isn't tracking the remote branch, probably something went wrong with the local repo (like one of my earlier attempts to get branches in sync, and it's an easy fix: ref.set_tracking_branch(remoteref).

But what if the local branch doesn't exist yet? That's the situation I cared about most, when I've been working on a new branch and it's not on the laptop yet, but I'm going to want to work on it while traveling. And that turned out to be difficult, maybe impossible, to do in git-python.

It's easy to create a new local branch: repo.head.create(repo, name). But that branch gets created as a copy of master, and if you try to turn it into a copy of the remote branch, you get conflicts because the branch is ahead of the remote branch you're trying to copy, or vice versa. You really need to create the new branch as a copy of the remote branch it's supposed to be tracking.

If you search the git-python documentation for ref.create, there are references to "For more documentation, please see the Head.create method." Head.create takes a reference argument (the basic ref.create doesn't, though the documentation suggests it should). But how can you call Head.create? I had no luck with attempts like repo.git.Head.create(repo, name, reference=remotebranches[name]).

I finally gave up and went back to calling the command line from git-python.

repo.git.checkout(remotebranchname, b=name)
I'm not entirely happy with that, but it seems to work.

I'm sure there are all sorts of problems left to solve. But this script does a much better job than any git command I've found of listing the branches in my repositories, checking for modifications that require commits or pushes, and making local branches to mirror new branches on the server. And maybe with time the git-python bindings will improve, and eventually I'll be able to create new tracking branches locally without needing the command line.

The final script, such as it is: gitbranchsync.py.

August 03, 2017

The embedded color sensor in the ThinkPad P70

Last week at GUADEC Christian gave me a huge laptop to borrow with the request to “make the color sensor work in Fedora”.

This thing is a beast: the display is 17″ and 4K resolution, two GPUs, two hard-disks and a battery. It did not fit in my laptop bag, only just squeezed in my suitcase, and weighed a metric ton. I was pretty confident I could make the color sensor work, as I previously reverse engineered the Huey and we had existing support for the embedded Huey as found in the W700 ThinkPad. Just like the W700, the sensor is located in the palm-rest, and so the laptop lid needs to be shut (and the display kept on) when showing calibration patches. I told Christian it should be a case of adding an unlock code, another PID to the udev rules and then we should be good. How wrong could I be!

Lets look on what’s shipped by default with the Laptop. In Microsoft Windows 10, the Pantone application prompts you to recalibrate your display once per week. When you manually run the calibration wizard, it asks you to choose your display temperature and also the gamma value for the curve, defaulting to D65 whitepoint and 2.2 gamma.

It then asks you to shut the lid and uses a combination of flashing the Thinkpad red-dot LED and using sound effects to show you the progress of the calibration. By opening the lid a tiny fraction we can see the pattern is as follows:

  1. Black offset
  2. Red primary
  3. Green primary
  4. Blue primary
  5. Red gamma ramp, 7 steps
  6. Green gamma ramp, 7 steps
  7. Blue gamma ramp, 7 steps

The USB traffic was intercepted for two runs, and dumped to CSV files. These were further post-processed by a python script to filter down and to help understand the protocol used.

From completely reverse engineering the protocol, we can show that the Pantone X-Rite sensor in the palm-rest of the P70 is nothing more than a brightness sensor with a display-specific primary correction matrix. You can’t actually get a RGB or XYZ color out of the sensor, the only useful thing that it can do is linearize the VCGT ramps, and with only 7 measurements for each channel I’m surprised it can do anything very useful at all.

Is it not known how the sensor and calibration tool can create an ICC profile without hardcoding the primaries in the sensor EEPROM itself, and this is probably what happens here. Whilst the sensor would be able to linearize a display where the hardware-corrected backlight suddenly becomes non-linear, it is completely unable to return a set of display primaries. Said another way, the sensor can’t tell the difference between a 100% red and 100% blue patch.

These findings also correlate with the findings from AnandTech who say that calibrating the display with the embedded sensor actually makes the LCD worse when measuring saturation accuracy, whitepoint and grayscale accuracy.

If you’re serious about color calibration, please don’t use the built-in sensor, and if you are buying a top-end Xeon system save a few dollars and don’t bother with the color sensor. For $20 extra Pantone could have used a calibrated XYZ one-piece sensor from MAZeT, which would have given them a true “color sensor” that could have sampled much quicker and with true XYZ-adapted readings.

The irony is of course, you can’t even use the HueyCOLOR sensor as a ambient light sensor. As the device is in the palm-rest, you frequently cover it with your hand — and any backlight adjustment would feed back into the sensor causing the backlight to flash.

If you actually want to make a colord sensor driver for this hardware we’d need to extend the capability bitfield to show it’s only capable of brightness, and also continue parsing the EEPROM to find the spectral sensitivities, but that’s not something that I think is useful to do.

If you want to know about the low-level protocol used and more information about the device, I’ve written some notes which document the protocol used. Disappointing.

August 02, 2017

GCompris at Akademy 2017

I didn’t blog yet about my experience during this year’s Akedemy, the annual conference and gathering of the KDE community.

This time it was in Almería, Spain. The organizers made a wonderful work, and everything went perfectly good. The event was well covered locally, with at least three newspaper articles.

(Photo by Guille Fuertes)

I could meet old friends and make new ones, visited a few awesome places, and I think we all had a wonderful time there.

It was also a very productive event, with lots of progress done or started for the different projects.
On my side, I had some very interesting feedback after my talk about GCompris. I was asking for some help on a few things, including deb, flatpak and appimage packaging on linux. For flatpak, Aleix Pol showed me the initial work he already did, and I could help him adding a missing dependency.
For the appimage, I was very happy to see the next day a message from probono on our irc channel, who saw my slides and started working on the appimage for GCompris :). That was a great surprise and I couldn’t hope for better help for it, as he is basically the man behind the appimage project, and already helped creating the appimage for Krita. And finally for the deb package, we have just been contacted by a Kubuntu packager who is willing to have an up-to-date package in their next release. The community is awesome, thank you all! 😀

(Photos by Paul Brown)

Besides, I could attend several very interesting talks, and had a whole lot of interesting technical and human talks that helped me to learn a lot, at least I believe so.

So much thanks to the KDE community for always being so cool, and again big thanks to KDE e.V. for supporting this event and my participation to it.

Krita Foundation: Update

When we posted the news about our tax wrangle yesterday, we did expect to make some waves. We didn’t expect the incredible response from all of you! A day later, over 500 awesome people have donated a total of €9562 (at the time of writing, check the fancy progress bar we’ve finally managed to create!). Fourteen people have joined the development fund, too! Thank you all!

But that’s not all, we were stunned when we were approached by the team at Private Internet Access. They wanted to help us out and sponsor Krita with £20,000! Private Internet Access provides worldwide fast, multi-gigabit VPN Tunnel gateways. They already sponsor a great many awesome organizations, and now also Krita!

Of course, this makes our work much easier. Not only do we don’t have to worry whether we can pay the tax bill, but we can also start sending money to Dmitry again! And that’s why if you’ve been wondering whether you should still help Krita with a donation (or by getting something from the shop), please don’t hesitate! To recap, our current plans are:

  • Make exporting and rendering animations much faster
  • Improve the performance of some brush engines on multi-core systems
  • Add touch functionality to Krita
  • Continue the implementation of the new text tool
  • Finish the remaining kickstarter features: lazy brush, stacked brushes, reference image tool.
  • Release Krita 3.2 (soon!) and Krita 4.0 (this year)

And then, since we’ve basically reworked all parts of Krita, spend some time working on bugs, polish and, as always, performance.


Boudewijn Rempt, Krita Maintainer

One-time Donation

€1 minimum

 

Monthly Subscription

€1 minimum

Stichting Krita Foundation
Korte Assenstraat 11 7411JP Deventer, the Netherlands.
IBAN: NL72INGB0007216397
BIC: INGBNL2A

August 01, 2017

FreeCAD Arch development news - July 2017

WTF, July development news in August, I hear you yelling (it's not only me!) But there was some last minute topic I really wanted to complete to include in this report... But now that it is complete, I think it deserves another post on its own, so I'll only mention it here briefly. It will...

Krita Foundation in Trouble

Please check the August 2nd update, too!

Even while we’re working on a new beta for Krita 3.2 and a new development build for 4.0 (with Python, on Windows!), we have to release some bad news as well.

The Krita Foundation is having trouble with the Dutch tax authorities. This is the situation:

In February, we received an audit from the tax inspector. We were quite confident we wouldn’t have any problems because when we setup the Krita Foundation in 2013, we took the advice of a local tax consultant on how to setup the Foundation and its administration. We registered for VAT with the tax authorities and kept our books as instructed by the consultant.

However, the tax inspector found two problems springing from the fact the Foundation sells training videos and books, so it is not 100% funded by donations. This means that the tax authorities see the Foundation is as partly a company, partly as not a company.

  • We claimed back VAT for things bought by the Foundation. But we should only have claimed the VAT back to the percentage of income generated from sales, which is about 15%. (The rest of our income is donations.)
  • The Foundation was created to be able to have Dmitry work full-time on Krita. Because we sell stuff, the tax inspector has determined that we’re a company, and should have paid VAT in the Netherlands over the work Dmitry has been doing in Russia. Even though there is no VAT in Russia on the kind of work Dmitry is doing. But because we’re not a company, we cannot reclaim the VAT.

In other words, because we’re mostly not a company, we should not have claimed back the VAT we paid; but we’re also considered fully a company, so we should have paid VAT in the Netherlands over Dmitry’s work, which we could not have claimed back because the Foundation is mostly not a company. (It didn’t matter that Dmitry owns the copyright on his work, and that the Foundation doesn’t own anything related to Krita except for the trademark…)

The result is a tax bill of 24,000 euros. We have consulted with an accountant, and together we got the bill reduced to 15,006 euros, including fines and interest, but the accountant’s bill came to 4,000 euros.

The discussions with the tax inspector and accountant have taken months to resolve. The stress that caused has not just eaten into our coding productivity, it also meant we had no certainty at all, so we missed our usual May fundraiser. At one point, we were almost certain the Krita Foundation would go broke.

We ended 2016 with about 30,000 euros in the bank, enough to keep us going until June: it has dwindled to € 5.461,63 by now. Fortunately, we did have the help of three extra-ordinary sponsors who helped us survive through this period. We also have found a sponsor for some extra work on Krita, mainly focused on improving performance on systems with many cores and restoring some touch functionality and touch ui to Krita.

Still, we have not been able to be as productive as we wanted, and some of the cool things we were working on aren’t done yet, and maybe won’t get done in time for Krita 4.0.

Then there is another complication: until the middle of 2016, I had a day job next to my work on Krita, giving me in effect two full-time jobs. I suffered a break-down in the middle of 2016, and had to stop my day job. I lived on my savings until they ran out by the end of 2016, when I started working full-time for the Foundation as well, so our expenses have gone up too.

For the future, we’ve separated the sales of training videos, artbooks and sales on the Windows Store and Steam out to a separate company, so the Krita Foundation is 100% a non-profit. That means that there is no VAT payable in the Netherlands over the work Dmitry does in Russia. We checked the new setup with the accountants, and they have given green light for it.

Now we’ve got the bills, we can start making plans again:

  • As I said in the beginning. we’re currently working on Krita 3.2 and the next pre-alpha development release of 4.0. Our community is healthy, with more and more people chipping in and having fun hacking on Krita, working on the documentation and creating illustrations, comics and animations with Krita.
  • In September, we will run a fundraiser for development in 2018. After we’ve finished the backlog of kickstarter-promised features for 4.0 or 4.1, our focus will be on stability and polish for a year. “Zero bugs!” — that’s going to be the rallying cry for the fundraiser and for 2018!

Though there is no reason to wait until September to make a donation or join the development fund!

Note: in the interests of full transparency, you can find our end-of-year reports for 2013, 2014, 2015 and 2016 here.

Boudewijn Rempt, Krita Maintainer

One-time Donation

€1 minimum

 

Monthly Subscription

€1 minimum

Stichting Krita Foundation
Korte Assenstraat 11 7411JP Deventer, the Netherlands.
IBAN: NL72INGB0007216397
BIC: INGBNL2A

July 30, 2017

Remapping the Caps Lock key on Raspbian

I've remapped my CapsLock key to be another Ctrl key since time immemorial. (Actually, since the ridiculous IBM PC layout replaced the older keyboards that had Ctrl there already, to the left of the A.)

On normal current Debian distros, that's fairly easy: you can edit /etc/default/keyboard to have XKBOPTIONS="ctrl:nocaps.

You might think that would work in Raspbian, since it also has /etc/default/keyboard and raspi-config writes keyboard options to it if you set any (though of course CapsLock isn't among the choices it offers you). But it doesn't work in the PIXEL desktop: there, that key still acts as a Caps Lock.

Apparently lxde (under PIXEL's hood) overrides the keyboard options in /etc/default/keyboard without actually giving you a UI to set them. But you can add your own override by editing ~/.config/lxkeymap.cfg. Make the option line look something like this:

option = ctrl:nocaps

Then when you restart PIXEL, you should have a Control key where CapsLock used to be.

July 26, 2017

New Evince format support: Adobe Illustrator and CBR files

A quick update, as we've touched upon Evince recently.

I mentioned that we switched from using external tools for decompression to using libarchive. That's not the whole truth, as we switched to using libarchive for CBZ, CB7 and the infamous CBT, but used a copy/paste version of unarr to support RAR files, as libarchive support lacks some needed features.

We hope to eventually remove the internal copy of unarr, but, as a stop-gap, that allowed us to start supporting CBR comics out of the box, and it's always a good thing when you have one less non-free package to grab from somewhere to access your media.

The second new format is really two formats, from either side of the 2-digit-year divide: PostScript-based Adobe Illustrator and PDF-based Adobe Illustrator. Evince now declares to support "the format" if both of the backends are built and supported. It only took 12 years, and somebody stumbling upon the feature request while doing bug triaging. The nooks and crannies of free software where the easy feature requests get lost :)


Both features will appear in GNOME 3.26, the out-of-the-box CBR support is however available now in an update for the just released Fedora 26.

July 25, 2017

My Life (So Far) in Numbers

As of 2017:

  • I have been at the company I helped to start for 18 years
  • I have been married for 12 years
  • I have a 9-year-old child (and 6, and 1)

I’m going for a personal high-score.

July 23, 2017

Nambé Lake Nutcrackers

[Nambe Lake]

This week's hike was to Nambé Lake, high in the Sangre de Cristos above Santa Fe.

It's a gorgeous spot, a clear, shallow mountain lake surrounded by steep rocky slopes up to Lake Peak and Santa Fe Baldy. I assume it's a glacial cirque, though I can't seem to find any confirmation of that online.

[Clark's nutcracker taking bread from my hand.] There's a raucous local population of Clark's nutcrackers, a grey relative of the jays (but different from the grey jay) renowned for its fearlessness and curiosity. One of my hiking companions suggested they'd take food from my hand if I offered. I broke off a bit of my sandwich and offered it, and sure enough, a nutcracker flew right over. Eventually we had three or four of them hanging around our lunch spot.

The rocky slopes are home to pikas, but they're shy and seldom seen. We did see a couple of marmots in the rocks, and I caught a brief glimpse of a small, squirrel-sized head that looked more grey than brown like I'd expect from a rock squirrel. Was it a pika? I'll never know.

We also saw some great flowers. Photos: Nambé Lake Nutcrackers.

July 22, 2017

Krita 3.2.0: Second Beta Available

We’re releasing the second beta for Krita 3.2.0 today! These beta builds contain the following fixes, compared to the first 3.2.0 beta release. Keep in mind that this is a beta: you’re supposed to help the development team out by testing it, and reporting issues on bugs.kde.org.

  • There are still problems on Windows with the integration with the gmic-qt plugin, but several lockups have been fixed.
  • The smart patch tool merge was botched: this is fixed now.
  • It wasn’t possible anymore to move vector objects with the mouse (finger and tablet worked fine). This is fixed now.
  • Fixed the size and flow sliders
  • Fixes to saving jpg or png images without a transparency channel

Download

The KDE download site has been updated to support https now.

Windows

Note for Windows users: if you encounter crashes, please follow these instructions to use the debug symbols so we can figure out where Krita crashes.

Linux

(If, for some reason, Firefox thinks it needs to load this as text: to download, right-click on the link.)

A snap image for the Ubuntu App Store will be available from the Ubuntu application store. When it is updated, you can also use the Krita Lime PPA to install Krita 3.2.0-beta.2 on Ubuntu and derivatives.

OSX

Source code

md5sums

For all downloads:

Key

The Linux appimage and the source tarball are signed. You can retrieve the public key over https here:
0x58b9596c722ea3bd.asc
. The signatures are here.

Support Krita

Krita is a free and open source project. Please consider supporting the project with donations or by buying training videos or the artbook! With your support, we can keep the core team working on Krita full-time.

July 21, 2017

SECURITY FOR THE SECURITY GODS! SANDBOXING FOR THE SANDBOXING THRONE

@GodTributes took over my title, soz.

Dude, where's my maintainer?

Last year, probably as a distraction from doing anything else, or maybe because I was asked, I started reviewing bugs filed as a result of automated flaw discovery tools (from Coverity to UBSan via fuzzers) being run on gdk-pixbuf.

Apart from the security implications of a good number of those problems, there was also the annoyance of having a busted image file bring down your file manager, your desktop, or even an app that opened a file chooser either because it was broken, or because the image loader for that format didn't check for the sanity of memory allocations.

(I could have added links to Bugzilla entries for each one of the problems above, but that would just make it harder to read)

Two big things happened in gdk-pixbuf 2.36.1, which was used in GNOME 3.24:

  • the removal of GdkPixdata as a stand-alone image format loader. We really don't want to load GdkPixdata files from sources other than generated sources or embedded data structures, and removing that loader closed off those avenues. We still ended up fixing a fair number of naive assumptions in helper functions though.
  • the addition of a thumbnailer for gdk-pixbuf supported images. Images would not be special-cased any more in gnome-desktop's thumbnailing code, making the file manager, the file chooser and anything else navigating directories full of broken and huge images more reliable.
But that's just the start. gdk-pixbuf continues getting bug fixes, and we carry on checking for overflows, underflows and just flows, breaks and beats in general.

Programmatic Thumbellina portrait-maker

Picture, if you will, a website making you download garbage files from the Internet, the ROM dump of a NES cartridge that wasn't properly blown on and digital comic books that you definitely definitely paid for.

That's a nice summary of the security bugs foisted upon GNOME in past year or so, even if, thankfully, we were ahead of the curve in terms of fixing those issues (the GStreamer NSF decoder bug was removed in 2013, the comics backend in evince was rewritten over a period of 2 years and committed in March 2017).

Still, 2 pieces of code were running on pretty much every file downloaded, on purpose or not, from the Internet: Tracker's indexers and the file manager's thumbnailers.

Tracker started protecting itself not long after the NSF vulnerability, even if recent versions of GStreamer weren't vulnerable, as we mentioned.

That left the thumbnailers. Some of those are first party, like the gdk-pixbuf, and those offered by core applications (Evince, Videos), written by GNOME developers (yours truly for both epub/mobi and Nintendo DS).

They're all good quality code I'd vouch for (having written or maintained quite a few of them), but they can rely on third-party libraries (say GStreamer, poppler, or libarchive), have naive or insufficiently defensive code (gdk-pixbuf loaders,  GStreamer plugins) or, worst of all: THIRD-PARTY EXTENSIONS.

There are external plugins and extensions for image formats in gdk-pixbuf, for video and audio formats in GStreamer, and for thumbnailers pretty much anywhere. We can't control those, but the least we can do when they explode in a wet mess is make sure that the toilet door is closed.

Not even Nicholas Cage can handle this Alcatraz

For GNOME 3.26 (and today in git master), the thumbnailer stall will be doubly bolted by a Bubblewrap sandbox and a seccomp blacklist.

This closes a whole vector of attack for the GNOME Desktop, but doesn't mean we're completely out of the woods. We'll need to carry on maintaining and fixing security bugs in those libraries and tools we depend on, as GStreamer plugin bugs still affect Videos, gdk-pixbuf bugs still affect Photos and Eye Of Gnome, etc.

And there are limits to what those 2 changes can achieve. The sandboxing and syscall blacklisting avoids those thumbnailers writing anything but an image file in PNG format in a specific directory. There's no network, the filename of the original file is hidden and sanitised, but the thumbnailer could still create a crafted PNG file, and the sandbox doesn't work inside a sandbox! So no protection if the application running the thumbnailer is inside Flatpak.

In fine

GNOME 3.26 will have better security for thumbnailers, so you won't "need to delete GNOME Files".

But you'll probably want to be careful with desktops that forked our thumbnailing code, namely Cinnamon and MATE, which don't implement those security features.

The next step for the thumbnailers will be beefing up our protection against greedy thumbnailers (in terms of CPU and memory usage), and sharing the code better between thumbnailers.

Note for later, more images of cute animals.

July 18, 2017

Krita 3.2 beta 1 Released

We’re releasing the first beta for Krita 3.2.0 today! Compared to Krita 3.1.4, released 26th of May, there are numerous bug fixes and some very cool new features. Please test this release, so we can fix bugs before the final release!

Known bugs

It’s a beta, so there are bugs. One of them is that the size and flow sliders are disabled. We promise faithfully we won’t release until that’s fixed, but in the meantime, no need to report it!

Features

  • Krita 3.2 will use the gmic-qt plugin created and maintained by the authors of G’Mic We’re still working with them to create binary builds that can run on Windows, OSX and most versions of Linux. This plugin replaces completely the older gmic plugin.
  • We added Radian’s brush set to Krita’s default brushes.

These brushes are good for create a strong painterly look:

  • There are now shortcuts for changing layer states like visibility and lock.
  • There have been many fixes to the clone brush
  • There is a new dialog from where you can copy and paste relevant information about your system for bug reports.
  • We’ve integrated the Smart Patch tool that was previously only in the 4.0 pre-alpha builds!

  • The Gaussian Blur filter now can use kernels up to 1000 pixels in diameter

Bug Fixes

Among the bigger bug fixes:

  • Painting with your finger on touch screens is back. You can enable or disable this in the settings dialog.
  • If previously you suffered from the “green brush outline” syndrome, that should be fixed now, too. Though we cannot guarantee the fix works on all OpenGL systems.
  • There have been a number of performance improvements as well
  • The interaction with the file dialog has been improved: it should be better at guessing which folder you want to open, which filename to suggest and which file type to use.

And of course, there were dozens of smaller bug fixes.

Download

The KDE download site has been updated to support https now.

Windows

Note for Windows users: if you encounter crashes, please follow these instructions to use the debug symbols so we can figure out where Krita crashes.

Linux

(For some reason, Firefox thinks it needs to load this as text: to download, right-click on the link.)

A snap image for the Ubuntu App Store will be available from the Ubuntu application store. When it is updated, you can also use the Krita Lime PPA to install Krita 3.2.0-beta.1 on Ubuntu and derivatives.

OSX

Source code

md5sums

For all downloads:

Key

The Linux appimage and the source tarball are signed. You can retrieve the public key over https here:
0x58b9596c722ea3bd.asc
. The signatures are here.

Support Krita

Krita is a free and open source project. Please consider supporting the project with donations or by buying training videos or the artbook! With your support, we can keep the core team working on Krita full-time.

July 16, 2017

Translating Markdown to LibreOffice or Word

For the Raspberry Pi Zero W book I'm writing, the publisher, Maker Media, wants submissions in Word format (but stressed that LibreOffice was fine and lots of people there use it, a nice difference from Apress). That's fine ... but when I'm actually writing, I want to be able to work in emacs; I don't want to be distracted fighting with LibreOffice while trying to write.

For the GIMP book, I wrote in plaintext first, and formatted it later. But that means the formatting step took a long time and needed exceptionally thorough proofreading. This time, I decided to experiment with Markdown, so I could add emphasis, section headings, lists and images all without leaving my text editor.

Of course, it would be nice to be able to preview what the formatted version will look like, and that turned out to be easy with a markdown editor called ReText, which has a lovely preview mode, as long as you enable Edit->Use WebKit renderer (I'm not sure why that isn't the default).

Okay, a chapter is written and proofread. The big question: how to get it into the Word format the publisher wants?

First thought: ReText has a File->Export menu. Woohoo -- it offers ODT. So I should be able to export to ODT then open the resulting file in LibreOffice.

Not so much. The resulting LibreOffice document is a mess, with formatting that doesn't look much like the original, and images that are all sorts of random sizes. I started going through it, resizing all the images and fixing the formatting, then realized what a big job it was going to be and decided to investigate other options first.

ReText's Export menu also offers HTML, and the HTML it produces looks quite nice in Firefox. Surely I could open that in LibreOffice, then save it (maybe with a little minor reformatting) as DOCX?

Well, no, at least not directly. It turns out LibreOffice has no obvious way to import an HTML file into a normal text document. If you Open the HTML file, it displays okay (except the images are all tiny thumbnails and need to be resized one by one); but LibreOffice can't save it in any format besides HTML or plaintext. Those are the only formats available in the menu in the Save dialog. LibreOffice also has a Document Converter, but it only converts Office formats, not HTML; and there's no Import... in LO's File. There's a Wizards->Web Page, but it's geared to creating a new web page and saving as HTML, not importing an existing HTML-formatted document.

But eventually I discovered that if I "Create a new Text Document" in LibreOffice, I can Select All and Copy in Firefox, followed by Paste into Libre Office. It works great. All the images are the correct size, the formatting is correct needing almost no corrections, and LibreOffice can save it as DOCX, ODT or whatever I need.

Image Captions

I mentioned that the document needed almost no corrections. The exception is captions. Images in a book need captions and figure numbers, unlike images in HTML.

Markdown specifies images as

![Image description][path/to/image.jpg)

Unfortunately, the Image description part is only visible as a mouseover, which only works if you're exporting to a format intended for a web browser that runs on desktop and laptop computers. It's no help in making a visible caption for print, or for tablets or phones that don't have mouseover. And the mouseover text disappears completely when you paste the document from Firefox into LibreOffice.

I also tried making a table with the image above and the caption underneath. But I found it looked just as good in ReText, and much better in HTML, just to add a new paragraph of italics below the image:

![][path/to/image.jpg)

*Image description here*

That looks pretty nice in a browser or when pasted into LibreOffice. But before submitting a chapter, I changed them into real LibreOffice captions.

In LibreOffice, right-click on the image; Add Caption is in the context menu. It can even add numbers automatically. It initially wants to call every caption "Illustration" (e.g. "Illustration 1", "Illustration 2" and so on), and strangely, "Figure" isn't one of the available alternatives; but you can edit the category and change it to Figure, and that persists for the rest of the document, helpfully numbering all your figures in order. The caption dialog when you add each caption always says that the caption will be "Illustration 1: (whatever you typed)" even if it's the fourteenth image you've captioned; but when you dismiss the dialog it shows up correctly as Figure 14, not as a fourteenth Figure 1.

The only problem arises if you have to insert a new image in the middle of a chapter. If you do that, you end up with two Figure 6 (or whatever the number is) and it's not clear how to persuade LibreOffice to start over with its renumbering. You can fix it if you remove all the captions and start over, but ugh. I never found a better way, and web searches on LibreOffice caption numbers suggest this is a perennial source of frustration with LibreOffice.

The bright side: struggling with captions in LibreOffice convinced me that I made the right choice to do most of my work in emacs and markdown!

July 14, 2017

July 13, 2017

Summer Sale: Made with Krita now €7,95

It’s summer — a bit rainy, but still summer! So it’s time for a summer sale — and we’ve reduced the price for the Made with Krita 2016 art books to just 7,95. That means that shipping (outside the Netherlands) is more expensive than the book itself, but it’s a great chance to get acquainted with forty great artists and their work with Krita! The book is professionally printed on 130 grams paper and softcover bound in signatures. The cover illustration is by Odysseas Stamoglou. Every artist is showcased with a great image, as well as a short bio.

Made with Krita 2016
On sale: €7,95
Forty artists from all over the world, working in all kinds of styles and on all kinds of subjects show how Krita is used in the real world to create amazing and engaging art. The book also contains a biographical section with information about each individual artist. Made with Krita 2016 is now on sale: 7,95€, excluding shipping. Shipping is 11,25€ (3,65€ in the Netherlands).

Get Made with Krita 2016

July 11, 2017

Over Half a Million Downloads per Month

The official Blender release is now being downloaded over half a million times per month, and a total of 6.5M last year.

During the period of July 2016 and July 2017, Blender has seen the release of Blender 2.78 and a/b/c fix releases.

This is not counting:

  • Experimental Builds on Buildbot
  • Release Candidates and Test Builds
  • Other services offering Blender (app stores like Steam or community sites like GraphicAll)
  • Linux repositories

Below is the full report for each platform.

July 10, 2017

security things in Linux v4.12

Previously: v4.11.

Here’s a quick summary of some of the interesting security things in last week’s v4.12 release of the Linux kernel:

x86 read-only and fixed-location GDT
With kernel memory base randomization, it was stil possible to figure out the per-cpu base address via the “sgdt” instruction, since it would reveal the per-cpu GDT location. To solve this, Thomas Garnier moved the GDT to a fixed location. And to solve the risk of an attacker targeting the GDT directly with a kernel bug, he also made it read-only.

usercopy consolidation
After hardened usercopy landed, Al Viro decided to take a closer look at all the usercopy routines and then consolidated the per-architecture uaccess code into a single implementation. The per-architecture code was functionally very similar to each other, so it made sense to remove the redundancy. In the process, he uncovered a number of unhandled corner cases in various architectures (that got fixed by the consolidation), and made hardened usercopy available on all remaining architectures.

ASLR entropy sysctl on PowerPC
Continuing to expand architecture support for the ASLR entropy sysctl, Michael Ellerman implemented the calculations needed for PowerPC. This lets userspace choose to crank up the entropy used for memory layouts.

LSM structures read-only
James Morris used __ro_after_init to make the LSM structures read-only after boot. This removes them as a desirable target for attackers. Since the hooks are called from all kinds of places in the kernel this was a favorite method for attackers to use to hijack execution of the kernel. (A similar target used to be the system call table, but that has long since been made read-only.) Be wary that CONFIG_SECURITY_SELINUX_DISABLE removes this protection, so make sure that config stays disabled.

KASLR enabled by default on x86
With many distros already enabling KASLR on x86 with CONFIG_RANDOMIZE_BASE and CONFIG_RANDOMIZE_MEMORY, Ingo Molnar felt the feature was mature enough to be enabled by default.

Expand stack canary to 64 bits on 64-bit systems
The stack canary values used by CONFIG_CC_STACKPROTECTOR is most powerful on x86 since it is different per task. (Other architectures run with a single canary for all tasks.) While the first canary chosen on x86 (and other architectures) was a full unsigned long, the subsequent canaries chosen per-task for x86 were being truncated to 32-bits. Daniel Micay fixed this so now x86 (and future architectures that gain per-task canary support) have significantly increased entropy for stack-protector.

Expanded stack/heap gap
Hugh Dickens, with input from many other folks, improved the kernel’s mitigation against having the stack and heap crash into each other. This is a stop-gap measure to help defend against the Stack Clash attacks. Additional hardening needs to come from the compiler to produce “stack probes” when doing large stack expansions. Any Variable Length Arrays on the stack or alloca() usage needs to have machine code generated to touch each page of memory within those areas to let the kernel know that the stack is expanding, but with single-page granularity.

That’s it for now; please let me know if I missed anything. The v4.13 merge window is open!

Edit: Brad Spengler pointed out that I failed to mention the CONFIG_SECURITY_SELINUX_DISABLE issue with read-only LSM structures. This has been add now.

© 2017, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

July 06, 2017

Writing a Book on the Raspberry Pi Zero W

It's official: I'm working on another book!

This one will be much shorter than Beginning GIMP. It's a mini-book for Make Media on the Raspberry Pi Zero W and some fun projects you can build with it. [Raspberry Pi Zero W]

I don't want to give too much away at this early stage, but I predict it will include light shows, temperature sensors, control of household devices, Twitter access and web scraping. And lots of code samples.

I'll be posting more about the book, and about various Raspberry Pi Zero W projects I'm exploring during the course of writing it. But for now ... if you'll excuse me, I have a chapter that's due today, and a string of addressable LEDs sitting on my desk calling out to be played with as part of the next chapter.

Gaming hardware support

While my colleagues are working on mice that shine in all kinds of different colours, I went towards the old school.

For around 10 units of currency, you should be able to find the uDraw tablet for the PlayStation 3, the drawing tablet that brought down a company.



The device contains a large touchpad which can report one or two touches, for right-clicking (as long as the fingers aren't too close), a pen interface which will make the cheapest of the cheapest Wacom tablets feel like a professional tool from 30 years in the future, a 4-button joypad (plus Start/Select/PS) with the controls either side of the device, and an accelerometer to play Marble Madness with.

The driver landed in kernel 4.10. Note that it only supports the PlayStation 3 version of the tablet, as the Wii and XBox 360 versions require receivers that aren't part of the package. Here, a USB dongle should be provided.

Recommended for: point'n'click adventure games, set-top box menu navigation.

The second driver landed in kernel 4.12, and is a primer for more work to be done. This driver adds support for the Retrode 2's joypad adapters.

The Retrode is a USB console cartridge reader which makes Sega Mega Drive (aka Genesis) and Super Nintendo (aka Super Famicom) cartridges show up as files on a mass storage devices in your computer.



It also has 4 connectors for original joypads which the aforementioned driver now splits up and labels, so you know which is which, as well as making the mouse work out of the box. I'd still recommend picking up the newer optical model of that mouse, from Hyperkin. Moving a mouse with a ball in it is like weighing a mobile phone from that same era.

I will let you inspect the add-ons for the device, like support for additional Nintendo 64 pads and cartridges, and Game Boy/GB Color/GB Advance, and Sega Master System adapters.

Recommended for: cartridge-based retro games, obviously.

Integrated firmware updates, and better integration with Games is in the plans.

I'll leave you with this video, which shows how you could combine GNOME Games, a Retrode, this driver, a SNES mouse, and a cartridge of Mario Paint. Let's get creative :)

July 05, 2017

Using a reverse-style application IDs in your application

Many upstream applications are changing their application ID from something like boxes.desktop to org.gnome.Boxes.desktop so they can be packaged as flatpaks. Where upstream doesn’t yet have this, we rewrite the desktop file in flatpak-builder so it can be packaged and deployed safely. However, more and more upstreams are building flatpaks and thus more and more apps seem to be changing desktop ID every month.

This poses a problem for the ODRS review system: When we query using the reverse-DNS-style we don’t match the hundreds of reviews submitted against the old ID. This makes the application look bad, and users file bugs against GNOME Software saying it’s broken either because “no reviews are showing up”, or that “a previously 5 star application with 30 reviews is now 2 stars with just one review”.

This also happens when companies get taken over, or when the little toy project moves from a hosting site to a proper home, e.g. com.github.FeedReader to org.gnome.FeedReader.

So, what can we do? AppData (again) to the rescue. Adding the following XML to the file allows new versions of gnome-software to do the right thing; we then get reviews and ratings for both the old and new names.

  <provides>
    <id>old-name.desktop</id>
  </provides>

If you renamed your application in the last couple of years, I’d love you to help out and add this tag to your .appdata.xml file – in all supported branches if possible. I can’t promise cookies, but your application will have more reviews and that can’t be a bad thing. Thanks!

July 04, 2017

fwupd 0.9.5 and new goodies

I’ve just released the latest version of fwupd from the development branch. 0.9.5 has the usual bug fixes, translation updates and polish, but also provides two new goodies:

We now support for updating Logitech peripherals over a protocol helpfully called DFU, which is not to be confused with the standard USB DFU protocol. This allows us to update devices such as the K780 keyboard over the Unifying layer. Although it takes a few minutes to complete, it works reliably and allows us to finally fix the receiver end of the MouseJack vulnerability. Once the user has installed the Unifying dongle update and in some cases a peripheral update they are secure again. The K780 update is in “testing” on the LVFS if anyone wants to try this straight away. You should send huge thanks to Logitech as they have provided me access to the documentation, hardware and firmware engineers required to make this possible. All the released Logitech firmwares will move to the “stable” state once this new fwupd release has hit Fedora updates-testing.

The other main feature in this release is the Intel Management Engine plugin. The IME is the source of the recent AMT vulnerability that affects the “ME blob” that is included in basically every consumer PC sold in the last decade. Although we can’t flash the ME blob using this plugin, it certainly makes it easy to query the hardware and find out if you are running a very insecure system. This plugin is more that inspired by the AMT status checker for Linux by Matthew Garrett, so you should send him cookies, not me. Actually updating the ME blob would be achieved using the standard UEFI UpdateCapsule, but it would mean your vendor does have to upload a new system firmware to the LVFS. If you’ve got a Dell you are loved, other vendors are either still testing this and don’t want to go public yet (you know who you are) or don’t care about their users. If you still don’t know what the LVFS is about, see the whitepaper and then send me an email. Anyway, obligatory technical-looking output:

$ fwupdmgr get-devices
  Guid:                 2800f812-b7b4-2d4b-aca8-46e0ff65814c
  DeviceID:             /dev/mei
  DisplayName:          Intel AMT (unprovisioned)
  Plugin:               amt
  Flags:                internal
  Version:              9.5.30
  VersionBootloader:    9.5.30

If the AMT device is present, and the display name has provisioned and the AMT version is between 6.0.x and 11.2.x, and you have not upgraded your firmware, you are vulnerable to CVE-2017-5689 and you should disable AMT in your system firmware. I’ve not yet decided if this should bubble up to the session in the form of a notification bubble, ideas welcome.

The new release is currently building for Fedora, and might be available in other distributions at some point.

June 30, 2017

Debugging with RPM packages

With one of our internal web applications based on Ruby on Rails, we’ve discovered a file descriptor leak in one of the delayed job worker processes. The worker leaked descriptors whenever it invoked a message being send to the message bus using qpid-messaging.

Since we’re using gems compiled as C++ and C extensions, in order to find the root cause, I used the packages provided through the package manager and gdb.

Big thanks to Dan Callaghan who walked me through most of the process and then found the leak in the C++ sources.

TL;DR;

  • identify the leaking descriptors and reproduce it with lsof
  • attach strace to the process and identify file descriptors which are not being closed
  • install debuginfo packages for all dependencies
  • use gdb to figure out what is going on

Reproducer

I’ve used lsof and a friend wrote a small script to quickly monitor the worker process. Looking at the opened files of the process revealed a long list which looked like half closed sockets. It turned out later, that it wasn’t the same problem since the sockets were created, but never bound/connected.

I was unable to reproduce the problem on my local development environment, but found away to do it on our staging environment which resembles production much closer. So whenever I invoked an action in the UI which resulted in a message being sent, I was able to see another file descriptor leak with lsof.

Strace the process

With the reproducer at hand, I started to strace the process:

# Note we're not filtering system calls with -e here.
# Weirdly CLOSE was not reported when just filtering network calls
strace -s 1000 -p  -o strace_output_log.strace

Dan helped me looking through the produced log output, which revealed that the system under investigation created a socket and called getpeername right after it, without binding it resulting in a leaked file descriptor.

10971 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 35
10971 getpeername(35, 0x7fffae712a90, [112]) = -1 ENOTCONN (Transport endpoint is not connected)

Install debuginfo packages and use gdb

In order to debug the system, we need debuginfo packages installed, otherwise you wont be able to step through the sources using gdb. When you attach gdb to the process it will tell you what packages it is missing, for example:

Missing separate debuginfos, use: debuginfo-install qpid-proton-c-0.10-3.fc25.x86_64

You then go install those (be mindful that you the repositories configured e.g. section name fedora-debuginfo):

debuginfo-install qpid-proton-c-0.10-3.fc25.x86_64

and basically start debugging.

Our first suspicion was the qpid messaging library and we check if it’s invocation of getpeername was leaking the file descriptors. I’ve added a break point at the point of the source code we thought was suspicious and in a separate terminal used lsof to see which file descriptor number is leaked. For example:

# I've used a watch, which executes the lsof every 2 seconds by
# default. The grep filters some of the files I'm not interested in
$ watch "lsof -p  | grep -v REG"

The lsof output will show you the leaked file descriptor number in column 4 by default. With that you can check in gdb if the file descriptor being handled in the source code is the one which leaked.

Since that achieved no results, we used gdb to break on invocations of the getpeername identifier and used backtrace to pin point in the sources where the leak occurred.


June 29, 2017

FreeCAD Arch development news - June 2017

Hi all, This is time for a new review of what has been going on in Arch development this month. Quite a lot actually, it's exciting that several things I've been working on during the last couple of months begin to flourish into pretty interesting and usable features. There is another interesting thing happening, is a very...

June 24, 2017

Mutt: Fixing Erroneous Charsets, part 632

Someone forwarded me a message from the Albuquerque Journal. It was all about "New Mexico\222s schools".

Sigh. I thought I'd gotten all my Mutt charset problems fixed long ago. My system locale is set to en_US.UTF-8, and accented characters in Spanish and in people's names usually show up correctly. But I do see this every now and then.

When I see it, I usually assume it's a case of incorrect encoding: whoever sent it perhaps pasted characters from a Windows Word document or something, and their mailer didn't properly re-encode them into the charset they were using to send the message.

In this case, the message had User-Agent: SquirrelMail/1.4.13. I suspect it came from a "Share this" link on the newspaper's website.

I used vim to look at the source of the message, and it had

Content-Type: text/plain; charset=iso-8859-1
For the bad characters, in vim I saw things like
New Mexico<92>s schools

I checked an old web page I'd bookmarked years ago that had a table of the iso-8859-1 characters, and sure enough, hex 0x92 was an apostrophe. What was wrong?

I got some help on the #mutt IRC channel, and, to make a long story short, that web table I was using was wrong. ISO-8859-1 doesn't include any characters in the range 8x-9x, as you can see on the Wikipedia ISO/IEC 8859-1.

What was happening was that the page was really cp1252: that's where those extra characters, like hex 92/octal 222 for an apostrophe, or hex 96/octal 226 for a dash (nitpick: that's an en dash, but it was used in a context that called for an em dash; if someone is going to use something other than the plain old ASCII dash - you'd think they'd at least use the right one. Sheesh!)

Anyway, the fix for this is to tell mutt when it sees iso-8859-1, use cp1252 instead:

charset-hook iso-8859-1 cp1252

Voilà! Now I could read the article about New Mexico&aposs schools.

A happy find related to this: it turns out there's a better way of looking up ISO-8859 tables, and I can ditch that bookmark to the old, erroneous page. I've known about man ascii forever, but someone I'd never thought to try other charsets. Turns out man iso_8859-1 and man iso_8859-15 have built-in tables too. Nice!

(Sadly, man utf-8 doesn't give a table. Of course, that would be a long man page, if it did!)

the world needs more fonts, honestly

‘Can you name one problem which type design (not engineering) solved and which is not predominantly aesthetic?’ Now that caught my attention on twitter. It appeared in a thread that started off with some saucy quotes: ‘the problems have already been solved’ and ‘the function of new typefaces is largely aesthetic.’

It piqued my interest because I have worked on the interaction design of a couple of font design applications. Besides that I have spent a lot of time investigating the general nature of design.

making a splash

So I jumped in and joined the twitter discussion. After a false start (oh, the joys of social media) the heart of the matter came to light: ‘It is about problems that typefaces solve, not about the problems of typeface design practice, i.e. the categories of reasons why to draw.’ So I addressed it there, have been thinking about it quite a bit more since then, and now I am going to address it better.

Let’s start with a smooth aikido move to get this discussion positioned where it belongs. When a font is to be used by many (i.e. more than 100) people, then it is a product. The type designer is the product designer; the design process is the act of product realisation. The process starts with a product definition; methodical research and design follows. Eventually a set of design drawings is created, to be engineered into shippable fonts.

This insight rebases the discussion. It is a product issue, not a design issue. Asking what problems type design can solve today, is asking: are there any product definitions left that aim to bring useful, valuable font solutions to users?

Well, allow me to make some suggestions.

think big, really big

If you write using Latin script, then it seems that you have 100.000 fonts to choose from. If you write in another script, you are suddenly scraping the barrel; 100 usable fonts is then super luxurious. Does this impact just some tiny minorities? Well, here is a handy list: writing scripts sorted by usage. If I skip Latin and add up the populations that actively use the next ten scripts, then I end up with 3.41 billion people.

The ten scripts are: Chinese, Arabic, Devanagari, Bengali‐Assamese, Cyrillic, Kana, Javanese, Hangul, Telugu and Tamil. Right after these on the list there is a group of six modestly used scripts (Gujarati, Kannada, Burmese, Malayalam, Thai and Sundanese) that nonetheless serve another 205 million people.

Here is my suggestion: Want to do something useful? Pick a popular Latin font (family), say from the top‐1000 in use, and pick one of the big‑10/modest‑6 scripts listed above. Your product definition is to design a font in that script that goes together seamlessly with the Latin font. That does not mean that your new font has to play second fiddle to the Latin one; just that they get along famously.

I can tell you from experience that it is very rewarding to design something this relevant; with the knowledge that tens, if not hundreds, of million of people are waiting out there for the results. Of the 3.615 billion people mentioned above, a good chunk owns a smartphone or will own one soon—you cannot stop commodity Android. It’s their access to the internet. They inform and express themselves using text. They need fonts.

fit for purpose

Read a book on typography and one discovers that non‐philistine typesetting starts with using proper numbers (oldstyle vs. lining, &c.), small caps, and so on. Now check 10 random fonts on the device you use to read this post. Do they contain a full set of numbers and small caps? It is going to be hit and miss. Personally, I am still waiting for oldstyle numbers for my favourite Swiss sans.

While typesetting got more efficient (hot lead, to photo, to digital), typography support got thrown overboard. Today, typography is banned to the graveyard called OpenType features. Yes I know, OT features UI is a world of hurt, but someday someone is going to do something about it (if that is you, ping me). Meanwhile, it is 2017 and fonts that just support the skimpiest of Latin glyph set feel very ‘ms‑dos’ to me; primitive, with a touch of nostalgia, but surely past due date.

So my second suggestion is to start doubling down on OpenType features. Go through the top‐1000 list of fonts and start extending them to make them useful, and valuable, for typographers. I realise there are some barriers of entry, like intellectual property and access to source files (so that they can be extended). Maybe you can pitch the company that owns them and get the gig. A straightforward case is open source fonts, you can get started right now.

fit for authors

Bold and italic are not just a good idea, they are (by default) the way to express certain conventions in text, e.g. emphasis, or denote publication titles. The defaults of html & css are an example of how enshrined this is. A week ago I was trying to select some typefaces for a new website, and it was an uphill struggle, littered with missing italic and/or bold font variants.

My third suggestion: there are plenty of holes in the top‐1000 fonts where it comes to bold and italics. Your product definition is to fill some of these, where you think it matters most. Designing a bold for someone else’s regular can be a drag. But italics can be worthwhile design work, because they start with a clean sheet and a different skeleton than the regulars. I suspect the amount of true‐design work involved is the reason italics got skipped in the first place.

Speaking of, here is a bonus product definition: real italics to be used seamlessly with that famous Swiss sans—to replace them obliques. Again a clean‐sheet project which solves a typographer’s problem. And an ambitious, high‐profile one too. You can call it Helvetalics, if you like.

fit for a new medium

Last year I was involved in an internet‐of‐things project. After a methodical start, it became immediately clear that for our combination of display (size, resolution), use (viewing distance, information density) and goals (not end up being cheap junk slapped together by engineers) we needed a font to make it work. Yes work; life or death.

New media to display text, with new properties—and new contexts for old ones—pop up regularly. These events naturally trigger product definitions for fonts to make new media work.

aesthetics, schm’sthetics

In this blog post I have not gone into aesthetics, because I didn’t need to. All I have done is look beyond the glyph shapes and spot ocean‐sized holes in the font product landscape. Just following up on my first suggestion will keep the global type designing community busy for decades with work that is 100% non‐frivolous. Suddenly today’s ‘glut’ of type designers looks like it could use some serious reinforcement troops.

A business coach once told me: ‘this design work you do is political, isn’t it?’ She meant that my design clearly impacts society and that my design decision make the world better, or worse. That starts with the decision ‘what project do I work on?’

If you get to decide the product definitions at your font shack, then your work is political.
  • Your choice of scripts is political; how many of 3.615+ billion people are you gonna throw under the bus?
  • Your choice of OT features is political; a font for typographers, or only for simple business administration?
  • Your choice of including a bold and italic is political; is your font going to be a drop‐in solution for those who just want to communicate?
  • Your choice of targeting new display media is political; are you going to leave their new users out in the cold?

If you scour the font landscape, looking for pockets of user‐felt hurt (‘what, XYZ simply doesn’t exist?’) and then do something about it by creating, or updating, a font product, then your work is political, useful and valuable. And I salute you.

June 23, 2017

Made with Krita: Bird Brains

Look what we got today by snail mail:

It’s a children’s nonfiction book, nice for adults too, by Jeremy Hyman (text) and Haude Levesque (art). All the art was made with Krita!

Jeremy:

One of my favorite illustrations is the singing White-throated sparrow (page 24-25). The details of the wing feathers, the boldness of the black and white stripes, and the shine in the eye all make the bird leap off the page.

I love the picture of the long tailed manakins (page 32-33). I think this illustration captures the velvety black of the body plumage, and the soft texture of the blue cape, and the shining red of the cap. I also like the way the unfocused background makes the birds in the foreground seem so crisp. It reminds me of seeing these birds in Costa Rica – in dark and misty tropical forests, the world often seems a bit out of focus until a bright bird, flower, or butterfly focuses your attention.

I also love the picture of the red-knobbed hornbill (page 68-69). You can see the texture and detail of the feathers, even in the dark black feathers of the wings and back. The illustration combines the crispness and texture of the branches, leaves and fruits in the foreground, with the softer focus on leaves in the background and a clear blue sky. Something about this illustration reminds me of the bird dioramas at the American Museum of Natural History – a place I visited many times with my grandfather (to whom the book is dedicated). The realism of those dioramas made me fantasize about seeing those birds and those landscapes someday. Hopefully, good illustrations will similarly inspire some children to see the birds of the world.

Haude:

My name is Haude Levesque and I am a scientific illustrator, writer and fish biologist. I have always been interested in both animal sciences and art, and it has been hard to choose between both careers, until I started illustrating books as a side job, about ten years ago while doing my post doc. My first illustration job was a book about insects behavior (Bug Butts), which I did digitally after taking an illustration class at the University of Minnesota. Since then, I have been both teaching biology, illustrating and writing books, while raising my two kids. The book “Bird Brains” belongs to a series with two other books that I illustrated, and Iwanted to have illustrations that look similar, which is full double page illustrations of a main animal in its natural habitat. I started using Krita only a year ago when illustrating “Bird Brains”, upon a suggestion from my husband, who is a software engineer and into open source software. I was getting frustrated with the software I had used previously, because it did not allow me to render life-like drawings, and required too many steps and time to do what I wanted. I also wanted my drawing to look like real paintings and also get the feeling that I am painting and Krita’s brushes do just that. It is hard for me to choose a favorite illustration in “Bird Brains”, I like them all and I know how many hours I spent on each. But, if I had to, I would say the superb lyrebird, page 28 and 29. I like how this bird is walking and singing at the same time and I like how I could render its plumage while giving him a real life posture.

I also like the striated heron, page 60 and 61. Herons are my favorite birds and I like the contrast between the pink and the green of the lilypads. Overall I am very happy with the illustrations in this book and I am planning on doing more scientific books for kids and possibly try fiction as well.

You can get it here from Amazon or here from Book Depository.

June 21, 2017

Stellarium 0.16.0

Stellarium 0.16.0 is a stable version (based on Qt5.6 but it can still be built from sources with Qt5.4) that introduces some new features and closes 38 bug and wishlist reports.

New features include
- RemoteSync plugin, which allows running several connected instances of Stellarium.
- Non-spherical models for solar system objects like asteroids and small moons.
- Solar system config file is now split into two parts.
- AstroCalc feature extension: What's Up Tonight, graphs, ...
- DSO: Addition of catalogs of peculiar galaxies
- New Skycultures: Belarusian, Hawaiian Star Lines
- Telescope plugin: support for the RTS2 telescope system.
- Location can now be read from a GPS device.

A huge thanks to the people who helped us a lot by reporting bugs!

Full list of changes:
- Added support of irregular solar system objects (3D models of minor bodies) (LP: #1153171)
- Added Remote Sync plugin
- Added GPS devices support (LP: #1448673)
- Added splitting ssystem.ini data - now have separate ssystem_major.ini and ssystem_minor.ini. Only the latter shall be editable for the users.
- Added a few more timezone replacements.
- Added support an asterisms for the sky cultures
- Added better identification for existing serial ports for GPS
- Added context support for constellations and asterisms names
- Added support RTS2 for Telescope Control Plugin
- Added a new option in config.ini file esp. for the planetariums (astro/
flag_forced_meteor_activity=(false|true) - to show a sporadic meteors activity without atmosphere).
- Added support of date and time formatting settings from main app to AstroCalc tool.
- Added a line for the approximate time of the meridian passing in AstroCalc tool (LP: #1652523)
- Added TLE tracking to RTS2 telescopes
- Added different star scales in the Oculars plugin, even separately for ocular and CCD views (LP: #1656940)
- Added information on magnification of the combination of eyepiece/lens/telescope in proportions of the telescope diameters.
- Added configurable options to AstroCalc tool
- Added support Catalan (Valencian) language
- Added support Kabyle language
- Added 'What's Up Tonight' tool - AstroCalc subsystem (LP: #1080408)
- Added Dark Doodad Nebula to DSO catalog
- Added more data for analysis to the Exoplanets plugin.
- Added calculation of list of visible object for current location (AstroCalc)
- Added tool to remove custom markers by coordinates
- Added support double and variable stars for AstroCalc tool
- Added support translation novae names (parse nova name to extract constellation name and year of flash)
- Added lists of bright double and bright variable stars to Search Tool
- Added customized buttons for toggle ICRS/Galactic/Ecliptic grids (LP: #730689)
- Added customized buttons for toggle constellation boundaries (LP: #1249239)
- Added import/export bookmarks (LP: #1675078)
- Added confirmation before deleting landscape (LP: #1635137)
- Added guessing for name of location and use it when spaceship is landing (LP: #1220561)
- Added an 'Additional settings' block for selected object info
- Added showing a proper motions for some stars
- Added an optional indication of mount mode (LP: #1172860)
- Added option to toggle the usage the buttons background on bottom bar (LP: #1589702)
- Added config option for planet apparent magnitude configuration
- Added description to the planets magnitude algorithm
- Added contrast index for DSO
- Added AstroCalc/Graphs feature
- Added new option to configure behaviour of Satellites (Satellites/time_rate_limit = 1.0)
- Added a scripting function to retrieve property names (helpful for configuring RemoteSync).
- Added 3 additional catalogs to our DSO catalog (Arp, VV, PK)
- Added packing of DSO catalog
- Added the showing the groups of the artificial satellites
- Added Belarusian sky culture
- Adding Hawaiian Starlines sky culture
- Added list of bright stars with high proper motion to the Search Tool/Lists and AstroCalc/Positions features
- Added lunar magnitude to sky brightness computation (brightness variation during lunar eclipses!) (LP: #1471546)
- Added property handling for the labels for ArchaeoLines plugin.
- Added Ukrainian translation for Belarusian skyculture
- Added Ukrainian translation for Hawaiian Starlines skyculture
- Added context and improve English phrase (AstroCalc)
- Added missed zh_HK zh_TW zh_CN descriptions for western sky-culture (LP: #1698473)
- Added Belarusian description for Belarusian sky culture (LP: #1698535)
- Added Bengali description for Belarusian sky culture (LP: #1698608)
- Added 'simulation speed' for tooltip of time (LP: #1698510)
- Added saving an angular separation option for phenomena
- Fixed crash when tried use of SIMBAD for offline mode (LP: #1674836)
- Fixed build scripts to update Index once more just before final run.
- Fixed COSPAR designation parser.
- Fixed wrong extinction coordinate frame of Zodiacal Light (LP: #1675699)
- Fixed a missing initialisation (avoids crash at program end)
- Fixed bug for loading default scenery on non-Englush locale in Scenery3D plugin
- Fixed typo in name of dark nebula LDN 935 (LP: #1679066)
- Fixed Scripting Engine: avoiding broken script when calling waitFor() after the point in time to wait.
- Fixed infoMap data for comets.
- Fixed issue of reloading of DSO names when filter of catalogs is updated.
- Fixed small cosmetic bug for SIMBAD status line.
- Fixed the opposition/conjunction longitude line: the line follows the ecliptic pole on date now (LP: #1687307)
- Fixed very stupid bug for Date & Time dialog.
- Fixed translation on-the-fly issue for AstroCalc tool.
- Fixed IAU constellation label for stars with high proper motion (LP: #1690615)
- Fixed crash when AstroCalc tool is active and we are on the spaceship
- Fixed several Coverity issues
- Fixed bug which disabled the bright flare-type Iridium point source drawing
- Fixed fullscreen behaviour on switching tasks (Alt+Tab) (LP: #550337)
- Fixed dynamic eye adaptation behaviour when persistent orbits are enabled
- Fixed switching horizontal/equatorial coordinates for Solar system objects (AstroCalc/Positions)
- Fixed crash when observer is flying on spaceship
- Fixed storing torchlight and coordinate display flag to config (Scenery3D) (LP: #1502245)
- Fixed placing a custom markers on HighDPI devices (LP: #1688985)
- Fixed infostring for ecliptical coordinates data (Nutation)
- Fixed strings consistency for Solar System Editor plug-in (LP: #1698783)
- Fixed string overlap with FOV and FPS labels (LP: #1698789)
- Restore searchable for telescope names (LP: #1686857)
- Updated Scenery3D plugin
- Updated Satellites plugin: refactoring the source code and speed-up rendering of satellites
- Updated rule to create a directory for screenshots (LP: #1626686)
- Updated GUI: refactoring blocks
- Updated a GUI behaviour: a map in LocationDialog resizable is now.
- Updated a GUI behaviour: enabled low resolution for High DPI devices.
- Updated a GUI: added a few GUI text improvements
- Updated InnoSetup script
- Updated and revised stars names
- Updated Historical Supernovae catalog (Added SN 2017cbv)
- Updated meteor showers catalog (Added data for year 2017)
- Updated AstroCalc tool: increased an accuracy of 'Altitude vs. Time' diagram
- Updated AstroCalc tool: speed-up calculations for some types of phenomena
- Updated AstroCalc tool: extension of features for Ephemeris Tool
- Updated AstroCalc tool: improve WUT
- Updated filters for DSO objects in AstroCalc/WUT tool
- Updated sorting rules for AstroCalc/Positions tool
- Updated filters for Solar system bodies (AstroCalc/Positions)
- Updated tab rules for Search Tool
- Updated list of locations
- Updated scripts and scripting engine
- Updated list of DSO's names
- Updated headers for AstroCalc tools
- Updated 'Go to home' feature.
- Updated Bookmarks tool.
- Updated API documentation
- Updated Exoplanets plugin: improve placing of the exoplanet systems
- Updated Oculars plugin: the limit for diameter of binoculars aperture upped to 200mm
- Updated calculation for boundaries of IAU constellations
- Updated default supernovae catalog
- Updated Belarusian translation for skycultures
- Updated cmake variable names
- Updated Ocean landscape
- Updated RemoteControl panels with new functionality
- Updated rules for TLE updated: never update TLE's for any date before Oct 4, 1957, 19:28:34GMT ;-)
- Removed script 'Analemma'
- Removed useless vertex color data from asteroid models.
- Removed Polynesian sky culture (replaced by Hawaiian starlines)

June 20, 2017

Writing a task list powerline segment

This is one of these notes to self, in case I want to redo,extend or modify this in the future... Not sure it is of any interest to anybody less nerd, but here it goes for your enjoyment anyway :) I use powerline since quite some time, it prints fancy prompts in your terminal, where...

June 17, 2017

Krita Available from the Windows Store

Some time ago, we got in touch with a team from Microsoft that was reaching out to projects like Krita and Inkscape. They were offering to help our projects to publish in the Windows Store, doing the initial conversion and helping us get published.

We decided to take them up on their offer. We have had the intention to offer Krita on the Windows Store for quite some time already, only we never had the time to get it done.

Get

Putting Krita in the Windows Store makes Krita visible to a whole new group of people. plus…

Money

And we wanted to do the same as on Steam, and put a price-tag on Krita in the store. Publishing Krita on the Store takes time, and the Krita project really needs funding at the moment. (Note, though, that buying Krita in the Windows Store means part of your money goes to Microsoft: it’s still more effective to donate).

In return, if you get Krita from the Windows Store, you get automatic updates, and it becomes really easy to install Krita on all your Windows systems. Krita will also run in a sandbox, like other Windows apps.

Basically, you’re paying for convenience, and to help the project continue.

And there’s another reason to put Krita in the Windows Store: to make sure we’re doing it, and not someone else, unconnected to the project.

For Free Software

Krita is free software under the GNU Public License. Having Krita in the Windows Store doesn’t change that. The Store page has links to the source code (though they might be hardish to find, we don’t control the store layout), and that contains instructions on how to build Krita. If you want to turn your own build into an appx bundle, that’s easy enough.

You can use the Desktop App Converter directly on your build, or you can use it on the builds we make available.

There are no functional differences between Krita as downloaded from this website, and Krita as downloaded from the Windows store. It’s the same binaries, only differently packaged.

Steam

We currently still have Krita on Steam, too. We intend to keep it on Steam, and are working on adding the training videos to Steam as well. People who have purchased the lifetime package of Krita Gemini will get all the videos as they are uploaded.

We’re also working on getting Krita 3 into Steam, as a new product, at the same price as Krita in the Windows store — and the same story. Easy updates and installs on all your systems, plus, a purchase supports Krita development.

Additionally, it looks like we might find some funding for updating Krita Gemini to a new version. It’ll be different, because the Gemini approach turns out to be impossible with Qt 5 and Qt Quick 2: we have already spent several thousands of euros on trying to get that to work.

Still, we have to admit that Krita on Steam is slow going. It’s not the easiest app store to work with (that is Ubuntu’s Snap), and uploading all the videos takes a lot of time!

June 16, 2017

Flycatchers Fledging, and The Buck Stops Here

We've had a pair of ash-throated flycatchers in the nest box I set up in the yard. I've been watching them bring bugs to the nest for a couple of weeks now, but this morning they've been acting unusual: fluttering around the corner of the house near my office window, calling to each other, not spending nearly as much time near the nest. I suspect one or more of the chicks may have fledged this morning, though I have yet to see more than two flycatchers at once. They still return to the nest box occasionally (one of them just delivered a big grasshopper), so not all the chicks have fledged yet. Maybe if I'm lucky I'll get to see one fledge.

I hope they're not too affected by the smoky air. We have two fires filling the air with smoke: the Bonita Fire, 50 miles north, and as of yesterday a new fire in Jemez Springs, only about half that distance. Yesterday my eyes were burning, my allergies were flaring up, and the sky was worse than the worst days in Los Angeles in the 70s. But it looks like the firefighters have gotten a handle on both fires; today is still smoky, with a major haze down in the Pojoaque Valley and over toward Albuquerque, but the sky above is blue and the smoke plume from Jemez Springs is a lot smaller and less dark than it was yesterday. Fingers crossed!

[Buck in velvet, drinking at the pond] And just a few minutes ago, a buck with antlers in velvet wandered into our garden to take a drink at the pond. Such a nice change from San Jose!

June 15, 2017

First Development Builds for Krita 4.0!

It’s still early days, and we have to say this up-front: these builds are not ready for daily work. We mean it, you might luck out, but you might also seriously lose work. Please test, and please report issues on bugs.kde.org! (But check whether your issue has already been reported…) That said…

Here are the first builds of Krita 4.0 pre-alpha!

This is as big, if not bigger a step than it was going from Krita 2.9 to Krita 3.0. No, we haven’t ported Krita to Qt6 (phew!), but we have replaced the entire vector layer system: instead of using the Open Document Graphics standard, Krita now uses the SVG standard to store vector information. This makes Krita more compatible with other applications, like inkscape. Krita can still load existing Krita documents with ODG vector layers, but will only save SVG vector layers. Once a file has been saved with Krita 4.0 pre-alpha, Krita 3.x cannot open vector layers in that file any more.

We have also rewritten a lot of the interaction with vector objects, to make working with vector layers easier and more productive, and we’d like your feedback on that as well.

And of course, this isn’t the only big change.

There is a complete new airbrush system, developed by Allen Marshall, that replaces the existing airbrush system. This will affect brush presets that use the airbrush option, but the new system is so much better that there was no reason to keep the old system in parallel.

Eugene Ingerman has added a healing brush tool. Just select the sticky plaster icon in the toolbox, and paint over the area you want to be patched out!

There is a new system for saving images that should be much safer than the old one, and that warns you when saving to a format that will lose you data.

There’s a much improved palette docker, by Wolthera van Hövell tot Westerflier, that allows you to organize a palette in groups of colors, and reorganize the palettes using drag and drop, and edit swatches by double-clicking.

There’s a new docker that makes it possible to load SVG symbols and drag and drop them as shapes onto the image. Handy for speech bubbles, and we’ve included David Revoy’s Pepper and Carrot speech bubble library to get you started!

And there’s much more ready for you to explore and experiment with!

We’re still working on the new text tool. We got the basics working only last week, but that isn’t in these development builds yet. It’s too rough for even that!

The Python plugin has been merged, and is ready for testing, but here we’ve run into another problem: we haven’t been able to figure out yet how to bundle Python and the Python modules for scripting Krita yet. It works fine when building Krita from source on supported Linux systems. We haven’t managed to build it on Windows or on OSX yet, at all. If you can help us with that, please contact us!

The Scripter — ad-hoc scripting in Krita, created by Eliakin Costa.

Download

Windows

Note for Windows users: if you encounter crashes, please follow these instructions to use the debug symbols so we can figure out where Krita crashes.

For development builds, we only create 64 bits windows portable zip files, Linux appimages and OSX disk images.

Linux

OSX

Source code

md5sums

For all downloads:

Key

The Linux appimage and the source tarball are signed. You can retrieve the public key over https here: 0x58b9596c722ea3bd.asc. The signatures are here.

Support Krita

Krita is a free and open source project. Please consider supporting the project with donations or by buying training videos or the artbook! With your support, we can keep the core team working on Krita full-time.

June 12, 2017

G’MIC 2.0: A second breath for open-source image processing

Disclaimer: This article is a duplicate of this post, originally published on the Pixls.us website, by the same authors.

The IMAGE team of the research laboratory GREYC in Caen/France is pleased to announce the release of a new major version (numbered 2.0) of its project G’MIC: a generic, extensible, and open source framework for image processing. Here, we present the main advances made in the software since our last article. The new features presented here include the work carried out over the last twelve months (versions 2.0.0 and 1.7.x, for x varying from 2 to 9).


Links:


1. G’MIC: A brief overview

G’MIC is an open-source project started in August 2008, by the IMAGE team. This French research team specializes in the fields of algorithms and mathematics for image processing. G’MIC is distributed under the CeCILL license (which is GPL compatible) and is available for multiple platforms (GNU/Linux, MacOS and Windows). It provides a variety of user interfaces for manipulating generic image data, that is to say, 2D or 3D multispectral images (or sequences) with floating-point pixel values. This includes, of course, “classic” color images.

G'MIC logo Fig.1.1: Logo of the G’MIC project, an open-source framework for image processing, and its mascot Gmicky.

The popularity of G’MIC mostly comes from the plug-in it provides for GIMP (since 2009). To date, there are more than 480 different filters and effects to apply to your images, which considerably enlarges the list of image processing filters available by default in GIMP.

G’MIC also provides a powerful and autonomous command-line interface, which is complementary to the CLI tools you can find in the famous ImageMagick or GraphicsMagick projects. There is also a web service G’MIC Online, allowing to apply image processing effects directly from a browser. Other (but less well known) G’MIC-based interfaces exist: a webcam streaming tool ZArt, a plug-in for Krita, a subset of filters available in Photoflow, Blender or Natron… All these interfaces are based on the CImg and libgmic libraries, that are portable, thread-safe and multi-threaded, via the use of OpenMP.

G’MIC has more than 950 different and configurable processing functions, for a library of only 6.5Mio, representing a bit more than 180 kloc. The processing functions cover a wide spectrum of the image processing field, offering algorithms for geometric manipulations, colorimetric changes, image filtering (denoising and detail enhancement by spectral, variational, non-local methods, etc.), motion estimation and registration, display of primitives (2D or 3D mesh objects), edge detection, object segmentation, artistic rendering, etc. It is therefore a very generic tool for various uses, useful on the one hand for converting, visualizing and exploring image data, and on the other hand for designing complex image processing pipelines and algorithms (see these project slides for details).

2. A new versatile interface, based on Qt

One of the major new features of this version 2.0 is the re-implementation of the plug-in code, from scratch. The repository G’MIC-Qt developed by Sébastien (an experienced member of the team) is a Qt-based version of the plug-in interface, being as independent as possible of the widget API provided by GIMP.

G'MIC-Qt plug-in 1 Fig.2.1: Overview of version 2.0 of the G’MIC-Qt plug-in running for GIMP.

This has several interesting consequences:

  • The plug-in uses its own widgets (in Qt) which makes it possible to have a more flexible and customizable interface than with the GTK widgets used by the GIMP plug-in API: for instance, the preview window becomes resizable at will, manages zooming by mouse wheel, and can be freely moved to the left or to the right. A filter search engine by keywords has been added, as well as the possibility of choosing between a light or dark theme. The management of favorite filters has been also improved and the interface even offers a new mode for setting the visibility of the filters. Interface personalization is now a reality.

  • The plug-in also defines its own API, which is used to facilitate its integration in third party software (other than GIMP). In practice, a software developer has to write a single file host_software.cpp implementing the functions of the API to make the link between the plug-in and the host application. Currently, the file host_gimp.cpp does this for GIMP as a host. But there is now also a stand-alone version available (file host_none.cpp that runs this Qt interface in solo mode, from a shell (with command gmic_qt).

  • Boudewijn Rempt, project manager and developer of the marvelous painting software Krita, has also started writing such a file host_krita.cpp to make this “new generation” plug-in communicate with Krita. In the long term, this should replace the previous G’MIC plug-in implementation they made (currently distributed with Krita), which is aging and poses maintenance problems for developers.

Minimizing the integration effort for developers, sharing the G’MIC plug-in code between different applications, and offering a user interface that is as comfortable as possible, have been the main objectives of this complete redesign. As you can imagine, this rewriting required a long and sustained effort, and we can only hope that this will raise interest among other software developers, where having a consistent set of image processing filters could be useful (a file host_blender.cpp available soon ? We can dream!). The animation below illustrates some of the features offered by this new Qt-based interface.

G'MIC-Qt plug-in 2 Fig.2.2: The new G’MIC-Qt interface in action.

Note that the old plug-in code written in GTK was updated also to work with the new version 2.0 of G’MIC, but has fewer features and probably will not evolve anymore in the future, unlike the Qt version.

3. Easing the work of cartoonists…

One of G’MIC’s purposes is to offer more filters and functions to process images. And that is precisely something where we have not relaxed our efforts, despite the number of filters already available in the previous versions!

In particular, this version comes with new and improved filters to ease the colorization of line-art. Indeed, we had the chance to host the artist David Revoy for a few days at the lab. David is well known to lovers of art and free software by his multiple contributions in these fields (in particular, his web comic Pepper & Carrot is a must-read!). In collaboration with David, we worked on the design of an original automatic line-art coloring filter, named Smart Coloring.

Smart coloring 1 Fig.3.1: Use of the “Colorize line-art [smart coloring]” filter in G’MIC.

When drawing comics, the colorization of line-art is carried out in two successive steps: The original drawing in gray levels (Fig.3.2.1) is first pre-colored with solid areas, i.e. by assigning a unique color to each region or distinct object in the drawing (Fig.3.2.3). In a second step, the colourist reworks this pre-coloring, adding shadows, lights and modifying the colorimetric ambiance, in order to obtain the final colorization result (Fig.3.2.4). Practically, flat coloring results in the creation of a new layer that contains only piecewise constant color zones, thus forming a colored partition of the plane. This layer is then merged with the original line-art to get the colored rendering (merging both in multiplication mode, typically).

Smart coloring 2 Fig.3.2: The different steps of a line-art coloring process (source: David Revoy).

Artists admit it themselves: flat coloring is a long and tedious process, requiring patience and precision. Classical tools available in digital painting or image editing software do not make this task easy. For example, even most filling tools (bucket fill) do not handle discontinuities in drawn lines very well (Fig.3.3.a), and even worse when lines are anti-aliased. It is then common for the artist to perform flat coloring by painting the colors manually with a brush on a separate layer (Fig.3.3.b), with all the precision problems that this supposes (especially around the contour lines, Fig.3.3.c). See also this link for more details.

Smart coloring 3 Fig.3.3: Classical problems encountered when doing flat coloring (source: David Revoy).

It may even happen that the artist decides to explicitly constrain his style of drawing, for instance by using aliased brushes in a higher resolution image, and/or by forcing himself to draw only connected contours, in order to ease the flat colorization work that has to be done afterwards.

The Smart Coloring filter developed in version 2.0 of G’MIC allows to automatically pre-color an input line-art without much work. First, it analyses the local geometry of the contour lines (estimating their normals and curvatures). Second, it (virtually) does contour auto-completion using spline curves. This virtual closure allows then the algorithm to fill objects with disconnected contour plots. Besides, this filter has the advantage of being quite fast to compute and gives coloring results of similar quality to more expensive optimization techniques used in some proprietary software. This algorithm smoothly manages anti-aliased contour lines, and has two modes of colorization: by random colors (Fig.3.2.2 and Fig.3.4) or guided by color markers placed beforehand by the user (Fig.3.5).

Smart coloring 4 Fig.3.4: Using the G’MICSmart Coloring” filter in random color mode, for line-art colorization (source: David Revoy).

In “random” mode, the filter generates a piecewise constant layer that is very easy to recolor with correct hues afterwards. This layer indeed contains only flat color regions, and the classic bucket fill tool is effective here to quickly reassign a coherent color to each existing region synthesized by the algorithm.

In the user-guided markers mode, color spots placed by the user are extrapolated in such a way that it respects the geometry of the original drawing as much as possible, taking into account the discontinuities in the pencil lines, as this is clearly illustrated by the figure below:

Smart coloring 5 Fig.3.5: Using the G’MICSmart Coloring” filter in user-guided color markers mode, for line-art colorization (source: David Revoy).

This innovative, flat coloring algorithm has been pre-published on HAL (in French): A semi-guided high-performance flat coloring algorithm for line-arts. Curious people could find there all the technical details of the algorithm used. The recurring discussions we had with David Revoy on the development of this filter enabled us to improve the algorithm step by step, until it became really usable in production. This method has been used successfully (and therefore validated) for the pre-colorization of the whole episode 22 of the webcomic Pepper & Carrot.

The wisest of you know that G’MIC already had a line-art colorization filter! True, but unfortunately it did not manage disconnected contour lines so well (such as the example in Fig.3.5), and could then require the user to place a large number of color spots to guide the algorithm properly. In practice, the performance of the new flat coloring algorithm is far superior.

And since it does not see any objection to anti-aliased lines, why not create ones? That is the purpose of another new filter “Repair / Smooth [antialias]” able to add anti-aliasing to lines in cartoons that would have been originally drawn with aliased brushes.

Smooth [antialias] Fig.3.6: Filter “Smooth [antialias]” smooths contours to reduce aliasing effect in cartoons (source: David Revoy).

4. …Not to forget the photographers!

“Colorizing drawings is nice, but my photos are already in color!”, kindly remarks the impatient photographer. Don’t be cruel! Many new filters related to the transformation and enhancement of photos have been also added in G’MIC 2.0. Let’s take a quick look of what we have.

4.1. CLUTs and colorimetric transformations

CLUTs (Color Lookup Tables) are functions for colorimetric transformations defined in the RGB cube: for each color (Rs,Gs,Bs) of a source image Is, a CLUT assigns a new color (Rd,Gd,Bd) transferred to the destination image Id at the same position. These processing functions may be truly arbitrary, thus very different effects can be obtained according to the different CLUTs used. Photographers are therefore generally fond of them (especially since these CLUTs are also a good way to simulate the color rendering of certain old films).

In practice, a CLUT is stored as a 3D volumetric color image (possibly “unwrapped” along the z = B axis to get a 2D version). This may quickly become cumbersome when several hundreds of CLUTs have to be managed. Fortunately, G’MIC has a quite efficient CLUT compression algorithm (already mentioned in a previous article), which has been improved version after version. So it was finally in a quite relax atmosphere that we added more than 60 new CLUT-based transformations in G’MIC, for a total of 359 CLUTs usable, all stored in a data file that does exceed 1.2 Mio. By the way, let us thank Pat David, Marc Roovers and Stuart Sowerby for their contributions to these color transformations.

CLUTs Fig.4.1.1: Some of the new CLUT-based transformations available in G’MIC (source: Pat David).

But what if you already have your own CLUT files and want to use them in GIMP? No problem ! The new filter “Film emulation / User-defined” allows to apply such transformations from CLUT data file, with a partial support of files with extension .cube (CLUT file format proposed by Adobe, and encoded in ASCII o_O!).

And for the most demanding, who are not satisfied with the existing pre-defined CLUTs, we have designed a very versatile filter “Colors / Customize CLUT“, that allows the user to build their own custom CLUT from scratch: the user places colored keypoints in the RGB color cube and these markers are interpolated in 3D (according to a Delaunay triangulation) in order to rebuild a complete CLUT, i.e. a dense function in RGB. This is extremely flexible, as in the example below, where the filter has been used to change the colorimetric ambiance of a landscape, mainly altering the color of the sky. Of course, the synthesized CLUT can be saved as a file and reused later for other photographs, or even in other software supporting this type of color transformations (for example RawTherapee or Darktable).

Customize CLUT 1 Fig.4.1.2: Filter “Customize CLUT” used to design a custom color transform in the RGB cube.

Customize CLUT 2 Fig.4.1.3: Result of the custom colorimetric transformation applied to a landscape.

To stay in the field of color manipulation, let us also mention the appearance of the filter “Colors / Retro fade” which creates a “retro” rendering of an image with grain generated by successive averages of random quantizations of an input color image.

Retro fade Fig.4.1.4: Filter “Retro fade” in the G’MIC plug-in.

4.2. Making the details pop out

Many photographers are looking for ways to process their digital photographs so as to bring out the smallest details of their images, sometimes even to exaggeration, and we can find some of them in the pixls.us forum. Looking at how they perform allowed us to add several new filters for detail and contrast enhancement in G’MIC. In particular, we can mention the filters “Artistic / Illustration look” and “Artistic / Highlight bloom“, which are direct re-implementations of the tutorials and scripts written by Sébastien Guyader as well as the filter “Light & Shadows / Pop shadows” suggested by Morgan Hardwood. Being immersed in such a community of photographers and cool guys always gives opportunities to implement interesting new effects!

Illustration look Fig.4.2.1: Filters “Illustration look” and “Highlight bloom” applied to a portrait image.

In the same vein, G’MIC gets its own implementation of the Multi-scale Retinex algorithm, something that was already present in GIMP, but here enriched with additional controls to improve the luminance consistency in images.

Retinex Fig.4.2.2: Filter “Retinex” for improving luminance consistency.

Our friend and great contributor to G’MIC, Jérome Boulanger, also implemented and added a dehazing filter “Details / Dcp dehaze” to attenuate the fog effect in photographs, based on the Dark Channel Prior algorithm. Setting the parameters of this filter is kinda hard, but the filter gives sometimes spectacular results.

DCP dehaze 1 DCP dehaze 2 Fig.4.2.3: Filter “DCP Dehaze” to attenuate the fog effect.

And to finish with this subsection, let us mention the implementation in G’MIC of the Rolling Guidance algorithm, a method to simplify images that has become a key step used in many newly added filters. This was especially the case in this quite cool filter for image sharpening, available in “Details / Sharpen [texture]“. This filter works in two successive steps: First, the image is separated into a texture component + a color component, then the details of the texture component only are enhanced before the image is recomposed. This approach makes it possible to highlight all the small details of an image, while minimizing the undesired halos near the contours, a recurring problem happening with more classical sharpening methods (such as the well known Unsharp Mask).

Sharpen [texture] Fig.4.2.4: The “Sharpen [texture]“” filter shown for two different enhancement amplitudes.

4.3. Masking by color

As you may know, a lot of photograph retouching techniques require the creation of one or several “masks”, that is, the isolation of specific areas of an image to receive differentiated processing. For example, the very common technique of luminosity masks is a way to treat differently shadows and highlights in an image. G’MIC 2.0 introduces a new interesting filter “Colors / Color mask [interactive]” that implements a relatively sophisticated algorithm (albeit computationally demanding) to help creating complex masks. This filter asks the user to hover the mouse over a few pixels that are representative of the region to keep. The algorithm learns in real time the corresponding set of colors or luminosities and deduces then the set of pixels that composes the mask for the whole image (using Principal Component Analysis on the RGB samples).

Once the mask has been generated by the filter, the user can easily modify the corresponding pixels with any type of processing. The example below illustrates the use of this filter to drastically change the color of a car

Color mask [interactive] Fig.4.3.1: Changing the color of a car, using the filter “Color mask [interactive]“.

It takes no more than a minute and a half to complete, as shown in the video below:

Fig.4.3.2: Changing the color of a car, using filter “Color mask [interactive]” (video tutorial).

This other video exposes an identical technique to change the color of the sky in a landscape.

Fig.4.3.3: Changing the color of the sky in a landscape, using filter “Color mask [interactive]” (video tutorial).

5. And for the others…

Since illustrators and photographers are now satisfied, let’s move on to some more exotic filters, recently added to G’MIC, with interesting outcomes!

5.1. Average and median of a series of images

Have you ever wondered how to easily estimate the average or median frame of a sequence of input images? The libre aficionado Pat David, creator of the site pixls.us often asked the question. First of all when he tried to denoise images by combining several shots of a same scene. Then he wanted to simulate a longer exposure time by averaging photographs taken successively. And finally, calculating averages of various kind of images for artistic purposes (for example, frames of music video clips, covers of Playboy magazine or celebrity portraits).

Hence, with his cooperation, we added new commands -median_files,-median_videos, -average_files and-average_videos to compute all these image features very easily using the CLI tool gmic. The example below shows the results obtained from a sub-sequence of the « Big Buck Bunny” video. We have simply invoked the following commands from the Bash shell:

$ gmic -average_video bigbuckbunny.mp4 -normalize 0.255 -o average.jpg
$ gmic -median_video bigbuckbunny.mp4 -normalize 0.255 -o median.jpg`

Big buck bunny 1 Fig.5.1.1: Sequence in the « Big Buck Bunny” video, directed by the Blender foundation.

Big buck bunny 2 Fig.5.1.2: Result: Average image of the « Big Buck Bunny” sequence above.

Big buck bunny 3 Fig.5.1.3: Result: Median image of the « Big Buck Bunny” sequence above.

And to stay in the field of video processing, we can also mention the addition of the commands -morph_files and -morph_video that render temporal interpolations of video sequences, taking the estimated intra-frame object motion into account, thanks to a quite smart variational and multi-scale estimation algorithm.

The video below illustrates the rendering difference obtained for the retiming of a sequence using temporal interpolation, with (right) and without (left) motion estimation.

Fig.5.1.4: Video retiming using G’MIC temporal morphing technique.

5.2. Deformations and “Glitch Art”

Those who like to mistreat their images aggressively will be delighted to learn that a bunch of new image deformation and degradation effects have appeared in G’MIC.

First of all, the filter “Deformations / Conformal maps” allows one to distort an image using conformal maps. These deformations have the property of preserving the angles locally, and are most often expressed as functions of complex numbers. In addition to playing with predefined deformations, this filter allows budding mathematicians to experiment with their own complex formulas.

Conformal maps Fig.5.2.1: Filter “Conformal maps” applying a angle-preserving transformation to the image of Mona Lisa.

Fans of Glitch Art may also be concerned by several new filters whose rendering look like image encoding or compression artifacts. The effect “Degradations / Pixel sort” sorts the pixels of a picture by row or by column according to different criteria and to possibly masked regions, as initially described on this page.

Pixel sort Fig.5.2.2: Filter “Pixel sort” for rendering a kind of “Glitch Art” effect.

Degradations / /Pixel sort also has two little brothers, filters “Degradations / Flip & rotate blocks” and “Degradations / Warp by intensity“. The first divides an image into blocks and allows to rotate or mirror them, potentially only for certain color characteristics (like hue or saturation, for instance).

Flip and rotate blocks Fig.5.2.3: Filter “Flip & rotate blocks” applied to the hue only to obtain a “Glitch Art” effect.

The second locally deforms an image with more or less amplitude, according to its local geometry. Here again, this can lead to the generation of very strange images.

Warp by intensity Fig.5.2.4: Filter “Warp by intensity” applied to the image of Mona Lisa (poor Mona!).

It should be noted that these filters were largely inspired by the Polyglitch plug-in, available for Paint.NET, and have been implemented after a suggestion from a friendly user (yes, yes, we try to listen to our most friendly users!).

5.3. Image simplification

What else do we have in store? A new image abstraction filter, Artistic / Sharp abstract, based on the Rolling Guidance algorithm mentioned before. This filter applies contour-preserving smoothing to an image, and its main consequence is to remove the texture. The figure below illustrates its use to generate several levels of abstraction of the same input image, at different smoothing scales.

Sharp abstract Fig.5.3.1: Creating abstractions of an image via the filter “Sharp abstract“.

In the same vein, G’MIC also gets a filter Artistic / Posterize which degrades an image to simulate posterization. Unlike the filter with same name available by default in GIMP (which mainly tries to reduce the number of colors, i.e. do color quantization), our version adds spatial simplification and filtering to approach a little more the rendering of old posters.

Posterize Fig.5.3.2: Filter “Posterize” of G’MIC, compared to the filter with same name available by default in GIMP.

5.4. Other filters

If you still want more (and in this case one could say you are damn greedy!), we will end this section by discussing some of the new, but unclassifiable filters.

We start with the filter “Artistic / Diffusion tensors“, which displays a field of diffusion tensors, calculated from the structure tensors of an image (structure tensors are symmetric and positive definite matrices, classically used for estimating the local image geometry). To be quite honest, this feature had not been originally developed for an artistic purpose, but users of the plug-in came across it by chance and asked to make a GIMP filter from it. And yes, this is finally quite pretty, isn’t it?

Diffusion tensors Fig.5.4.1: Filter “Diffusion Tensors” filter and its multitude of colored ellipses.

From a technical point of view, this filter was actually an opportunity to introduce new drawing features into the G’MIC mathematical evaluator, and it has now become quite easy to develop G’MIC scripts for rendering custom visualizations of various image data. This is what has been done for instance, with the command -display_quiver reimplemented from scratch, and which allows to generate this type of rendering:

-display_quiver Fig. 5.4.2: Rendering vector fields with the G’MIC command -display_quiver.

For lovers of textures, we can mention the apparition of two new fun effects: First, the “Patterns / Camouflage” filter. As its name suggests, this filter produces a military camouflage texture.

Camouflage Fig. 5.4.3: Filter “Camouflage“, to be printed on your T-shirts to go unnoticed in parties!

Second, the filter “Patterns / Crystal background” overlays several randomly colored polygons in order to synthesize a texture that vaguely looks like a crystal seen under a microscope. Pretty useful to quickly render colored image backgrounds.

Crystal background Fig.5.4.4: Filter “Crystal background” in action.

And to end this long overview of new G’MIC filters developed since last year, let us mention “Rendering / Barnsley fern“. This filter renders the well-known Barnsley fern fractal. For curious people, note that the related algorithm is available on Rosetta Code, with even a code version written in the G’MIC script language, namely:

# Put this into a new file 'fern.gmic' and invoke it from the command line, like this:
# $ gmic fern.gmic -barnsley_fern

barnsley_fern :
  1024,2048
  -skip {"
    f1 = [ 0,0,0,0.16 ]; g1 = [ 0,0 ];
    f2 = [ 0.2,-0.26,0.23,0.22 ]; g2 = [ 0,1.6 ];
    f3 = [ -0.15,0.28,0.26,0.24 ]; g3 = [ 0,0.44 ];
    f4 = [ 0.85,0.04,-0.04,0.85 ]; g4 = [ 0,1.6 ];
    xy = [ 0,0 ];
    for (n = 0, n<2e6, ++n,
      r = u(100);
      xy = r<=1?((f1**xy)+=g1):
           r<=8?((f2**xy)+=g2):
           r<=15?((f3**xy)+=g3):
           ((f4**xy)+=g4);
      uv = xy*200 + [ 480,0 ];
      uv[1][1] = h - uv[1][1];
      I(uv) = 0.7*I(uv) + 0.3*255;
    )"}
  -r 40%,40%,1,1,2

And here is the rendering generated by this function:

Barnsley Fern Fig.5.4.5: Fractal “Barnsley fern“, rendered by G’MIC.

6. Overall project improvements

All filters presented throughout this article constitute only the visible part of the G’MIC iceberg. They are in fact the result of many developments and improvements made “under the hood”, i.e., directly on the code of the G’MIC script language interpreter. This interpreter defines the basic language used to write all G’MIC filters and commands available to users. Over the past year, a lot of work has been done to improve the performances and the capabilities of this interpreter:

  • The mathematical expressions evaluator has been considerably enriched and optimized, with more functions available (especially for matrix calculus), the support of strings, the introduction of const variables for faster evaluation, the ability to write variadic macros, to allocate dynamic buffers, and so on.

  • New optimizations have been also introduced in the CImg library, including the parallelization of new functions (via the use of OpenMP). This C++ library provides the implementations of the “critical” image processing algorithms and its optimization has a direct impact on the performance of G’MIC (in this respect, note that CImg is also released with a major version 2.0).

  • Compiling G’MIC on Windows now uses a more recent version of g++ (6.2 rather than 4.5), with the help of Sylvie Alexandre. This has actually a huge impact on the performances of the compiled executables: some filters run up to 60 times faster than with the previous binaries (this is the case for example, with the Deformations / Conformal Maps filter, discussed in section 5.2).

  • The support of large .tiff images (format BigTIFF, with files that can be larger than 4Gb) is now enabled (read and write), as it is for 64-bit floating-point TIFF images

  • The 3D rendering engine built into G’MIC has also been slightly improved, with the support for bump mapping. No filter currently uses this feature, but we never know, and prepare ourselves for the future!

    Bump mapping Fig.6.1: Comparison of 3D textured rendering with (right) and without “Bump mapping” (left).

  • And as it is always good to relax after a hard day’s work, we added the game of Connect Four to G’MIC :). It can be launched via the shell command $ gmic -x_connect4 or via the plug-in filter “Various / Games & demos / Connect-4“. Note that it is even possible to play against the computer, which has a decent but not unbeatable skill (the very simple AI uses the Minimax algorithm with a two-level decision tree).

    Connect four Fig.6.2: The game of “Connect Four“, as playable in G’MIC.

Finally, let us mention the undergoing redesign work of the G’MIC Online web service, with a beta version already available for testing. This re-development of the site, done by Christophe Couronne and Véronique Robert (both members of the GREYC laboratory), has been designed to better adapt to mobile devices. The first tests are more than encouraging. Feel free to experiment and share your impressions!

7. What to remember?

First, the version 2.0 of G’MIC is clearly an important step in the project life, and the recent improvements are promising for the future developments. It seems that the number of users are increasing (and they are apparently satisfied!), and we hope that this will encourage open-source software developers to integrate our new G’MIC-Qt interface as a plug-in for their own software. In particular, we are hopeful to see the new G’MIC in action under Krita soon, this would be already a great step!

Second, G’MIC continues to be an active project, and evolve through meetings and discussions with members of artists and photographers communities (particularly those who populate the forums and IRC of pixls.us and GimpChat). You will likely able to find us there if you need more information, or just if you want to discuss things related to (open-source) image processing.

And while waiting for a future hypothetical article about a future release of G’MIC, you can always follow the day-after-day progress of the project via our Twitter feed.

Until then, long live open-source image processing!


Credit: Unless explicitly stated, the various non-synthetic images that illustrate this post come from Pixabay.

CoreOS Fest 2017

CoreOS Fest 2017 happened earlier this month in San Francisco. I had the joy of attending this conference. With a vendor-organized conference there’s always the risk of it being mostly a thinly-veiled marketing excercise, but this didn’t prove to be the case: there was a good community and open-source vibe to it, probably because CoreOS itself is for the most part an open-source company.

Not bad for a view

Also fun was encountering a few old-time GNOME developers such as Matthew Garrett (now at Google) and Chris Kühl (who now runs kinvolk). It’s remarkable how good of a talent incubator the GNOME project is. Look at any reasonably successful project and chances are high you’ll find some (ex-)GNOME people.

Main room

I also had the pleasure of presenting the experiences and lessons learned related to introducing Kubernetes at Ticketmatic. Annotated slides and a video of the talk can be found here.

Making your company cloud‑native: the Ticketmatic story


Comments | More on rocketeer.be | @rubenv on Twitter

June 11, 2017

0.16.0RC1: Call to translators

We plan to release Stellarium 0.16.0 around June 21 (at the moment first release candidate was published for the testing of planetarium and translations checking).

This will an another major release with fixes of bugs and a few new important features - another one step to version 1.0. This version has many changes in the GUI and we added many new lines for translation. If you can assist with translation to any of the 140 languages which Stellarium supports, please go to Launchpad Translations and help us out: https://translations.launchpad.net/stellarium

If you can help translate description of sky cultures and landscapes on your language then we would be grateful to you for this. You need a create your branch, add 'description.YOUR-LANG-CODE.utf8' files from description.en.utf8 and translate it!

You can send translated description.YOUR-LANG-CODE.utf8 files to me for adding in Stellarium also.

Thank you!

June 09, 2017

Emacs: Typing dashes in html mode (update for Emacs 24)

Back in 2006, I wrote an article on making a modified copy of sgml-mode.el to make it possible to use double-dashed clauses -- like this -- in HTML without messing up auto-fill mode.

That worked, but the problem is that if you use your own copy of sgml-mode.el, you miss out on any other improvements to HTML and SGML mode. There have been some good ones, like smarter rewrap of paragraphs. I had previously tried lots of ways of customizing sgml-mode without actually replacing it, but never found a way.

Now, in emacs 24.5.1, I've found a easier way that seems to work. The annoying mis-indentation comes from the function sgml-comment-indent-new-line, which sets variables comment-start, comment-start-skip and comment-end and then calls comment-indent-new-line.

All I had to do was redefine sgml-comment-indent-new-line to call comment-indent-new-line without first defining the comment characters:

(defun sgml-comment-indent-new-line (&optional soft)
  (comment-indent-new-line soft))

Finding emacs source

I wondered if it might be better to call whatever underlying indent-new-line function comment-indent-new-line calls, or maybe just to call (newline-and-indent). But how to find the code of comment-indent-new-line?

Happily, describe-function (on C-h f, or if like me you use C-h for backspace, try F-1 h) tells you exactly what file defines a function, and it even gives you a link to click on to view the source. Wonderful!

It turned out just calling (newline-and-indent) wasn't enough, because sgml-comment-indent-new-line typically calls comment-indent-new-line when you've typed a space on the end of a line, and that space gets wrapped and then messes up indentation. But you can fix that by copying just a couple of lines from the source of comment-indent-new-line:

(defun sgml-comment-indent-new-line (&optional soft)
  (save-excursion (forward-char -1) (delete-horizontal-space))
  (delete-horizontal-space)
  (newline-and-indent))

That's a little longer than the other definition, but it's cleaner since comment-indent-new-line is doing all sorts of extra work you don't need if you're not handling comments. I'm not sure that both of the delete-horizontal-space lines are needed: the documentation for delete-horizontal-space says it deletes both forward and backward. But I have to assume they had a good reason for having both: maybe the (forward-char -1) is to guard against spurious spaces already having been inserted in the next line. I'm keeping it, to be safe.

June 08, 2017

G'MIC 2.0


G'MIC 2.0

A second breath for open-source image processing.

The IMAGE team of the research laboratory GREYC in Caen/France is pleased to announce the release of a new major version (numbered 2.0) of its project G’MIC: a generic, extensible, and open source framework for image processing. Here, we present the main advances made in the software since our last article. The new features presented here include the work carried out over the last twelve months (versions 2.0.0 and 1.7.x, for x varying from 2 to 9).



1. G’MIC: A brief overview

G’MIC is an open-source project started in August 2008, by the IMAGE team. This French research team specializes in the fields of algorithms and mathematics for image processing. G’MIC is distributed under the CeCILL license (which is GPL compatible) and is available for multiple platforms (GNU/Linux, MacOS and Windows). It provides a variety of user interfaces for manipulating generic image data, that is to say, 2D or 3D multispectral images (or sequences) with floating-point pixel values. This includes, of course, “classic” color images.

G'MIC logo Fig.1.1: Logo of the G’MIC project, an open-source framework for image processing, and its mascot Gmicky.

The popularity of G’MIC mostly comes from the plug-in it provides for GIMP (since 2009). To date, there are more than 480 different filters and effects to apply to your images, which considerably enlarges the list of image processing filters available by default in GIMP.

G’MIC also provides a powerful and autonomous command-line interface, which is complementary to the CLI tools you can find in the famous ImageMagick or GraphicsMagick projects. There is also a web service G’MIC Online, allowing to apply image processing effects directly from a browser. Other (but less well known) G’MIC-based interfaces exist: a webcam streaming tool ZArt, a plug-in for Krita, a subset of filters available in Photoflow, Blender or Natron… All these interfaces are based on the CImg and libgmic libraries, that are portable, thread-safe and multi-threaded, via the use of OpenMP.

G’MIC has more than 950 different and configurable processing functions, for a library of only 6.5Mio, representing a bit more than 180 kloc. The processing functions cover a wide spectrum of the image processing field, offering algorithms for geometric manipulations, colorimetric changes, image filtering (denoising and detail enhancement by spectral, variational, non-local methods, etc.), motion estimation and registration, display of primitives (2D or 3D mesh objects), edge detection, object segmentation, artistic rendering, etc. It is therefore a very generic tool for various uses, useful on the one hand for converting, visualizing and exploring image data, and on the other hand for designing complex image processing pipelines and algorithms (see these project slides for details).

2. A new versatile interface, based on Qt

One of the major new features of this version 2.0 is the re-implementation of the plug-in code, from scratch. The repository G’MIC-Qt developed by Sébastien (an experienced member of the team) is a Qt-based version of the plug-in interface, being as independent as possible of the widget API provided by GIMP.

G'MIC-Qt plug-in 1 Fig.2.1: Overview of version 2.0 of the G’MIC-Qt plug-in running for GIMP.

This has several interesting consequences:

  • The plug-in uses its own widgets (in Qt) which makes it possible to have a more flexible and customizable interface than with the GTK widgets used by the GIMP plug-in API: for instance, the preview window becomes resizable at will, manages zooming by mouse wheel, and can be freely moved to the left or to the right. A filter search engine by keywords has been added, as well as the possibility of choosing between a light or dark theme. The management of favorite filters has been also improved and the interface even offers a new mode for setting the visibility of the filters. Interface personalization is now a reality.

  • The plug-in also defines its own API, which is used to facilitate its integration in third party software (other than GIMP). In practice, a software developer has to write a single file host_software.cpp implementing the functions of the API to make the link between the plug-in and the host application. Currently, the file host_gimp.cpp does this for GIMP as a host. But there is now also a stand-alone version available (file host_none.cpp that runs this Qt interface in solo mode, from a shell (with command gmic_qt).

  • Boudewijn Rempt, project manager and developer of the marvelous painting software Krita, has also started writing such a file host_krita.cpp to make this “new generation” plug-in communicate with Krita. In the long term, this should replace the previous G’MIC plug-in implementation they made (currently distributed with Krita), which is aging and poses maintenance problems for developers.

Minimizing the integration effort for developers, sharing the G’MIC plug-in code between different applications, and offering a user interface that is as comfortable as possible, have been the main objectives of this complete redesign. As you can imagine, this rewriting required a long and sustained effort, and we can only hope that this will raise interest among other software developers, where having a consistent set of image processing filters could be useful (a file host_blender.cpp available soon ? We can dream!). The animation below illustrates some of the features offered by this new Qt-based interface.

G'MIC-Qt plug-in 2 Fig.2.2: The new G’MIC-Qt interface in action.

Note that the old plug-in code written in GTK was updated also to work with the new version 2.0 of G’MIC, but has fewer features and probably will not evolve anymore in the future, unlike the Qt version.

3. Easing the work of cartoonists…

One of G’MIC’s purposes is to offer more filters and functions to process images. And that is precisely something where we have not relaxed our efforts, despite the number of filters already available in the previous versions!

In particular, this version comes with new and improved filters to ease the colorization of line-art. Indeed, we had the chance to host the artist David Revoy for a few days at the lab. David is well known to lovers of art and free software by his multiple contributions in these fields (in particular, his web comic Pepper & Carrot is a must-read!). In collaboration with David, we worked on the design of an original automatic line-art coloring filter, named Smart Coloring.

Smart coloring 1 Fig.3.1: Use of the “Colorize line-art [smart coloring]“ filter in G’MIC.

When drawing comics, the colorization of line-art is carried out in two successive steps: The original drawing in gray levels (Fig.3.2.[1]) is first pre-colored with solid areas, i.e. by assigning a unique color to each region or distinct object in the drawing (Fig.3.2.[3]). In a second step, the colourist reworks this pre-coloring, adding shadows, lights and modifying the colorimetric ambiance, in order to obtain the final colorization result (Fig.3.2.[4]). Practically, flat coloring results in the creation of a new layer that contains only piecewise constant color zones, thus forming a colored partition of the plane. This layer is then merged with the original line-art to get the colored rendering (merging both in multiplication mode, typically).

Smart coloring 2 Fig.3.2: The different steps of a line-art coloring process (source: David Revoy).

Artists admit it themselves: flat coloring is a long and tedious process, requiring patience and precision. Classical tools available in digital painting or image editing software do not make this task easy. For example, even most filling tools (bucket fill) do not handle discontinuities in drawn lines very well (Fig.3.3.a), and even worse when lines are anti-aliased. It is then common for the artist to perform flat coloring by painting the colors manually with a brush on a separate layer (Fig.3.3.b), with all the precision problems that this supposes (especially around the contour lines, Fig.3.3.c). See also this link for more details.

Smart coloring 3 Fig.3.3: Classical problems encountered when doing flat coloring (source: David Revoy).

It may even happen that the artist decides to explicitly constrain his style of drawing, for instance by using aliased brushes in a higher resolution image, and/or by forcing himself to draw only connected contours, in order to ease the flat colorization work that has to be done afterwards.

The Smart Coloring filter developed in version 2.0 of G’MIC allows to automatically pre-color an input line-art without much work. First, it analyses the local geometry of the contour lines (estimating their normals and curvatures). Second, it (virtually) does contour auto-completion using spline curves. This virtual closure allows then the algorithm to fill objects with disconnected contour plots. Besides, this filter has the advantage of being quite fast to compute and gives coloring results of similar quality to more expensive optimization techniques used in some proprietary software. This algorithm smoothly manages anti-aliased contour lines, and has two modes of colorization: by random colors (Fig.3.2.[2] and Fig.3.4) or guided by color markers placed beforehand by the user (Fig.3.5).

Smart coloring 4 Fig.3.4: Using the G’MICSmart Coloring“ filter in random color mode, for line-art colorization (source: David Revoy).

In “random” mode, the filter generates a piecewise constant layer that is very easy to recolor with correct hues afterwards. This layer indeed contains only flat color regions, and the classic bucket fill tool is effective here to quickly reassign a coherent color to each existing region synthesized by the algorithm.

In the user-guided markers mode, color spots placed by the user are extrapolated in such a way that it respects the geometry of the original drawing as much as possible, taking into account the discontinuities in the pencil lines, as this is clearly illustrated by the figure below:

Smart coloring 5 Fig.3.5: Using the G’MICSmart Coloring“ filter in user-guided color markers mode, for line-art colorization (source: David Revoy).

This innovative, flat coloring algorithm has been pre-published on HAL (in French): A semi-guided high-performance flat coloring algorithm for line-arts. Curious people could find there all the technical details of the algorithm used. The recurring discussions we had with David Revoy on the development of this filter enabled us to improve the algorithm step by step, until it became really usable in production. This method has been used successfully (and therefore validated) for the pre-colorization of the whole episode 22 of the webcomic Pepper & Carrot.

The wisest of you know that G’MIC already had a line-art colorization filter! True, but unfortunately it did not manage disconnected contour lines so well (such as the example in Fig.3.5), and could then require the user to place a large number of color spots to guide the algorithm properly. In practice, the performance of the new flat coloring algorithm is far superior.

And since it does not see any objection to anti-aliased lines, why not create ones? That is the purpose of another new filter “Repair / Smooth [antialias]“ able to add anti-aliasing to lines in cartoons that would have been originally drawn with aliased brushes.

Smooth [antialias] Fig.3.6: Filter “Smooth [antialias]“ smooths contours to reduce aliasing effect in cartoons (source: David Revoy).

4. …Not to forget the photographers!

“Colorizing drawings is nice, but my photos are already in color!”, kindly remarks the impatient photographer. Don’t be cruel! Many new filters related to the transformation and enhancement of photos have been also added in G’MIC 2.0. Let’s take a quick look of what we have.

4.1. CLUTs and colorimetric transformations

CLUTs (Color Lookup Tables) are functions for colorimetric transformations defined in the RGB cube: for each color (Rs,Gs,Bs) of a source image Is, a CLUT assigns a new color (Rd,Gd,Bd) transferred to the destination image Id at the same position. These processing functions may be truly arbitrary, thus very different effects can be obtained according to the different CLUTs used. Photographers are therefore generally fond of them (especially since these CLUTs are also a good way to simulate the color rendering of certain old films).

In practice, a CLUT is stored as a 3D volumetric color image (possibly “unwrapped” along the z = B axis to get a 2D version). This may quickly become cumbersome when several hundreds of CLUTs have to be managed. Fortunately, G’MIC has a quite efficient CLUT compression algorithm (already mentioned in a previous article), which has been improved version after version. So it was finally in a quite relax atmosphere that we added more than 60 new CLUT-based transformations in G’MIC, for a total of 359 CLUTs usable, all stored in a data file that does exceed 1.2 Mio. By the way, let us thank Pat David, Marc Roovers and Stuart Sowerby for their contributions to these color transformations.

CLUTs Fig.4.1.1: Some of the new CLUT-based transformations available in G’MIC (source: Pat David).

But what if you already have your own CLUT files and want to use them in GIMP? No problem ! The new filter “Film emulation / User-defined“ allows to apply such transformations from CLUT data file, with a partial support of files with extension .cube (CLUT file format proposed by Adobe, and encoded in ASCII o_O!).

And for the most demanding, who are not satisfied with the existing pre-defined CLUTs, we have designed a very versatile filter “Colors / Customize CLUT“, that allows the user to build their own custom CLUT from scratch: the user places colored keypoints in the RGB color cube and these markers are interpolated in 3D (according to a Delaunay triangulation) in order to rebuild a complete CLUT, i.e. a dense function in RGB. This is extremely flexible, as in the example below, where the filter has been used to change the colorimetric ambiance of a landscape, mainly altering the color of the sky. Of course, the synthesized CLUT can be saved as a file and reused later for other photographs, or even in other software supporting this type of color transformations (for example RawTherapee or Darktable).

Customize CLUT 1 Fig.4.1.2: Filter “Customize CLUT“ used to design a custom color transform in the RGB cube.
Customize CLUT 2 Fig.4.1.3: Result of the custom colorimetric transformation applied to a landscape.

To stay in the field of color manipulation, let us also mention the appearance of the filter “Colors / Retro fade“ which creates a “retro” rendering of an image with grain generated by successive averages of random quantizations of an input color image.

Retro fade Fig.4.1.4: Filter “Retro fade“ in the G’MIC plug-in.

4.2. Making the details pop out

Many photographers are looking for ways to process their digital photographs so as to bring out the smallest details of their images, sometimes even to exaggeration, and we can find some of them in the pixls.us forum. Looking at how they perform allowed us to add several new filters for detail and contrast enhancement in G’MIC. In particular, we can mention the filters “Artistic / Illustration look“ and “Artistic / Highlight bloom“, which are direct re-implementations of the tutorials and scripts written by Sébastien Guyader as well as the filter “Light & Shadows / Pop shadows“ suggested by Morgan Hardwood. Being immersed in such a community of photographers and cool guys always gives opportunities to implement interesting new effects!

Illustration look Fig.4.2.1: Filters “Illustration look“ and “Highlight bloom“ applied to a portrait image.

In the same vein, G’MIC gets its own implementation of the Multi-scale Retinex algorithm, something that was already present in GIMP, but here enriched with additional controls to improve the luminance consistency in images.

Retinex Fig.4.2.2: Filter “Retinex“ for improving luminance consistency.

Our friend and great contributor to G’MIC, Jérome Boulanger, also implemented and added a dehazing filter “Details / Dcp dehaze“ to attenuate the fog effect in photographs, based on the Dark Channel Prior algorithm. Setting the parameters of this filter is kinda hard, but the filter gives sometimes spectacular results.

DCP dehaze 1 DCP dehaze 2 Fig.4.2.3: Filter “DCP Dehaze“ to attenuate the fog effect.

And to finish with this subsection, let us mention the implementation in G’MIC of the Rolling Guidance algorithm, a method to simplify images that has become a key step used in many newly added filters. This was especially the case in this quite cool filter for image sharpening, available in “Details / Sharpen [texture]“. This filter works in two successive steps: First, the image is separated into a texture component + a color component, then the details of the texture component only are enhanced before the image is recomposed. This approach makes it possible to highlight all the small details of an image, while minimizing the undesired halos near the contours, a recurring problem happening with more classical sharpening methods (such as the well known Unsharp Mask).

Sharpen [texture] Fig.4.2.4: The “Sharpen [texture]“” filter shown for two different enhancement amplitudes.

4.3. Masking by color

As you may know, a lot of photograph retouching techniques require the creation of one or several “masks”, that is, the isolation of specific areas of an image to receive differentiated processing. For example, the very common technique of luminosity masks is a way to treat differently shadows and highlights in an image. G’MIC 2.0 introduces a new interesting filter “Colors / Color mask [interactive]“ that implements a relatively sophisticated algorithm (albeit computationally demanding) to help creating complex masks. This filter asks the user to hover the mouse over a few pixels that are representative of the region to keep. The algorithm learns in real time the corresponding set of colors or luminosities and deduces then the set of pixels that composes the mask for the whole image (using Principal Component Analysis on the RGB samples).

Once the mask has been generated by the filter, the user can easily modify the corresponding pixels with any type of processing. The example below illustrates the use of this filter to drastically change the color of a car

Color mask [interactive] Fig.4.3.1: Changing the color of a car, using the filter “Color mask [interactive]“.

It takes no more than a minute and a half to complete, as shown in the video below:

Fig.4.3.2: Changing the color of a car, using filter “Color mask [interactive]“ (video tutorial).

This other video exposes an identical technique to change the color of the sky in a landscape.

Fig.4.3.3: Changing the color of the sky in a landscape, using filter “Color mask [interactive]“ (video tutorial).

5. And for the others…

Since illustrators and photographers are now satisfied, let’s move on to some more exotic filters, recently added to G’MIC, with interesting outcomes!

5.1. Average and median of a series of images

Have you ever wondered how to easily estimate the average or median frame of a sequence of input images? The libre aficionado Pat David, creator of the site pixls.us often asked the question. First of all when he tried to denoise images by combining several shots of a same scene. Then he wanted to simulate a longer exposure time by averaging photographs taken successively. And finally, calculating averages of various kind of images for artistic purposes (for example, frames of music video clips, covers of Playboy magazine or celebrity portraits).

Hence, with his cooperation, we added new commands -median_files,-median_videos, -average_files and-average_videos to compute all these image features very easily using the CLI tool gmic. The example below shows the results obtained from a sub-sequence of the « Big Buck Bunny“ video. We have simply invoked the following commands from the Bash shell:

$ gmic -average_video bigbuckbunny.mp4 -normalize 0.255 -o average.jpg
$ gmic -median_video bigbuckbunny.mp4 -normalize 0.255 -o median.jpg
Big buck bunny 1 Fig.5.1.1: Sequence in the « Big Buck Bunny“ video, directed by the Blender foundation.
Big buck bunny 2 Fig.5.1.2: Result: Average image of the « Big Buck Bunny“ sequence above.
Big buck bunny 3 Fig.5.1.3: Result: Median image of the « Big Buck Bunny“ sequence above.

And to stay in the field of video processing, we can also mention the addition of the commands -morph_files and -morph_video that render temporal interpolations of video sequences, taking the estimated intra-frame object motion into account, thanks to a quite smart variational and multi-scale estimation algorithm.

The video below illustrates the rendering difference obtained for the retiming of a sequence using temporal interpolation, with (right) and without (left) motion estimation.

Fig.5.1.4: Video retiming using G’MIC temporal morphing technique.

5.2. Deformations and “Glitch Art”

Those who like to mistreat their images aggressively will be delighted to learn that a bunch of new image deformation and degradation effects have appeared in G’MIC.

First of all, the filter “Deformations / Conformal maps“ allows one to distort an image using conformal maps. These deformations have the property of preserving the angles locally, and are most often expressed as functions of complex numbers. In addition to playing with predefined deformations, this filter allows budding mathematicians to experiment with their own complex formulas.

Conformal maps Fig.5.2.1: Filter “Conformal maps“ applying a angle-preserving transformation to the image of Mona Lisa.

Fans of Glitch Art may also be concerned by several new filters whose rendering look like image encoding or compression artifacts. The effect “Degradations / Pixel sort“ sorts the pixels of a picture by row or by column according to different criteria and to possibly masked regions, as initially described on this page.

Pixel sort Fig.5.2.2: Filter “Pixel sort“ for rendering a kind of “Glitch Art” effect.

Degradations / /Pixel sort also has two little brothers, filters “Degradations / Flip & rotate blocks“ and “Degradations / Warp by intensity“. The first divides an image into blocks and allows to rotate or mirror them, potentially only for certain color characteristics (like hue or saturation, for instance).

Flip and rotate blocks Fig.5.2.3: Filter “Flip & rotate blocks“ applied to the hue only to obtain a “Glitch Art” effect.

The second locally deforms an image with more or less amplitude, according to its local geometry. Here again, this can lead to the generation of very strange images.

Warp by intensity Fig.5.2.4: Filter “Warp by intensity“ applied to the image of Mona Lisa (poor Mona!).

It should be noted that these filters were largely inspired by the Polyglitch plug-in, available for Paint.NET, and have been implemented after a suggestion from a friendly user (yes, yes, we try to listen to our most friendly users!).

5.3. Image simplification

What else do we have in store? A new image abstraction filter, Artistic / Sharp abstract, based on the Rolling Guidance algorithm mentioned before. This filter applies contour-preserving smoothing to an image, and its main consequence is to remove the texture. The figure below illustrates its use to generate several levels of abstraction of the same input image, at different smoothing scales.

Sharp abstract Fig.5.3.1: Creating abstractions of an image via the filter “Sharp abstract“.

In the same vein, G’MIC also gets a filter Artistic / Posterize which degrades an image to simulate posterization. Unlike the filter with same name available by default in GIMP (which mainly tries to reduce the number of colors, i.e. do color quantization), our version adds spatial simplification and filtering to approach a little more the rendering of old posters.

Posterize Fig.5.3.2: Filter “Posterize“ of G’MIC, compared to the filter with same name available by default in GIMP.

5.4. Other filters

If you still want more (and in this case one could say you are damn greedy!), we will end this section by discussing some of the new, but unclassifiable filters.

We start with the filter “Artistic / Diffusion tensors“, which displays a field of diffusion tensors, calculated from the structure tensors of an image (structure tensors are symmetric and positive definite matrices, classically used for estimating the local image geometry). To be quite honest, this feature had not been originally developed for an artistic purpose, but users of the plug-in came across it by chance and asked to make a GIMP filter from it. And yes, this is finally quite pretty, isn’t it?

Diffusion tensors Fig.5.4.1: Filter “Diffusion Tensors“ filter and its multitude of colored ellipses.

From a technical point of view, this filter was actually an opportunity to introduce new drawing features into the G’MIC mathematical evaluator, and it has now become quite easy to develop G’MIC scripts for rendering custom visualizations of various image data. This is what has been done for instance, with the command -display_quiver reimplemented from scratch, and which allows to generate this type of rendering:

-display_quiver Fig. 5.4.2: Rendering vector fields with the G’MIC command -display_quiver.

For lovers of textures, we can mention the apparition of two new fun effects: First, the “Patterns / Camouflage“ filter. As its name suggests, this filter produces a military camouflage texture.

Camouflage Fig. 5.4.3: Filter “Camouflage“, to be printed on your T-shirts to go unnoticed in parties!

Second, the filter “Patterns / Crystal background“ overlays several randomly colored polygons in order to synthesize a texture that vaguely looks like a crystal seen under a microscope. Pretty useful to quickly render colored image backgrounds.

Crystal background Fig.5.4.4: Filter “Crystal background“ in action.

And to end this long overview of new G’MIC filters developed since last year, let us mention “Rendering / Barnsley fern“. This filter renders the well-known Barnsley fern fractal. For curious people, note that the related algorithm is available on Rosetta Code, with even a code version written in the G’MIC script language, namely:

# Put this into a new file 'fern.gmic' and invoke it from the command line, like this:
# $ gmic fern.gmic -barnsley_fern
barnsley_fern :
  1024,2048
  -skip {"
      f1 = [ 0,0,0,0.16 ];           g1 = [ 0,0 ];
      f2 = [ 0.2,-0.26,0.23,0.22 ];  g2 = [ 0,1.6 ];
      f3 = [ -0.15,0.28,0.26,0.24 ]; g3 = [ 0,0.44 ];
      f4 = [ 0.85,0.04,-0.04,0.85 ]; g4 = [ 0,1.6 ];
      xy = [ 0,0 ];
      for (n = 0, n<2e6, ++n,
        r = u(100);
        xy = r<=1?((f1**xy)+=g1):
             r<=8?((f2**xy)+=g2):
             r<=15?((f3**xy)+=g3):
                   ((f4**xy)+=g4);
        uv = xy*200 + [ 480,0 ];
        uv[1] = h - uv[1];
        I(uv) = 0.7*I(uv) + 0.3*255;
      )"}
  -r 40%,40%,1,1,2

And here is the rendering generated by this function:

Barnsley Fern Fig.5.4.5: Fractal “Barnsley fern“, rendered by G’MIC.

6. Overall project improvements

All filters presented throughout this article constitute only the visible part of the G’MIC iceberg. They are in fact the result of many developments and improvements made “under the hood”, i.e., directly on the code of the G’MIC script language interpreter. This interpreter defines the basic language used to write all G’MIC filters and commands available to users. Over the past year, a lot of work has been done to improve the performances and the capabilities of this interpreter:

  • The mathematical expressions evaluator has been considerably enriched and optimized, with more functions available (especially for matrix calculus), the support of strings, the introduction of const variables for faster evaluation, the ability to write variadic macros, to allocate dynamic buffers, and so on.

  • New optimizations have been also introduced in the CImg library, including the parallelization of new functions (via the use of OpenMP). This C++ library provides the implementations of the “critical” image processing algorithms and its optimization has a direct impact on the performance of G’MIC (in this respect, note that CImg is also released with a major version 2.0).

  • Compiling G’MIC on Windows now uses a more recent version of g++ (6.2 rather than 4.5), with the help of Sylvie Alexandre. This has actually a huge impact on the performances of the compiled executables: some filters run up to 60 times faster than with the previous binaries (this is the case for example, with the Deformations / Conformal Maps filter, discussed in section 5.2).

  • The support of large .tiff images (format BigTIFF, with files that can be larger than 4Gb) is now enabled (read and write), as it is for 64-bit floating-point TIFF images

  • The 3D rendering engine built into G’MIC has also been slightly improved, with the support for bump mapping. No filter currently uses this feature, but we never know, and prepare ourselves for the future!

Bump mapping Fig.6.1: Comparison of 3D textured rendering with (right) and without “Bump mapping” (left).
  • And as it is always good to relax after a hard day’s work, we added the game of Connect Four to G’MIC :). It can be launched via the shell command $ gmic -x_connect4 or via the plug-in filter “Various / Games & demos / Connect-4“. Note that it is even possible to play against the computer, which has a decent but not unbeatable skill (the very simple AI uses the Minimax algorithm with a two-level decision tree).
Connect four Fig.6.2: The game of “Connect Four“, as playable in G’MIC.

Finally, let us mention the undergoing redesign work of the G’MIC Online web service, with a beta version already available for testing. This re-development of the site, done by Christophe Couronne and Véronique Robert (both members of the GREYC laboratory), has been designed to better adapt to mobile devices. The first tests are more than encouraging. Feel free to experiment and share your impressions!

7. What to remember?

First, the version 2.0 of G’MIC is clearly an important step in the project life, and the recent improvements are promising for the future developments. It seems that the number of users are increasing (and they are apparently satisfied!), and we hope that this will encourage open-source software developers to integrate our new G’MIC-Qt interface as a plug-in for their own software. In particular, we are hopeful to see the new G’MIC in action under Krita soon, this would be already a great step!

Second, G’MIC continues to be an active project, and evolve through meetings and discussions with members of artists and photographers communities (particularly those who populate the forums and IRC of pixls.us and GimpChat). You will likely able to find us there if you need more information, or just if you want to discuss things related to (open-source) image processing.

And while waiting for a future hypothetical article about a future release of G’MIC, you can always follow the day-after-day progress of the project via our Twitter feed.

Until then, long live open-source image processing!


Credit: Unless explicitly stated, the various non-synthetic images that illustrate this post come from Pixabay.

Propose a talk for Flock!

Propose a talk for Flock!

Flock 2017’s CFP is open!

We need your Flock session proposals!

This year’s Flock is more action-oriented compared to previous Flocks. The majority of session slots are hackfests and workshops; only one day (Tuesday the 29th) is devoted to traditional talks.

Calendar showing days of Flock - Tue Aug 29, Wed Aug 30, Thu Aug 31, Fri Sep 1

The registration system allows you to submit 4 different types of proposals:

  • Talk (30 min) – A traditional talk, 30-minute time slot.
  • Talk (60 min) – A traditional talk, 60-minute time slot.
  • Do-Session (120 min) – A 2-hour long hackfest or workshop.
  • Do-Session (120 min) – A 3-hour long hackfest or workshop.

There is no session proposal limit. Feel free to submit as many proposals as you have ideas for.

Our CFP ends June 15 so you have one week to get those awesome proposals in!

Submit your Flock session proposal now!

How to create a strong proposal

How can you ensure your proposal is sufficiently strong enough for acceptance into Flock? Here are some tips and guidelines:

Align your proposal to Fedora’s new mission statement.

Fedora’s mission statement was updated almost two months ago. The revised and final mission statement is:

Fedora creates an innovative platform for hardware, clouds, and containers that enables software developers and community members to build tailored solutions for their users.

If you can explain the connection between your session and this goal, you’ll make the proposal stronger. Even if you are not directly working on a hardware, cloud, or container effort, you can relate your session to the goal.

For example, say you’d like to propose a Fedora badges hackfest. Task the badges hackfest specifically with creating badges for activities associated with efforts aligned specifically with hardware, cloud, and container to strengthen it.

Make sure the folks relevant to your topic are involved.

If you want to propose a Fedora badges workshop, that’s totally cool. You might want talk to Marie Nordin or Masha Leonova, and see what their plans are, give them a heads up, and coordinate or even propose it together with one or both of them.

The committee reviewing proposals occasionally sees duplicate / overlapping topics proposed. Generally, the committee chooses the proposal that has the subject matter experts most involved in the topic. A weak proposal on a topic has no indication of involvement or coordination with subject matter experts most actively involved in a topic.

Make the audience for your topic clear.

Think about who you are giving your talk to or who you want to show up to your workshop or hackfest. If you’re proposing a Fedora Hubs hackfest, are there enough Pythonistas in Fedora to help? (Yes, yes, there are. 🙂 )

Tailor your content for your audience – while you may be able to get folks familiar with Python, they may not be familiar with Flask or how Fedora Hubs widgets work, so make sure your proposal notes this material will be covered.

General user talks are discouraged. This Flock will be focused on empowering Fedora contributors and actively getting stuff done, so make sure your audience is a subset of existing Fedora contributors.

Focus on taking or inspiring action.

A major focus of this year’s Flock is taking action, so talks that inspire action and hackfests / workshops where action will take place are going to be strong proposals.

Questions?

Feel free to ask on the flock-planning list if you have any questions. Or, if you have private concerns / questions, you can email flock-staff@fedoraproject.org.

The Flock planning committee is looking forward to seeing your proposals! 🙂

Submit your Flock session proposal now!

Save

June 06, 2017

HTML Email from Mutt

I know, I know. We use mailers like mutt because we don't believe in HTML mail and prefer plaintext. Me, too.

But every now and then a situation comes up where it would be useful to send something with emphasis. Or maybe you need to highlight changes in something. For whatever reason, every now and then I wish I had a way to send HTML mail.

I struggled with that way back, never did find a way, and ended up writing a Python script, htmlmail.py to send an HTML page, including images, as email.

Sending HTML Email

But just recently I found a neat mutt hack. It turns out it's quite easy to send HTML mail.

First, edit the HTML source in your usual mutt message editor (or compose the HTML some other way, and insert the file). Note: if there's any quoted text, you'll have to put a <pre> around it, or otherwise turn it into something that will display nicely in HTML.

Write the file and exit the editor. Then, in the Compose menu, type Ctrl-T to edit the attachment type. Change the type from text/plain to text/html.

That's it! Send it, and it will arrive looking like a regular HTML email, just as if you'd used one of them newfangled gooey mail clients. (No inline images, though.)

Viewing HTML Email

Finding out how easy that was made me wonder why the other direction isn't easier. Of course, I have my mailcap set up so that mutt uses lynx automatically to view HTML email:

text/html; lynx -dump %s; nametemplate=%s.html; copiousoutput

Lynx handles things like paragraph breaks and does in okay job of showing links; but it completely drops all emphasis, like bold, italic, headers, and colors. My terminal can display all those styles just fine. I've also tried links, elinks, and w3m, but none of them seem to be able to handle any text styling. Some of them will do bold if you run them interactively, but none of them do italic or colors, and none of them will do bold with -dump, even if you tell them what terminal type you want to use. Why is that so hard?

I never did find a solution, but it's worth noting some useful sites I found along the way. Like tips for testing bold, italics etc. in a terminal:, and for testing whether the terminal supports italics, which gave me these useful shell functions:

echo -e "\e[1mbold\e[0m"
echo -e "\e[3mitalic\e[0m"
echo -e "\e[4munderline\e[0m"
echo -e "\e[9mstrikethrough\e[0m"
echo -e "\e[31mHello World\e[0m"
echo -e "\x1B[31mHello World\e[0m"

ansi()          { echo -e "\e[${1}m${*:2}\e[0m"; }
bold()          { ansi 1 "$@"; }
italic()        { ansi 3 "$@"; }
underline()     { ansi 4 "$@"; }
strikethrough() { ansi 9 "$@"; }
red()           { ansi 31 "$@"; }

And in testing, I found that a lot of fonts didn't offer italics. One that does is Terminus, so if your normal font doesn't, you can run a terminal with Terminus: xterm -fn '-*-terminus-bold-*-*-*-20-*-*-*-*-*-*-*'

Not that it matters since none of the text-mode browsers offer italic anyway. But maybe you'll find some other use for italic in a terminal.

June 02, 2017

darktable 2.2.5 released

we're proud to announce the fifth bugfix release for the 2.2 series of darktable, 2.2.5!

the github release is here: https://github.com/darktable-org/darktable/releases/tag/release-2.2.5.

as always, please don't use the autogenerated tarball provided by github, but only our tar.xz. the checksum is:

    $ sha256sum darktable-2.2.5.tar.xz
    e303a42b33f78eb1f48d3b36d1df46f30873df4c5a7b49605314f61c49fbf281  darktable-2.2.5.tar.xz
    $ sha256sum darktable-2.2.5.dmg
    f6e8601fca9a08d988dc939484d03e137c16dface48351ef523b5e0bbbaecf18  darktable-2.2.5.dmg

Important note: to make sure that darktable can keep on supporting the raw file format for your camera, please help us by visiting https://raw.pixls.us/ and making sure that we have the full raw sample set for your camera under CC0 license!

and the changelog as compared to 2.2.4 can be found below.

New features:

  • When appending EXIF data to an exported image, do not fail if reading of EXIF from the original file fails
  • Support XYZ as proofing profile
  • Clear DerivedFrom from XMP before writing it
  • bauhaus: when using soft bounds, keep slider step constant

Bugfixes:

  • Some GCC7 build fixes
  • cmstest: fix crash when missing XRandR extension.
  • Fix crash in Lua libs when collapsing libs
  • Mac packaging: some fixes
  • RawSpeed: TiffIFD: avoid double-free
  • Fix a few alloc-dealloc mismatches

Base Support:

  • Canon EOS 77D
  • Canon EOS 9000D
  • Nikon D500 (14bit-uncompressed, 12bit-uncompressed)
  • Nikon D5600 (12bit-compressed, 12bit-uncompressed, 14bit-compressed, 14bit-uncompressed)
  • Panasonic DC-FZ82 (4:3)
  • Panasonic DMC-FZ80 (4:3)
  • Panasonic DMC-FZ85 (4:3)
  • Panasonic DC-GH5 (4:3)

White Balance Presets:

  • Pentax K-3 II

Noise Profiles:

  • Nikon D500
  • Panasonic DMC-FZ300
  • Panasonic DMC-LX100
  • Pentax K-70
  • Sony ILCE-5000

June 01, 2017

Tiger Salamander Larvae

[Tiger salamander with gills] [Tiger salamander with gills] I got a tip that there were tiger salamanders with gills swimming around below Los Alamos reservoir, so I had to go see for myself.

They're fabulous! Four to five inch salamanders with flattened tails and huge frilly gills behind their heads -- dozens of them, so many the pond is thick with them. Plenty of them are hanging out in the shallows or just below the surface of the water, obligingly posing for photos.

I had stupidly brought only the pocket camera, not the DSLR -- and then the camera's battery turned out to be low -- so I was sparing with camera, but even so I was pleased at how well they came out, with the camera mostly managing to focus on the salamanders rather than (as I had feared) the surface of the murky water. I may go back soon with the DSLR. It's an easy, pleasant hike.

Photos: Tiger Salamander larvae.