Parametric Press Unravels The JPEG Format

February 14, 2023 by Dave Rowntree 5 Comments

This is the first we’ve heard of Parametric Press — a digital magazine with some deep dives into a variety of subjects (such as particle physics, “big data” and such) that have interactive elements or simulations of various types embedded within each story.

The first one that sprung up in our news feed is a piece by [Omar Shehata] on the humble JPEG image format. In it, he explains the how and why of the JPEG encoding process, allowing the reader to play with the various concepts along the way, in real time, within the browser.

RGB colour-space subsampling doesn’t affect each component to the same degree due to the human eye cone cell response. Also, the chroma components are much less affected than the luminance.

For those not familiar with the format, the first step (which is actually optional) to JPEG encoding is to transform the image from the RGB color space, into a YCbCr (luminance, chrominance) color space. Since the human eye is far more sensitive to luminance (brightness) differences than it is to Cb (chroma relative blueness) and Cr (chroma relative redness) differences, these latter two components can be subsampled by only storing a single value for each, in every 2×2 pixel matrix. JPEG allows other matrix sizes, but 2×2 is the most common.

This sets the scene for the clever bit, that comes next and allows more of that harder-to-perceive chroma information to be discarded. It’s fun to play with the chroma sub-sampling slider and see how the different colours are not equally affected, due to the relative sensitivities of the human eye cone cells.

Next, the three YCbCr components are treated independently to a discrete cosine transform and quantization. This transforms each 8×8 pixel block into 64 discrete spatial frequencies. The JPEG compression level (which you can change) affects how many of the upper-frequency components get discarded, and thus how much of the fine spatial detail gets discarded. This is the main source of JPEG image quality loss. Finally, the compressed blocks are delta encoded, where each subsequent block is coded as the difference from the previous one. Like chroma subsampling, this doesn’t offer any compression on its own but allows the subsequent run-length encoding to be more effective, giving more (lossless) compression. Finally, the whole lot is then Huffman compressed with a unique table stored in the JPEG header. So want to play with JPEGs some more? here’s the GitHub source.

If all of this theoretical stuff is a bit useless to you, perhaps you just want to decode some JPEGs, then here is a speedy library for just that.

An Open Hardware Eurorack Compatible Audio FPGA Front End

February 13, 2023 by Dave Rowntree 4 Comments

[Sebastian Holzapfel] has designed an audio frontend (eurorack-pmod) for FPGA-based audio applications, which is designed to fit into a standard Eurorack enclosure. The project, released under CERN Open-Hardware License V2, is designed in KiCAD using the AK4619VN four-channel audio codec by Asahi Kasei microdevices. (And guess what folks, there’s plenty of those in stock!) Continue reading “An Open Hardware Eurorack Compatible Audio FPGA Front End” →

GhostSCAD: Marrying OpenSCAD And Golang

February 12, 2023 by Dave Rowntree 18 Comments

It’s been at least a couple of months since we’ve seen a different 3D modeling language project, so here’s [Lukasz Janyst] with GhostSCAD: a take on creating OpenSCAD models, using the Go language as the front end, bringing all the delights this modern modular language has to offer (and a few of its own idiosyncrasies.) As [Lukasz] says in the blog, from a programmer’s viewpoint, openSCAD has a number of failings that make it not necessarily hard, just kinda annoying to work with, due to the way the geometry tree works. The OpenSCAD way of working ends up with the programmer requiring knowledge of the internal workings of sub-modules, in order to work at the top level (assembly) which is not an ideal situation from a code reuse perspective.

A programmer would describe this problem as “abstraction leakage” and it doesn’t make modular, reusable coding easy to do without a lot of extra work. [Lukasz] says regarding the example GhostSCAD project, that some parts were modeled in a way that knowledge was needed of some mounting points of sub-modules, but those sub-modules had no way to expose this information to the outside world. GhostSCAD enables the programmer to define parts that expose specific parameters to the world that can be queried, for example, to produce a joining part, or an exploded assembly diagram. These properties can be interpreted without the querying module having any knowledge of the internal structure of the thing it’s working with. GhostSCAD provides a Java3D-like API for defining the geometry tree, which may be familiar to some.

Continue reading “GhostSCAD: Marrying OpenSCAD And Golang” →

Directing Ambient Light For Some Extra Glow

February 11, 2023 by Dave Rowntree 17 Comments

[Yuichiro Morimoto] wanted to create a decorative lamp, one that wasn’t burdened with batteries or wires, but used just the ambient light in the room to create a directed glow effect. Using a coloured circular acrylic sheet, with a special coating (not specified) ambient light impinging on the surface is diffused toward the edge. This centre sheet is embedded in an opalescent sheet, which scatters the light from the center sheet, giving a pleasant glow, kind of akin to a solar corona. An additional diffuser cover sheet on the front covers over the edge to hide it, and further enhance the glow effect.

Details of the ‘special coating’ are scarce, with the coloured sheet described as a condenser plate. This clearly isn’t the same as diffuser plastic, as that cannot be seen through as clearly as some of the photographs show. So we’re a little stumped on this one! Please answer in the comments if you can, ahem, shed some light on this one!

When talking about ambient light, many people will think more along the lines of active lighting, for example, adaptive ambient light around a TV like this hack.

Continue reading “Directing Ambient Light For Some Extra Glow” →

Create Your RTL Simulations With KiCAD

February 6, 2023 by Dave Rowntree 4 Comments

[Bob Alexander] is in the process of designing a homebrew discrete TTL CPU, and wanted a way to enter schematics for digital simulations via a Verilog RTL flow. Since KiCAD is pretty good at handling hierarchical schematics, why not use that? [Bob] created a KiCAD plugin, KiCadVerilog allowing one to instantiate and wire up the circuits under consideration, and then throw the resulting Verilog file at your logic simulator of choice.

KiCadVerilog doesn’t do all the hard work though, as it only provides the structure and the wiring of the circuit. The actual guts of each TTL instance needs to be provided, and a reference to it is manually added to the schematic object fields. That’s a one-time deal, as you can re-use the component library once generated. Since TTL logic has been around for a little while, locating a suitable Verilog library for this is easy. Here’s ice-chips-verilog by [TimRudy] on GitHub for starters. It’s intended as a collection for Icestudio (which is also worth a look). Still, the Verilog code for many TTL series devices is presented ready for the taking, complete with individual test benches in case you need them.

Check out the project GitHub page for the module source code, and some more documentation about the design process.

We’ve seen many RTL hacks over the years, here’s an interesting way to generate a PCB layout with discrete logic, direct from the RTL.

Building A Fake Printer To Grab Screenshots Off The Parallel Port

February 3, 2023 by Dave Rowntree 36 Comments

[Tom Verbeure] recently found himself lamenting the need to take screen grabs from an Advantest R3273 spectrum analyzer with a phone camera, as the older gear requires you to either grab tables of data over an expensive GPIB interface card, or print them to paper. Then he realized, why not make a simple printer port add-on that looks like a printer, but sends the data over USB as a serial stream?

On the hardware side, the custom PCB (KiCAD project) is based on the Raspberry Pi Pico. Obvious form factor issues aside ([Tom] did revise the PCB to make it smaller) this is a shrewd move, as this is not a critical-path gadget so using the Pico as a USB-to-thing solution is a cost-effective way to get something working with minimal risk. One interesting design point was the use of the 74LVC161284 special function bus interface that handles the 5 V tolerance that the RP2040 lacks, whilst making the project compliant with IEEE-1284 — useful for the fussier instruments.

Using the service manual of the Sharp AP-PK11 copier/printer as a reference, [Tom] again, shows how to correctly use the chip, minimizing the design effort and scope for error. The complete project, with preliminary firmware and everything needed to build this thing, can be found on the project GitHub page. [Tom] does add a warning however that this project is still being worked on so adopters might wish to bear that in mind.

If you don’t own such fancy bench instrumentation, but grabbing screenshots from devices that don’t normally support it, is more your thing, then how about a tool to grab Game Boy screenshots?

Generating PAL Video With A Heavily Overclocked Pi Pico

January 24, 2023 by Dave Rowntree 19 Comments

Barely a week goes by without another hack blessing the RP2040 with a further interfacing superpower. This time it’s the turn of the humble PAL standard composite video interface. As many of us of at least a certain vintage will be familiar with, the Phase Alternate Line (PAL to friends) standard was used mainly in Europe (not France, they used SECAM like Russia, China, and co) and Australasia, and is a little different from the much earlier NTSC standard those in the US may fondly recollect. Anyway, [Fred] stresses that this hack isn’t for the faint-hearted, as the RP2040 needs one heck of an overclock (up to 312 MHz, some 241% over stock) to be able to pull off the needed amount of processing grunt. This is much more than yet another PIO hack.

The dual cores of the RP2040 are really being pushed here. The software is split into high and low-level functions, with the first core running rendering the various still images and video demos into a framebuffer. The second core runs in parallel and deals with all the nitty-gritty of formatting the frame buffer into a PAL-encoded signal, which is then sucked out by the DMA and pushed to the outside world via the PIO. There may be a few opportunities for speeding the code up even more, but [Fred] has clearly already done a huge amount of work there, just to get it working at all. The PIO code itself is very simple but is instructive as a good example of how to use multiple chained DMA channels to push data through the PIO at the fastest possible rate.

Continue reading “Generating PAL Video With A Heavily Overclocked Pi Pico” →