Author: Maya Posch

1882 Articles

Recreating Paintings By Teaching An AI To Paint

June 27, 2020 by 9 Comments

The Timecraft project by [Amy Zhao] and team members uses machine learning to figure out a way how an existing painting may have been originally been painted, stroke by stroke. In their paper titled ‘Painting Many Pasts: Synthesizing Time Lapse Videos of Paintings’, they describe how they trained a ML algorithm using existing time lapse videos of new paintings being created, allowing it to probabilistically generate the steps needed to recreate an already finished painting.

The probabilistic model is implemented using a convolutional neural network (CNN), with as output a time lapse video, spanning many minutes. In the paper they reference how they were inspired by artistic style transfer, where neural networks are used to generate works of art in a specific artist’s style, or to create mix-ups of different artists.

A lot of the complexity comes from the large variety of techniques and materials that are used in the creation of a painting, such as the exact brush used, the type of paint. Some existing approaches have focused on the the fine details here, including physics-based simulation of the paints and brush strokes. These come with significant caveats that Timecraft tried to avoid by going for a more high-level approach.

The time lapse videos that were generated during the experiment were evaluated through a survey performed via Amazon Mechanical Turk, with the 158 people who participated asked to compare the realism of the Timecraft videos versus that of the real time lapse videos. The results were that participants preferred the real videos, but would confuse the Timecraft videos for the real time lapse videos half the time.

Although perhaps not perfect yet, it does show how ML can be used to deduce how a work of art was constructed, and figure out the individual steps with some degree of accuracy.

Continue reading “Recreating Paintings By Teaching An AI To Paint” →

Teardown Of The Singaporean COVID-19 TraceTogether Token

June 25, 2020 by 63 Comments

A large part of fighting against the SARS-CoV-2 pandemic is the practice of contact tracing, where the whereabouts of an infected person can be traced and anyone who has been in contact with that person over the past days tested for COVID-19. While smartphone apps have been a popular choice for this kind of tracing, they come with a range of limitations, which is what the TraceTogether hardware token seeks to circumvent. Now [Sean “Xobs” Cross] has taken a look at the hardware that will be inside the token once it launches.

The Simmel COVID-19 contact tracer.

Recently, [Sean] along with [Andrew “bunnie” Huang] and a few others were asked by GovTech Singapore to review their TraceTogether hardware token proposal. At its core it’s similar to the Simmel contact tracing solution – on which both are also working – with contacts stored locally in the device, Bluetooth communication, and a runtime of a few months or longer on the non-rechargeable batteries.

The tracing protocol used is BlueTrace, which is an open application protocol aimed at digital contact tracing. It was developed by the Singaporean government, initially for use with their TraceTogether mobile app.

This smartphone app showed a number of issues. First is that Apple does not allow for iOS apps to use Bluetooth in the background, requiring the app to be active in the foreground to be useful. Apple has its own tracing protocol, but it does not cover the requirements for building a full contact graph, as [Andrew] covers in more detail. Finally, the app in general is not useful to those who do not have a recent (compatible) smartphone, or who do not have a smartphone at all.

A lot of the challenges in developing these devices lie in making them low-power, while still having the Bluetooth transceiver active often enough to be useful, as well as having enough space to store interactions and the temporary tokens that are used in the tracing protocol. As Simmel and the TraceTogether tokens become available over the coming months, it will be interesting to see how well these predictions worked out.

Creating A Custom ASIC With The First Open Source PDK

June 25, 2020 by 23 Comments

A process design kit (PDK) is a by now fairly standard part of any transformation of a new chip design into silicon. A PDK describes how a design maps to a foundry’s tools, which itself are described by a DRM, or design rule manual. The FOSSi foundation now reports on a new, open PDK project launched by Google and SkyWater Technology. Although the OpenPDK project has been around for a while, it is a closed and highly proprietary system, aimed at manufacturers and foundries.

The SkyWater Open Source PDK on Github is listed as a collaboration between Google and SkyWater Technology Foundry  to provide a fully open source PDK and related sources. This so that one can create manufacturable designs at the SkyWater foundry, that target the 130 nm node. Open tools here should mean a far lower cost of entry than is usually the case.

Although a quite old process node at this point (~19 years), it should nevertheless still be quite useful for a range of applications, especially those that merge digital and analog circuitry. SkyWater lists their SKY130 node technology stack as:

  • Support for internal 1.8V with 5.0V I/Os (operable at 2.5V)
  • 1 level of local interconnect
  • 5 levels of metal
  • Inductor-capable
  • High sheet rho poly resistor
  • Optional MiM capacitors
  • Includes SONOS shrunken cell
  • Supports 10V regulated supply
  • HV extended-drain NMOS and PMOS

It should be noted that use of this open source PDK is deemed experimental at this point in time, and should not be used for any commercial or otherwise sensitive applications.

Header image: Peellden/ CC BY-SA 3.0

AudioMoth: The Proverbial Moth On The Wall

June 25, 2020 by 12 Comments

Monitoring environmental sounds is perhaps not a common task, but much like with wildlife cameras, we could learn a lot from an always-on device listening in on Mother Nature. The AudioMoth is one of such devices. Although it has been around for a few years, it is notable for being an open platform, with the full Eagle-based hardware design files, BOM and firmware available, as well as NodeJS- and Electron-based utility software.

The AudioMoth is powered by a Silicon Labs EFM32-based MCU (EFM32WG980F256) with a Cortex-M4 core, 256 kB of Flash and 32 kB of SRAM. Using the onboard MEMS microphone it records both audible and ultrasonic frequencies that are written in uncompressed WAV format to the SD card. This makes it capable of capturing the sounds from bats in an area in addition to the calls of birds and other wildlife.

The AudioMoth has also a micro-sized, low-cost version called the μMoth, which shares the same features as the AudioMoth. This project is still in progress, with updates expected later this year.

Although the AudioMoth device can apparently be bought from sites like LabMaker for $74 at this point, it should be noted that the MCU used on the device is listed as ‘NRND’ (not recommended for new designs) by SiLabs, which may complicate building one in a number of years from now. Or at least you’ll have to substitute in a different microcontroller.

Regardless, it does seem like an interesting starting point for wildlife monitoring, whether one simply wants to build a device like this, or to use it as inspiration for one’s own design.

New Silq Programming Language Aims To Make Quantum Programming Easier

June 22, 2020 by 18 Comments

Fresh from ETH Zurich comes the new Silq programming language. They also have submitted a paper to the PLDI 2020 conference on why they feel that it is the best quantum programming language so far. Although it may be not common knowledge, the lack of usable general purpose quantum computers has not kept multiple teams from developing programming languages for such computer systems.

Microsoft’s Q# is a strong contender in this space, along with the older QCL language. The claims by the Silq team on exactly why their language is better appear to come down to it being ‘more high level’, and by supporting automatic (and safe) uncomputation. While the ‘high level’ aspect is suspect since Q# is most decidedly a high-level programming language, their uncomputation claim does at least have some merit.

Quantum algorithm with uncompute step.

Uncomputation is a concept in quantum programming, where one occasionally has to remove a few intermediate objects from the current state because they may cause quantum interference that would affect the resulting output. Normally, one would save the intermediate result to a register for this, then reset the state and continue. Which parts of the state to keep and what to uncompute is however not easily determined, as a quick glance at related answers over at the Quantum Computing StackExchange and Theoretical Computer Science might reveal.

The main question thus appears the validity of this claim about Silq being able to automatically determine what ‘garbage’ can be safely uncomputed, and what should be part of the quantum interference. We have all seen with languages like Java and C# how even with traditional computing something as simple as garbage collecting can go horribly wrong. Maybe we shouldn’t count our quantum chickens yet until this particular waveform has fully collapsed.

(Thanks to Qes)

Metasurface Design Methods Can Make LED Light Act More Like Lasers

June 18, 2020 by 33 Comments

Light-emitting diodes (LEDs) are not exactly new technology, but their use over time has evolved from rather dim replacements of incandescent signal lights in control panels to today’s home lighting. Although LEDs have the reputation of being power-efficient, there is still a lot of efficiency to be gained.

UC Santa Barbara researchers [Jonathan Schuller] and his team found that a large number of the photons that are generated never make it out of the LED. This means that the power that was used to generate these photons was essentially wasted. Ideally one would be able to have every single photon successfully make it out of the LED to contribute to the task of illuminating things.

In their paper titled ‘Unidirectional luminescence from InGaN/GaN quantum-well metasurfaces‘  (pre-publication Arxiv version) they describe the problem of photon emission in LEDs. Photons are normally radiated in all directions, causing a ‘spray’ of photons that can be guided somewhat by the LED’s packaging and other parameters. The challenge was thus to start at the beginning, having the LED emit as many photons in one direction as possible.

Their solution was the use of a metasurface-based design, consisting out of gallium nitride (GaN) nanorods on a sapphire substrate. These were embedded with indium gallium nitride (InGaN) quantum wells which emit the actual photons. According to one of the researchers, the idea is based on subwavelength antenna arrays already used with coherent light sources like lasers.

With experiments showing the simulated improvements, it seems that this research may lead to even brighter, more efficient LEDs before long if these findings translate to mass production.

(Thanks, Qes)

OmniBallot, Another Flawed Attempt At Online Voting

June 14, 2020 by 49 Comments

Although online voting in elections has been a contentious topic for decades already, it is during the current pandemic that it has seen significant more attention. Along with mail-based voting, it can be a crucial tool in keeping the world’s democratic nations running smoothly. This is where the OmniBallot software, produced by Democracy Live, comes into play, and its unfortunate unsuitability for this goal.

Despite already being used by multiple US jurisdictions for online voting, a study by MIT’s [Michael Specter] and University of Michigan researchers points out the flaws in this web-based platform. Their recommendations are to either avoid using OmniBallot completely, or to only use it for printing out a blank ballot that one then marks by hands and sends in by mail.

One of the issues with the software is that it by default creates the marked ballot PDF on the Democracy Live servers, instead of just on the user’s device. Another is that as a web-based platform it is hosted on Amazon Web Services (AWS), with JavaScript sources pulled from both CloudFlare and Google servers. Considering that the concern with electronic voting machines was that of unauthorized access at a polling station, it shouldn’t require a lengthy explanation to see this lack of end-to-end security with OmniBallot offers many potential attack surfaces.

When Ars Technica contacted Democracy Live for commentary on these findings, Democracy Live CEO [Bryan Finney] responded that “The report did not find any technical vulnerabilities in OmniBallot”. Since the researchers did not examine the OmniBallot code itself that is technically true, but misses the larger point of the lack of guarantee of every single voter’s device being secured, as well as every AWS, CloudFlare and Google instance involved in the voting process.

As a result, the recommended use of OmniBallot is to use it for the aforementioned printing out of blank ballots, to save half of the trip time of the usual mail-in voting.