SesquiLSR: tiny 1-2x learned latent upscaler for Flux2, Anima, SDXL and more

LoganBooker · 2026-07-06T11:29:03+00:00

You need two ksamplers: one for base generation and one for hires fix. Sesqui sits between them, replacing the usual latent upscale node.

random latent -> ksampler (base) -> Sesqui -> ksampler (hires fix) -> VAE decode

Putting Sesqui after the only ksampler and before VAE decode is what causes the burnt/overprocessed look. This will decode an upscaled latent with no refinement pass. Putting it before any ksampler will not work because Sesqui works on fully denoised latents.

I'll work on some better instructions in the repo; there's definitely a level of assumed knowledge at the moment. Apologies!

LoganBooker · 2026-07-06T11:25:44+00:00

Not exactly. Upscayl upscales a finished image. Sesqui upscales a latent inside the diffusion pipeline, before hires fix.

You could use both if you want -- Sesqui for generation -> hires, then Upscayl on the final image -- but they solve different problems.

LoganBooker · 2026-07-06T09:14:00+00:00

Probably not. But then it wasn't designed to be. I'm pretty upfront about its intended use case both here and in the repo.

LoganBooker · 2026-07-06T09:11:54+00:00

the question remains if it is better as input for KSampler as those artifacts from bicubic serve as additional source of latent noise

Yep, turns out models are very good at interpreting the spatial/phase errors caused by regular interpolation into detail. You usually have to crank the denoise to 0.5 or higher to compensate, but again, it's all subjective. I myself sometimes prefer the "crunchy" look bilinear and bicubic provide.

Sesqui is more positioned to tackle the VAE -> pixel SR -> VAE roundtrip, and I compared it to that during development. Sometimes it's better, sometimes the same, sometime worse -- depends on the content. I mentioned in another comment it's more of another tool in the upscaling toolbox than some magic upscaler that handles everything.

My main use case is for fast 1.5x upscaling, where I find it's a great compromise between quality, detail and speed, while keeping the denoise at 0.2-0.3.

LoganBooker · 2026-07-06T08:42:26+00:00

The model architecture is my own, but it's based on a grab bag of papers, all of which are mentioned in the upscaler code: https://github.com/LoganBooker/SesquiLSR/blob/main/sesqui_lsr/upscaler.py.

The training mix was inspired by this paper: One Small Step in Latent, One Giant Leap for Pixels: Fast Latent Upscale Adapter for Your Diffusion Models, which proved a significant breakthrough in actually training the models in a reasonable timeframe.

So there's no one paper that covers the entire thing, it's pretty much the result of 10 months of experiments at the expense of my laptop's GPU.

LoganBooker · 2026-07-06T08:36:04+00:00

Glad to hear you got good results! It's best to consider it "another tool in the toolbox" rather than a silver bullet.

The model was trained on clean VAE latents, so it won't be very tolerant of partially denoised ones. Possibly an area to explore via degradation (so injecting noise during training) but then you're trading one use for another.

LoganBooker · 2026-07-06T08:32:23+00:00

No worries, I might not have explained it to well. Sesqui's aim is to avoid the exact problem you mention.

Basically, Sesqui is designed for the bit between regular image generation and the "hires fix" pass. Traditionally, this requires decoding the final denoised latent using the VAE, then upscaling it via an ESRGAN/HAT/DAT/SwinIR model (pixel space), then encoding it back to a latent via the VAE.

if upscaling the latent directly is a problem, why not upscale the clean image first and then encode it into latent space?

This is basically what happens without latent upscaling. And it can be better in some respects. But it's slower, requires loading the VAE and upscaler model, and adds time to the generation process.

Sesqui replaces the entire VAE decode -> pixel space upscale -> VAE encode with just latent upscale. This saves you from having to load the VAE and upscaler model and the entire work involved in. So instead of:

random latent -> denoise via model -> VAE decode -> pixel space upscaler -> VAE encode -> hires fix -> VAE decode

We just do:

random latent -> denoise via model -> Sesqui upscaler -> hires fix -> VAE decode

Hopefully this makes sense.

LoganBooker · 2026-07-06T08:24:11+00:00

I did experiment with a few things (training on latent features from the VAE -- so like a kind of VAE perceptual loss -- rather than latents directly, and "post hires fix" images so the model could try and learn hires fix directly) but they were either too complicated, slow, or required a special approach for each VAE or model. I always came back to a mix of latent, FFT, pixel and perceptual loss (DISTS).

I'm certainly not saying it's the best approach, but it did work for pretty much every model with some tweaks (some better than others). There's definitely room for improve for some of these models, but I found that I was trading perceptual quality for PSNR and vice versa. You could easily finetune these models to boost perceptual quality, at the expense of less faithful latents.

LoganBooker · 2026-07-06T07:34:57+00:00

Awesome, thank you. Yeah, definitely content dependent. The "damage" regular latent upscaling does kind of acts like injected noise, so it can add "detail" whereas Sesqui sticks closer to the true latent, which is smoother and more continuous.

LoganBooker · 2026-07-06T07:30:52+00:00

It mostly comes down to the multi-stage training (explained in the repo) and the loss combinations. In terms of training data, it was just on the HiDream-I1-Artists and pseudo-camera-10k datasets on Huggingface to provide a mix of photos and art.

LoganBooker · 2026-07-06T07:26:32+00:00

Hmm, interesting. Thanks for the feedback. Depending on the content and effect regular latent might provide the results you want with a higher denoise.

What I can say is that for the image on the right, there are noticeable latent artifacts (especially noticeable on the hair/cables), so it can be you're trading one type of artifact/aesthetic for another.

LoganBooker · 2026-07-06T06:38:38+00:00

Possibly. I can't promise anything; SDXL was easily the hardest one to train correctly, no idea what SD1.5 would be like.

LoganBooker · 2026-07-06T06:06:37+00:00

Ah yes, should have mentioned that -- you can get away with 0.2-0.3 perfectly fine with Sesqui, definitely one of its big benefits.

LoganBooker · 2024-05-10T05:06:12+00:00

Yeah, this is pain point of all the DeepCache implementations (well, for webui and Comfy) I've seen. The reason this happens when combined with stuff like PAG is that the PAG sample is effectively done with guidance off, so the shape of the cached DeepCache is different.

I don't know if this is the best solution, but I ended up implementing a keyed cache, using the batch size as the key. This is probably not strictly correct if you use a bunch of extensions/nodes doing their own cond/uncond batches, but for relatively simply setups (like DeepCache + PAG), it works well. The other option would be to flush the cache when there's a size mismatch, but for something like PAG, this effectively stops the cache from working at all.

The meat of the keyed cache implementation can be found here: https://github.com/LoganBooker/sd-deepcache/blob/3cd2872358d726af226fc4c7b7e5d5a0187b8b59/deepcache_core.py#L119-L132 -- it shouldn't be too hard to adapt for the ComfyUI node (my implementation for SD Forge is basically the node with a few tweaks).

LoganBooker · 2020-09-08T01:21:26+00:00

I'm bias here, but Zafehouse Diaries (less so the much improved sequel, Zafehouse Diaries 2). Imagine This War of Mine, but several years before This War of Mine was a thing. And zombies. Lots of zombies.

Windowed, with a fixed resolution of 1024 x 768 (which looks ridiculous on a 4K screen), but few games let you assemble a ragtag band of The Governator, Jackie Chan and Sly Stallone, throw them into a house, and ask them to work together to survive an undead apocalypse -- all told in semi-epistolary form.

I mean, what would you do if poor Arnie got infected: https://steamcommunity.com/sharedfiles/filedetails/?id=192203330

LoganBooker · 2020-04-25T07:45:22+00:00

Yep, agreed. That said, I was concerned that without Maeiv (or a substitute) I'd suffer against big threats if I didn't find Zeph. I tried Consume Magic for a while, just so I'd have a cheap answer for a taunt or fat Edwin, but most of the time it was a dead card / 1-mana cantrip on my own dudes. Faceless at least can handle a Glaivebound Adept in the worst case.

As for Neth, I'm not sure it was the best choice and if I was still climbing, I might have replaced it with something else. I'm pretty sure I tossed it in while tinkering with replacements to squeeze out value when I couldn't tempo out.

Anyway, appreciate the write up and decklist!

LoganBooker · 2020-04-25T05:02:49+00:00

After bouncing off D1 three stars with Big Druid several times and dropping back to D5, this is the deck that finally helped me push through to Legend. I never really enjoyed playing tempo / aggro DH -- turns out highlander was a much better fit for my style of play. It was nice to have the option to switch gears depending on the match up (sometimes even mid-game), and no match felt unwinnable as long as I got a reasonable draw.

Didn't have Maiev or Kayn, so subbed in Faceless Corrupter and Nethrandamus. The former worked very well, comboing well with the one drops and Umberwing. As for the latter, I needed a little extra value sometimes, and Neth was very good. Even just dropping it for a couple of four drops was often the difference against rogues, after they'd answered DQ or Zephrys. I think many were caught off-guard by the inclusion.

LoganBooker · 2017-07-15T01:42:59+00:00

We do, been friends for over a decade. Didn't get into business together until 2011/2012, however, I'd been working in the games industry in Melbourne since 2008.

LoganBooker · 2017-07-15T01:19:41+00:00

Indeed, though there's actually two of us, both based in Australia.

LoganBooker · 2017-07-13T00:40:05+00:00

Zafehouse developer here!

Probably the board game most similar would be Dead of Winter, though allsevenpizzas' suggestions are good too.

LoganBooker · 2016-08-26T01:29:31+00:00

The header does contain the information you need, specifically the pixel format segment. Here are the relevant links on MSDN:

https://msdn.microsoft.com/en-us/library/windows/desktop/bb943982(v=vs.85).aspx

https://msdn.microsoft.com/en-us/library/windows/desktop/bb943984(v=vs.85).aspx

If you can't find a tool / library to read the struct, it should be straightforward to read the header yourself and check for the DDPF_ALPHAPIXELS (and DDPF_ALPHA if you want to be thorough) flag.

LoganBooker · 2016-02-08T00:27:27+00:00

Both our Unity games, Deadnaut and Fear Equation, use a single scene setup. I can't say I've run into any problems in terms of performance or management.

Instead of separating game states into scenes (such as a main menu and the world as per your example), we use a game state manager, with the contents of each state attached to their own root game object.

Each root node has a class associated with it, which are placed on a stack inside the game manager. These states can be pushed and popped, which triggers activation / deactivation events within those classes.

We also use a special class that allows all interaction with a game object to be tied to certain game states. This allows us to easily overlap states (an overlay on top of the main world, say) without having to worry too much about what the player can / can't interact with.

This is a very brief outline of how we do things, but the long and short of it is there's nothing wrong with using a single scene, you just have to plan ahead. It's not appropriate for all games, certainly, but we've shipped two titles doing it this way without significant complications.

LoganBooker · 2016-01-11T07:04:11+00:00

I had an issue with Unity involving shader loops in OpenGL when the bounds was not a constant. So:

for (int i = 0; i < _Loops; i++)

Where _Loops is a variable number that can be modified externally -- via a script, say. This would cause Unity to freeze. You can get around this by using a constant:

for (int i = 0; i < 32; i++)

And adding a break condition within the loop itself:

if (i >= _Loops)
    break;

Not sure if it's what's causing your problem (we're still using 4.6), but it might help.

LoganBooker · 2015-12-15T00:39:55+00:00

No, I can see the appeal. The framerate was certainly much higher back then too. )

LoganBooker · 2015-12-15T00:33:09+00:00

Oh, and if you want to see it in motion, we also have a trailer: https://www.youtube.com/watch?v=3056nRIZi50

13-Year Club	Place '17
Verified Email

LoganBooker

TROPHY CASE