Quantcast
Channel: Richard Geldreich's Blog
Viewing all 302 articles
Browse latest View live
↧

RDO ETC1 compression examples

October 23, 2016, 10:58 am
$
0
0
I've compressed the kodak test images using the prototype RDO ETC1 compressor I've been working on recently at various settings. You can download a .7z archive containing the RDO compressed .KTX files and unpacked PNG's here. The .KTX files can be loaded using the Mali Texture Compression Tool (v4.3.0).

Here are the unpacked images for 512 endpoints and 1024 selectors (1.65 average bits/texel vs. 2.85 average bits/texel for non-RDO ETC1):

























Non-RDO:
best_luma_psnr: Avg: 40.009226, Std Dev: 2.154732, Min: 35.193684, Max: 42.750275, Mean: 41.113007
best_luma_ssim: Avg: 0.983419, Std Dev: 0.002109, Min: 0.980131, Max: 0.989254, Mean: 0.983190
best_bits_per_texel: Avg: 2.851078, Std Dev: 0.341672, Min: 2.184774, Max: 3.482361, Mean: 2.822876
best_orig_size: Avg: 196676.000000, Std Dev: 0.000000, Min: 196676.000000, Max: 196676.000000, Mean: 196676.000000
best_compressed_size: Avg: 140136.166667, Std Dev: 16793.846305, Min: 107386.000000, Max: 171165.000000, Mean: 138750.000000

RDO (#endpoints_#selectors):

512_256:
rdo_luma_psnr: Avg: 31.638530, Std Dev: 2.891301, Min: 25.210732, Max: 35.657692, Mean: 33.023266
rdo_luma_ssim: Avg: 0.903939, Std Dev: 0.022998, Min: 0.839709, Max: 0.941335, Mean: 0.902615
rdo_bits_per_texel: Avg: 1.478541, Std Dev: 0.211604, Min: 1.075765, Max: 1.888489, Mean: 1.453206

512_512:
rdo_luma_psnr: Avg: 32.549770, Std Dev: 2.950959, Min: 25.927277, Max: 36.671211, Mean: 34.135223
rdo_luma_ssim: Avg: 0.916562, Std Dev: 0.020127, Min: 0.860491, Max: 0.950293, Mean: 0.915359
rdo_bits_per_texel: Avg: 1.555512, Std Dev: 0.211616, Min: 1.142314, Max: 1.969767, Mean: 1.533732

512_1024:
rdo_luma_psnr: Avg: 33.600601, Std Dev: 2.981399, Min: 26.842752, Max: 37.809361, Mean: 35.187038
rdo_luma_ssim: Avg: 0.928182, Std Dev: 0.017318, Min: 0.879742, Max: 0.957868, Mean: 0.926356
rdo_bits_per_texel: Avg: 1.648000, Std Dev: 0.208101, Min: 1.249207, Max: 2.055928, Mean: 1.623047

512_2048:
rdo_luma_psnr: Avg: 34.828563, Std Dev: 2.959008, Min: 27.984495, Max: 38.820568, Mean: 36.302998
rdo_luma_ssim: Avg: 0.939762, Std Dev: 0.014454, Min: 0.898490, Max: 0.964750, Mean: 0.938300
rdo_bits_per_texel: Avg: 1.765885, Std Dev: 0.208030, Min: 1.368184, Max: 2.174438, Mean: 1.735372

512_4096:
rdo_luma_psnr: Avg: 36.244860, Std Dev: 2.824295, Min: 29.513725, Max: 39.823002, Mean: 37.670746
rdo_luma_ssim: Avg: 0.951658, Std Dev: 0.011454, Min: 0.918562, Max: 0.971457, Mean: 0.950959
rdo_bits_per_texel: Avg: 1.924732, Std Dev: 0.210003, Min: 1.535360, Max: 2.343709, Mean: 1.893290

1024_4096:
rdo_luma_psnr: Avg: 36.375379, Std Dev: 2.881440, Min: 29.531380, Max: 40.141788, Mean: 37.697235
rdo_luma_ssim: Avg: 0.952464, Std Dev: 0.011512, Min: 0.918884, Max: 0.972384, Mean: 0.951676
rdo_bits_per_texel: Avg: 1.992114, Std Dev: 0.220525, Min: 1.569580, Max: 2.418762, Mean: 1.949666

↧
Search

Another little note about the Halo Wars engine

November 28, 2016, 3:54 pm
$
0
0
There's still a lot of misunderstanding out there about where the Halo Wars engine technology came from. Starting in very early 2005 the HW team wrote a new engine pretty much from scratch. The Age3 code was only single threaded, didn't use SIMD, and consumed huge amounts of RAM. (Age3 used over 32MB just for UTF16 strings - not good for a console game!) The "Bang!" engine ran at ~7Hz and took around three to five minutes to load on the early Xbox 360 devkits.

Colt McAnlis (now Google), Billy Khan (now at Id Software) and I wrote the entire Xbox 360-only renderer almost from scratch. We started out with Age3's particle renderer and my "wrench" demo deferred shading engine for SM 2.0 hardware. Ensemble Studios basically gave us a blank check to do whatever we wanted on Xbox 360. (What good times!)

Age3's particle engine (written partially or mostly by Graham Devine, now at Magic Leap) was so good that the artists refused to allow us to rewrite it. Billy and I threaded it by converting it into jobs, and we SIMD'ified all the key loops using Altivec ops. We also offloaded as many computations as we could into vertex/pixel shaders, to cut down on the very high CPU cost of the original code.

The Halo Wars particle engine would have ran circles around Age3's (once ported back to x86).

Please don't get me wrong, Age3 was a beautiful and fun game, and I loved working on it. The team was super easy and pleasant to work with. Just remember that Halo Wars was created by a very different team with different goals. We had some pretty awesome goals for the next Halo Wars, but the studio was shut down.

↧
↧

Why Age3 used low poly skinned meshes

November 28, 2016, 4:16 pm
$
0
0
Age3 used CPU skinning of relatively low poly models (even in "high" model mode). To help improve this technical design misstep made by the Age3 team (before I joined the team near the end of production) I rewrote the skinning code to be multithreaded. Unfortunately, by the time I came on board the artists had already created a ton of low poly skinned meshes.

I also built the skinning DLL with Intel's compiler, so I was able to easily rewrite all the skinning code using SSE1/2 ops using compiler intrinsics. Back in those days MSVC's support for vector intrinsics was weaker than Intel's compiler. (I'm also the developer to blame for Age3's SSE requirement, which bit some owners of very early AMD processors who otherwise could have played the title at low frame rates.)

Anyhow, I mention this because if you play Age3 today, like on a 4k monitor, the game's terrain and other effects hold up pretty well. Except the skinned character models look terribly low poly by comparison. On Halo Wars I used GPU skinning, instanced rendering, and I heavily jobified the animation system.
↧

"The Ballad of the Green Beret"

December 10, 2016, 1:26 pm
$
0
0
I heard this playing at the local Pagliacci's recently, and I realized this is one of the tunes my father used to play all the time. He was in Vietnam in I think '68 or '69, totally lost alone in the jungle, and was saved by a branch of the Special Forces called the Green Beret's.


↧

Visual Studio 2015's Busted Find Dialog

December 16, 2016, 10:31 pm
$
0
0
In Visual Studio 2015, Microsoft decided to wreck the Find dialog so it's perma-docked into the upper right-hand corner of the document. The dialog is too small, and the key icons (to enable case sensitive searching or searching for whole words) are too small and hard to use:


By comparison, here's 2010's:


The new find dialog in 2015 is an example of bad UI, and I'm not the only Windows C++ developer I know who seriously dislikes it.
↧
↧

End of year realization

December 31, 2016, 1:16 pm
$
0
0
I'm basically an artist who "paints" with code, and good debuggers are one of my brushes. Except, each "painting" involves a variable amount of mental and/or physical resources. The Steam Linux project was the hardest one I've ever done so far. Getting games on Linux and pushing the GL driver teams to go in the right directions was extremely difficult.

Thankfully, each project is a learning experience. Each time I get better at understanding myself.
↧

Pic of Matt Pritchard's shipped title award

January 3, 2017, 12:27 am
$
0
0
Pic taken during a late night debugging session. (I have one just like it.) This thing is so well done and high quality.

Ensemble Studios (Microsoft) was such a classy outfit. No other company I've worked at treated its employees as well as Ensemble's did (including Valve).


↧

I love ebikes

January 3, 2017, 1:39 am
$
0
0
Here's me ebiking to work at Boss Fight Entertainment in McKinney, TX, on a custom ebike built from parts acquired from ebikes.ca. In this video, I was only running at around 40v 20a, and the rest of the power was coming from peddling (me!). I eventually pushed the controller to its limit (100v), and switched from A123 LiFe cells to the much more "touchy" LiPo chemistry.


Dallas turned out to be a wonderfully ebike friendly area. There are endless miles and miles of golf cart trails, bike/walking trails, and virtually unused streets all over the Dallas metroplex. Also, I was almost invisible in Dallas as an ebiker. (Which is both good, and bad.)

↧
Search

The "Faster Zombies!" blog post

January 3, 2017, 7:26 pm
$
0
0
I'll never forget this post:

http://blogs.valvesoftware.com/linux/faster-zombies/

Gabe Newell himself wrote a lot of this post in front of me. From what I could tell, he seemed flabbergasted and annoyed that the team didn't immediately blog this info once we were solidly running faster in OpenGL vs. D3D. (Of course we should have blogged it ourselves! One of our missions as a team inside of Valve was to build a supportive community around our efforts.) From his perspective, it was big news that we were running faster on Linux vs. Windows. I personally suspect his social network didn't believe it was possible, and/or there was some deeper strategic business reason for blogging this info ASAP.

I stood behind Gabe and gave him all the data concerning GL vs. D3D performance while he typed the blog post in. I was (and still remain) extremely confident that our results were real. We conducted these tests as scientifically as we could, using two machines with the same hardware, configured in precisely the same way in the BIOS's, etc. NVidia and AMD were able to reproduce our results independently. Also, I could have easily made L4D2 on Linux GL run even faster vs. Windows, but we had other priorities like getting more Source1 games working, and helping Intel with their open source GL driver. From what I understand, Linux has some inherent advantages at the kernel level vs. Windows that impact driver performance.

Curiously and amusingly, another key developer on the team (who will remain unnamed as a professional courtesy) seemed to be terrified of being involved in this post when Gabe came over. When I stepped up to tell Gabe what to say, this developer looked totally relieved. I should have realized right there that I had a lot more influence that I suspected. Every time Gabe came over, it seemed like I was in the hot seat. Those were some challenging and amazing experiences!

A few weeks after this post went out, some very senior developers from Microsoft came by for a discrete visit. They loved our post, because it lit a fire underneath Microsoft's executives to get their act together and keep supporting Direct3D development. (Remember, at this point it was years since the last DirectX SDK release. The DirectX team was on life support.) Linux is obviously extremely influential.

It's perhaps hard to believe, but the Steam Linux effort made a significant impact inside of multiple corporations. It was a surprisingly influential project. Valve being deeply involved with Linux also gives the company a "worse case scenario" hedge vs. Microsoft. It's like a club held over MS's heads. They just need to keep spending the resources to keep their in-house Linux expertise in a healthy state.

I look back and now I see that I was totally not ready to handle the stress involved in this project. My ability and experience managing stress was very limited back then. I took on the lion's share of the graphics problems in the Source1 engine releases, I had to interact with the external driver teams and their managers/execs, help and present to external game developers about how to get good performance out of OpenGL, dodge patent attacks on my open source software, survive the rage of one corporation as I (naively!) helped their competitors implement support for a public GL extension, and also try to survive during the mass layoffs of 2013.

Unfortunately, these layoffs did impact the Linux team's morale and development efficiency. Even so, I did have a great time working at Valve overall. It was the most challenging and educational experience I've ever had. I highly doubt I could have gotten this kind of life changing experience at any other company.

↧
↧

ETC1 intermediate format progress

January 16, 2017, 6:42 pm
$
0
0
I've been working on support for the ETC1 format in Basis. The RDO front end class is done, and I'm writing the first ETC1 encoder+transcoder tonight. ETC1 is different enough from DXT1 that a redesign/rewrite is required.

Check out these histograms of the symbols the encoder sends to the transcoder (for kodim18).



↧

Basis ETC1 intermediate format support is now round-tripping

January 19, 2017, 12:50 am
$
0
0
We can now encode to our new compressed intermediate format for ETC1, and quickly transcode this compressed data to raw ETC1 bits. (Just like crunch's "CRN" format, but for ETC1.) This required many hundreds of compression and coding experiments to get here, and a bunch of work. The next major step is to port it to Linux and continue optimizing/tuning the encoder. We are freezing out file format for ETC1 within the next 2-3 weeks, and beyond that we'll just be tuning the encoder for higher quality output per bit.

For the first time, the backend of any encoder I've written supports explicit selector RDO. It basically tries to balance luma noise vs. bitrate. I've discovered a large number of improvements to crunch's basic approach. Each time I get tempted to try a completely different algorithm, I find another optimization.

Here's a random example of what selector RDO looks like on kodim18. At these quality settings, Basis ETC1 intermediate format gets 1.52 bits/texel, RDO compression (with the exact same quality level) on the ETC1 .KTX file+LZMA gets 1.83 bits/texel, and plain ETC1+LZMA is 3.33 bits/texel.

Delta selector RDO Enabled: 1.52 bits/texel Luma SSIM: .867811 (plain non-RDO ETC1 Luma SSIM is .981066)


Delta selector RDO Disabled: 1.61 bits/texel SSIM: .900380


RGB delta image (biased to 128):


The two textures above share the exact same endpoint/selector codebooks, the same per-macroblock mode values (flip and differential bits), and the same block color "endpoints". The delta selectors in the 2nd image were chosen to balance introduced noise vs. bitrate. I'm still tuning this algorithm but it's amazing to find improvements like this with so little code. This improvement and others like it will also be available in Basis's support for the DXT formats.

We also support an "ETC1S" mode, that doesn't support per-block tiling or 4:4:4 "individual" mode colors. It transcodes to standard ETC1 blocks. It gets 1.1 bits/texel, Luma SSIM .8616 using the same selector/endpoint codebook sizes. This mode has sometimes noticeable 4x4 block artifacts, but otherwise can perform extremely well in a rate-distortion sense vs. full ETC1 mode.


ETC1S mode has better behavior in a rate-distortion sense vs. full ETC1 mode, so there's still a lot of work to do.

The encoder's backend hasn't been tuned hardly at all yet, there are some missing optimization steps (that crunch used), and the selector codebook compression stage needs to be redone. The ETC1 per-block "mode" bits are also pretty expensive right now, so I need to implement a form of explicit "mode bit" RDO that purposely biases the mode bits in the front end to achieve better compression.

↧

Basis ETC1 support progress

January 24, 2017, 12:02 am
$
0
0
The front-end is written, now all of my effort has been on designing an efficient intermediate file format for ETC1 and a decent enough (but an improvable) encoder to go along with it. The idea is to prioritize the development of a powerful enough intermediate file format itself first, along with a "hopefully good enough" encoder. So I've been quickly trying a bunch of different RDO-driven (mostly back end) optimizations, to find some interesting ones to exploit later down the line. Because once the transcoder ships I can't change it for a long time, if ever.

The next step is to add one more major feature, port it to Linux, and ship it to our first customer.

↧

"Hybrid" supercompressed texture approach

January 24, 2017, 1:00 am
$
0
0
I think this is (vaguely to roughly - no idea?) similar to the new supercompressed texture algorithm John Brooks is working on, CEO of Blue Shift:

Instead of crunch-style top down clusterization (VQ) on the color endpoints and selector vectors with GPU format specific optimization and refinement stages, you could convert a pixel-wise codec (something like JPEG but hopefully better!) to directly output GPU block data. In ETC1, each subblock's colorspace line lies along the grayscale axis. The selector optimization/decision process is driven very strongly by the importance of luma vs. chroma error in ETC1. (And it's possible to trivially convert ETC1 data into high quality DXT1, so none of this info is specific to exclusively ETC1.)

The compressor can send "mode" bits to the decompression/transcoder system, depending on the importance of each bit of compressed data. The actual importance is related to a balance between bitrate and desired decompression/encoding time. If something is just way too expensive to do in the transcoder, then just do the computation in the encoder offline and send the results as some arithmetically coded bits with the right contexts.

And the encoder can make all key RDO decisions keeping in mind the destination GPU format (ETC1, DXT1, ASTC, etc.) and the transcoder's strengths/weaknesses.

It's also possible to combine crunch's clusterization+refinement algorithm to handle the chroma problem in this format. Use VQ on the luma/chroma endpoint information, and a pixel-wise approach on the luma to drive the selector decision process. I can imagine so many possibilities here!




↧
↧

Adaptogens

February 18, 2017, 11:34 am
$
0
0
I love herbal adaptogens, especially Rhodiola, and Ashwagandha.  Adaptogens are a rare, special breed of herb. Pretty much every game and software developer should at least understand what adaptogens do. How I wish I knew about adaptogens over the past 20+ years!

Effects of Adaptogens on the Central Nervous System and the Molecular Mechanisms Associated with Their Stress—Protective Activity

With adaptogens, my stress response feels totally different. Check out this graph:

An external file that holds a picture, illustration, etc. Object name is pharmaceuticals-03-00188-g001.jpg

Adaptogens are like "RadAway" for internal and/or external stress:


So far, the most powerful and reliable blend of adaptogens I've tried is "Adrenal Health - Daily Support" from Gaia. Their plain Rhodiola, Holy Basis, and Ashwagandha extracts are also very good. 

The downside to adaptogens: If you take too much, you're just not going to feel tired. If you *like* feeling tired, be cautious of dose. The slight CNS stimulating effect can be too energizing for some people, so go especially slow at first and only take a tiny amount only in the morning. If you just want to get your feet wet and play around with small amounts of adaptogens, try some Rhodiola extract in tea. So far, Ashwagandha feels the least stimulating to me.

Check out the anti-toxic effects of certain adaptogens. This is the kind of stuff James Bond surely takes every day:
"The adaptogens Eleutherococcus senticosus, Rhodiola rosea and Schisandra chinensis were reported to be safe in acute and subacute toxicity studies. Moreover, adaptogen induced state of non-specific resistance to highly toxic chemicals (e.g., chlorophos, phosphorus, cyclophosphane, strychnine, aniline, sodium nitrite, narcotics like sodium barbital, hexenal, chloralhydrate, benzene, acetone, ether, etc.) and microbes demonstrated in many pharmacological/toxicological studies [28], actually implies that they have an anti-toxic activity. For example, it was demonstrated that repeated administration of Rhodiola rosea extract during 10 consecutive days decreased LD50 of 40% ethanol in mice from 24.1 ml/kg to 55.2 ml/kg. It was also shown that salidroside shortened (from 100% to 19%) the duration of benzene induced sleep in rats"
What I wish I could find is a concise breakdown of the exact properties of each adaptogenic herb. For example, how stimulating is each one? How powerful is the cortisol lowing/normalizing effect of each, etc.

BTW - if you for some reason are freaked out by the concept of herbal medicine, the stimulating effect of caffeine feels much more powerful than any adaptogen I've tried. Also, adaptogens are not addictive like caffeine is. I have more consistent and reliable energy on adaptogens, and overall less energy when drinking caffeine.

↧

Interesting looking ETC1/2 encoder

February 26, 2017, 8:45 pm
↧
Search

Virtual global selector codebooks in Basis

March 5, 2017, 12:01 pm
$
0
0
Much of this information will be present in .basis's open source transcoder, so here's a little brain dump of how it works.

Selectors in DXT1 and ETC1 are 2-bits each. These values select which block color is used to represent each texel in a block. The block size in these formats is 4x4 texels, so each selector can be treated as a 16D vector. The uncompressed size of a selector vector is 32-bits (4*4*2).

One way of compressing these selector vectors is vector quantization (VQ). One problem with straightforward VQ is the expense of codebook storage. crunch stores selector codebooks in a compressed form, using order-1 delta compression on each vector's component, and it tries to rearrange the codebook entry order to minimize these deltas. With large codebooks the amount of bits needed to store the compressed selector vectors becomes prohibitive relative to the compressed texture data.

An alternative technique is to switch to a multi-level codebook scheme, where each .basis file has a "local" selector codebook which refers into a much larger constant "global" selector codebook. (This is somewhat inspired by Graham Devine'sROQ video file format used in Quake 3, which used multilevel codebooks.) Now we've got a serious memory problem, because the global (constant) selector codebook is going to require several megabytes of memory. A 1024^2 global selector codebook requires a 4MB table, which is undesirable on many platforms (i.e. WebGL).

.basis works around this problem by using a very small (256 entry) global selector vector codebook which is procedurally "amplified" using a series of small functions. These functions can rotate the vector by 90, 180, or 270 degrees, vertically flip the vector, change its contrast, add Gaussian noise to the vector, invert the vector, etc. It turns out that this method is surprisingly powerful and simple, and lends itself well to a hardware implementation.

To select a "virtual" selector codebook entry in this scheme, the encoder first selects a "seed" vector from the small global codebook (which requires 8-bits), then it specifies a series of control bits (typically 6-12) to select which procedural routines are used to modify the codebook entry. The control bits can be optionally arithmetically coded, or stored as-is. It's also possible to completely discard with the seed codebook and just use a PRNG (with some post processing) to generate the initial selector entries. In this case, the seed bits are used to prime the PRNG.

Function usage statistics in kodim18 (on each ETC1 block):

shift_x: Samples: 24576, Total: 12737.000000, Avg: 0.518270, Std Dev: 0.499666
shift_y: Samples: 24576, Total: 10472.000000, Avg: 0.426107, Std Dev: 0.494510
flip: Samples: 24576, Total: 10811.000000, Avg: 0.439901, Std Dev: 0.496375
rot: Samples: 24576, Total: 18679.000000, Avg: 0.760050, Std Dev: 0.427052
erode: Samples: 24576, Total: 6115.000000, Avg: 0.248820, Std Dev: 0.432329
dilate: Samples: 24576, Total: 7067.000000, Avg: 0.287557, Std Dev: 0.452623
high_pass: Samples: 24576, Total: 10076.000000, Avg: 0.409993, Std Dev: 0.491832
rand: Samples: 24576, Total: 12522.000000, Avg: 0.509521, Std Dev: 0.499909
div: Samples: 24576, Total: 10053.000000, Avg: 0.409058, Std Dev: 0.491660
shift: Samples: 24576, Total: 8016.000000, Avg: 0.326172, Std Dev: 0.468811
contrast: Samples: 24576, Total: 6080.000000, Avg: 0.247396, Std Dev: 0.431499
inv: Samples: 24576, Total: 12075.000000, Avg: 0.491333, Std Dev: 0.499925
median: Samples: 24576, Total: 7947.000000, Avg: 0.323364, Std Dev: 0.467760

rot's usage was ~76% because it was used 3/4 times. ~25% of the time the vector wasn't rotated. I've been continually surprised how easy it has been to find useful functions.

Here's a description of the current set of procedural functions in .basis:

  • shift_x/y: Shifts the block's selectors up or left by 1 row/column
  • flip: Vertical flip
  • rotate: Rotates by 0, 90, 180, or 270 degrees
  • erode: 3x3 erosion morphological  operator
  • dilate: 3x3 dilation morphological operator
  • high pass: 3x3 high-pass filter
  • rand: Adds Gaussian noise to the selectors, using the selectors themselves as a seed for the PRNG.
  • div: Selector remapping through table { 2, 0, 3, 1 }
  • shift: Adds 1 to the selectors with clamping
  • contrast: Boosts contrast of selectors by remapping them through 1 of 3 tables: { 0, 0, 3, 3 }, { 1, 1, 2, 2 }, { 1, 1, 3, 3 }
  • inv: Inverts the selectors
  • median: 3x3 selector median filter

The order that these functions are applied matters, and I'm still figuring out the optimal order. The control bits select which combination of the above functions is used to modify the selectors, and for a couple functions (like rot and contrast) multiple control bits are needed.

With a method like this it's possible to compress a selector vector down to 14-16 bits. Quality is extremely good. The biggest problem I'm working on solving now is how to efficiently search such large virtual codebooks during encoding without sacrificing too much quality or introducing artifacts. Full codebook searches are very slow.

↧

Virtual selector codebook example image

March 10, 2017, 12:06 am
$
0
0
I'm going to post some examples over the next few days. Note these examples are not .basis compressed images, instead they are just ETC1 compressed images where each block's selectors have been replaced by the "best" corresponding virtual selector codebook entry. Each block was processed independently, using a brute force search on a 20 core workstation.

I used an 8-bit seed dictionary and 11-bits to control the amplification functions, so the virtual CB size was 512K entries. The seed dictionary and functions were tuned on the set of photos, test images, and textures used to tune crunch. My current implementation seems to work best on photos and textures, and worst on synthetic images and high-contrast text.

In .basis, this method is currently only used to compressed selector codebooks, not entire images, so a brute force search over the entire virtual codebook isn't too insane. Also, basis supports a hybrid codebook mode, so it can select between virtual VB entries and "raw" entries depending on quality.

(Posting links so blogger doesn't resample the images.)

ETC1 compressed with selectors chosen from a 512K virtual codebook - .977149 Luma SSIM

ETC1 compressed - .996428 Luma SSIM

Original

Other ETC1 examples using vitual selector CB's (sorry no SSIM's, although I do have this data):





↧
↧

Nerd/Brogrammer spectrum

March 18, 2017, 12:38 pm
$
0
0
Okay, I've been watching Silicon Valley. This show is so realistic and exaggerated that I find it painful to watch at times (especially the first couple episodes), but it's also funny as hell. It really helps to put things into perspective about why I'm now a consultant and not "exclusive" to a single corporation anymore.


Some observations:

- Notice that the interpersonal relationships between basically all the characters are pretty toxic. Everyone seems to be exploiting everyone else in some way, and money/wealth is a large motivator to most characters.

- Look at the above frame. Where's the programmer in the middle in this series? The person who works out, is empathetic, loves to program, but isn't a total and complete asshole.

↧

Probiotic yogurt making

March 18, 2017, 9:00 pm
$
0
0
Just got back from a wonderful business trip to Portland Maine, visiting ForeFlight. Making more probiotic yogurt tonight because I ate up almost my entire stock on the trip. (It didn't help that we got stuck in a blizzard while there, but that turned out to be really fun.) The food in Portland is amazing!

The pot of boiling water is for sterilizing the growth medium, in this case 2% organic grassfed milk+raw sugar. After the milk is boiled (repastuerized) and cooled I inoculate it using a 10 strain probiotic blend from Safeway. I tried a bunch of probiotics before finding this particular brand, which seems magical for me. Without this extremely strong yogurt I have no idea how long it would have taken my gut to heal after the antibiotics I had to take in 2015.

Yogurt making like this is tricky. Early on, around 30% of my attempts failed in spectacular ways. These days my success rate is almost 100%. Sterilization of basically everything (including tools, spoons, etc.) over and over throughout the process is critical to success.



↧

Basis status

April 19, 2017, 5:29 pm
$
0
0
Just a small update. We've put like 99% of our effort into ETC1 and ETC1+DXT1 over the previous 5-6 months. Our ETC1 encoder supports RDO and an intermediate format, and has shipped on OSX/Linux/Windows. I've been modifying the ETC1 encoder to also support DXT1 over the previous few weeks.

Our ETC1 encoder was written almost from scratch. The next major step is to roll back all the improvements and things I've learned while implementing our ETC1 encoder back into our DXT-specific encoder. crunch's support for DXT has a bunch of deficiencies which hurt ratio (which Roy Eltham and Fabian Giesen have pointed out to me, and that I've been aware of for a few months since working on the new codebook generator for ETC1), which I'm definitely fixing in Basis.

↧
Viewing all 302 articles
Browse latest View live
Search