Converting V-Log LUTs to Standard: An Amateur Exploration of LUMIX, ISO, and Color Science

This exploration eventually evolved into an open-source project: t0saki/lumix-lut-converter. It is built with Python, uv, numpy.float64, and tetrahedral interpolation. The goal is not to “crack Panasonic’s color science,” but rather to turn the published, explainable math into a practical, reproducible tool.

This project happened to coincide with the release of GPT-5.6, so I also treated it as a personal test of the new model: the code and the initial draft of this article were written by GPT-5.6 Sol, revised by me and Fable 5, and finally polished by Gemini 3.1 Pro.

It all started with ISO 640

LUMIX’s Real Time LUT feature is fantastic: load a .cube or .vlt file into the camera, and you get highly stylized JPEGs straight out of camera. The catch is that many existing LUTs expect V-Log/V-Gamut input. When a LUT’s base Photo Style is set to V-Log, the S9’s minimum photo-mode ISO is locked at 640, whereas the Standard profile starts at ISO 100 (see the ISO section of the S9 Complete Guide).

For video production, the V-Log workflow makes perfect sense, but I primarily use Real Time LUTs for stills. When shooting indoors, using slow shutter speeds, or shooting wide open, an ISO 640 floor is more than just an annoying menu restriction. To achieve the same out-of-camera brightness, the V-Log workflow forces a faster shutter speed, feeding the sensor less light. This preserves highlight headroom but actively degrades the signal-to-noise ratio (SNR) in the RAW’s midtones and shadows.

So the initial question was quite simple:

Can a creative LUT that expects V-Log input be converted into a LUT that expects Standard input, allowing the camera to produce a visually similar out-of-camera look at ISO 100?

Initially, I believed a “lossless conversion” was achievable, but I later adjusted my goal to achieving visually close results. The technically accurate term for this process is remapping the LUT’s input base (base remapping). While known color transforms can be composed mathematically with high precision, irreversible data losses—like gamut compression, clipping that has already occurred, and the camera’s proprietary internal tone mapping—cannot magically be recovered by stacking another LUT on top.

Stage one: inverting the official Like709 LUT

The first reference point that came to mind was Panasonic’s official VLog_to_V709_forV35 LUT, which defines a technical mapping from V-Log/V-Gamut to V709. Let’s denote this technical transform as $T$ and the original creative LUT as $L$. The intuitive approach is to numerically solve for $T^{-1}$ and generate a new LUT designed for Like709 input:

To achieve this, I tasked GPT-5.6 Sol with writing KD-tree initial guesses, a bounded damped Gauss–Newton solver, tetrahedral interpolation, and Rec.709/CIELAB error checks. Numerically, this approach works: in the initial round of test shots, the native V-Log LUT and the inverted Like709 version looked remarkably similar.

Figure 1: All at ISO 640, 1/30 s, f/2.8. Left: V-Log + original creative LUT; middle: Like709 + numerically inverted LUT; right: Standard reference. All three shots utilized auto white balance (AWB), so this serves only as a visual sanity check, not a strict color-difference measurement.

This stage confirmed that “pre-composing a technical transform into a creative LUT” is feasible from an engineering standpoint, but it also exposed new challenges:

• The Like709 Photo Style is not Standard, and what I practically needed was Standard’s ISO 100 working range;
• The official V709 LUT contains ambiguities regarding legal vs. full-range interpretation;
• Once a 3D LUT introduces clipping or many-to-one mappings, its mathematical inverse is no longer universally unique;
• No matter how precise the numerical inversion is, it cannot prove that the camera’s internal Like709 profile perfectly matches this specific VariCam technical LUT.

Consequently, the Like709 route was relegated to a cross-validation tool rather than becoming the recommended solution.

Stage two: Standard isn’t published, so let’s “photograph” it

Next came a messier but seemingly more intuitive plan: display a comprehensive set of known color patches on a screen, photograph them in V-Log, Like709, and Standard, and train a model to learn the Standard → V-Log mapping directly from the resulting JPEGs.

The initial attempts were rocky. The first batch was shot using AWB, which shifts dynamically based on on-screen content. Fitting a model to that data meant it was learning not just the Photo Style differences, but also the camera’s per-shot AWB decisions. Similarly, adjusting exposure frame-by-frame “to avoid losing JPEG detail” inadvertently baked exposure variances into the model.

To make the experiment more rigorous, I had GPT-5.6 Sol generate a set of 4K SDR calibration frames in Python, which included:

• multi-step grayscale and single-channel ramps;
• RGB/CMY ramps;
• a regular 9×9×9 RGB cube;
• a few natural landscape images (used exclusively for validation, not training);
• machine-readable corner markers for automatic perspective correction and patch sampling.

There were some mundane detours along the way: opening the local viewer.html directly in a browser triggered file: origin restrictions, and the on-screen instruction text obscured one of the corner markers. After setting up a local server and fixing the layout, I shot the second batch at a locked 5500K with manual focus. The three Photo Styles shared identical exposure settings for the same chart, with adjustments made only between different chart pages as necessary.

Figure 2: After locating the four corner markers, the program computes a perspective transform and samples patches at the coordinates specified in the manifest. In the second batch, all 39 frames were localized successfully, yielding 3,552 paired samples.

The empirical fit was actually quite decent: on unclipped samples, the training set’s mean max-channel error was roughly $0.52/255$ with a 95th percentile (P95) of $1.19/255$. The independent grayscale validation set averaged about $2.80/255$ with a P95 of $8.28/255$.

But there is a crucial lesson here: a low fitting error does not mean the model has learned the correct underlying color science. It may simply have memorized, with high precision, the quirks of this specific camera, this exact QD-OLED screen, the 5500K white balance, that specific day’s exposure, the JPEG tone curve, and the analog gain differences between the two Photo Styles.

In short, while this empirical model is excellent for analyzing “what the camera actually did in that room,” it is unfit to be declared a universal Standard-inversion LUT across different scenes and camera bodies.

The turning point: stop fitting — Panasonic already published the key formulas

Around this time, @Jackchou00 reminded me that Panasonic has actually published the V-Log encoding function and the V-Gamut definitions. Rather than stuffing every variable into a black-box model, the standard colour space transform (CST) should be constructed from the published documentation first. Real-world shots should then be used to verify the unpublished residuals, not to substitute for math that is already publicly available.

That remark completely changed the project’s trajectory, serving as the single most important conceptual pivot in the whole exploration.

Panasonic’s V-Log / V-Gamut Reference Manual provides the V-Log OETF, which maps linear light $L$ to the V-Log code value $V$:

The same document also outlines V-Gamut’s primaries, the D65 white point, and the matrix required to convert between V-Gamut and linear BT.709. This means there is zero need to eyeball “a gray curve that kind of looks like V-Log”—the entire computation can be explicitly mapped out step by step:

1. Decode the Standard/sRGB code values to linear BT.709 RGB using the sRGB EOTF;
2. Convert linear BT.709 to V-Gamut using the official matrix;
3. Apply Panasonic’s V-Log OETF to obtain V-Log code values;
4. Finally, feed those values into the original V-Log creative LUT.

Figure 3: The analytic base remapping pipeline the project ultimately adopted. The first three steps form the technical adapter $F$, which is mathematically composed with the original creative LUT $L$ to generate a single 33-point in-camera LUT: $L_{\text{STD}}(x) = L\big(F(x)\big)$.

I chose sRGB over Adobe RGB here not because Adobe RGB is inherently “worse,” but because sRGB is simply more verifiable for this specific problem. sRGB shares its primaries and D65 white point with BT.709, allowing Panasonic’s official matrix to plug in seamlessly. Furthermore, LUMIX Lab, camera JPEGs, OS previewers, and web platforms consistently default to sRGB.

This also doesn’t mean I jumped to the assumption that “Panasonic’s Standard profile perfectly equals the textbook sRGB curve.” Standard’s internal tone curve, gamut mapping, and exact LUT insertion point remain unpublished by Panasonic. sRGB is simply the most explicit, compatible working model for aligning the LUT input with the JPEG processing chain.

What actually happens at ISO 640: RAW gives an interesting answer

Jackchou00 raised another hypothesis worth testing: V-Log’s ISO 640 might sit on roughly the same physical analog gain scale as a normal Photo Style’s ISO 100.

I shot a series of RAWs with identical aperture, shutter speed, and rated ISO (f/2.8, 1/30 s, ISO 640), changing only the Photo Style between V-Log and Standard. After subtracting the standard RAW black level of 128 and aggressively masking out clipped regions, the linear code-value ratio of Standard to V-Log looks like this:

Figure 4: All four Bayer channels hold remarkably steady at about 6.08×, yielding a pooled slope of 6.0848 (roughly 2.60 EV). Note: This compares RAW code-value responses only and should not be misread as a definitive teardown of the camera’s analog gain circuitry.

This result establishes at least one undeniable fact: ISO numbers cannot be directly compared without the context of their specific Photo Style. Seeing “ISO 640” in the menu does not mean V-Log and Standard are utilizing the same RAW code-value scale. Conversely, the RAW response of V-Log at ISO 640 aligns roughly with Standard at ISO 100–105. This also explains why V-Log’s “base floor of 640” cannot be naively interpreted as pushing a normal Photo Style up by $\log_2(640/100) \approx 2.68$ stops of pure analog gain.

For my practical stills workflow, however, another angle is equally important: when exposing for a similar final out-of-camera brightness, the V-Log shot required ISO 640 at 1/25 s, while the Standard analytic-LUT version used ISO 100 at 1/5 s (both at f/2.8). The Standard workflow fed the sensor approximately 5× more light.

This gets to the heart of what I cared about from the start. It’s not that “the V-Log curve alters the physical photons,” but rather that within a standard exposure workflow, V-Log’s unique ISO/Photo Style mapping achieves a target brightness using less incident light. By switching the base to Standard at ISO 100, I can reclaim that longer exposure time.

Assuming photon shot noise dominates, capturing 5× the light improves the signal-to-noise ratio (SNR) by roughly:

If a testing scenario perfectly allowed for 6.4× the light (the exact mathematical ratio between ISO 100 and 640), the theoretical improvement becomes $\sqrt{6.4} \approx 2.53$, or about 8.1 dB (1.34 stops). It is worth noting that deep shadows are also influenced by read noise, black levels, and onboard noise reduction, so real-world gains won’t follow the square-root law perfectly at the pixel level.

Is this “free dynamic range”? Of course not

Using Standard at ISO 100 allows me to expose longer while maintaining a similar out-of-camera brightness, which is highly beneficial for the SNR of RAW midtones and shadows. However, it does not magically conjure extra total sensor dynamic range out of thin air. The trade-offs are entirely explicit:

• More light captured: Better SNR in RAW midtones and shadows, resulting in substantially cleaner shadow lifts in post-production.
• Less highlight headroom: Increasing exposure by 5× inherently sacrifices about $\log_2 5 \approx 2.32$ EV of sensor highlight retention.
• No magic growth in total dynamic range: I am simply reallocating the finite RAW capacity, shifting priority from the highlights to the midtones and shadows.
• Context is key: Controlled interiors, nightscapes, and low-contrast scenes generally benefit immensely from this reallocation. Harsh sunlight, window-lit interiors, and stage lighting, however, require careful highlight protection.

So the accurate claim is not “the Standard conversion gives the RAW more dynamic range,” but rather:

It frees me from the rigid ISO 640 floor of the V-Log base and the exposure habits tied to it. This allows me to expose more fully based on the specific scene—trading highlight headroom for cleaner midtones, better shadow SNR, and more robust RAW processing latitude.

Does Real Time LUT just stack a LUT on an 8-bit JPEG?

At one point during the conceptual discussion, GPT-5.6 Sol described the Standard pipeline as having “already lost most of the data”—a significant overstatement that it later retracted.

Panasonic’s official documentation explicitly describes Real Time LUT as an in-camera process applied during capture/recording. It does not generate a finished 8-bit JPEG, save it, and then reopen the file to apply a LUT. The S9 manual also clarifies that RAW files consist of unprocessed 12-bit data, and the LUT is not baked into the RAW file itself—it only affects the JPEG, previews/thumbnails, and any subsequent in-camera RAW processing you manually choose to perform. See:

• Panasonic: Using Real Time LUTs
• S9 Complete Guide: RAW is unprocessed 12-bit data
• S9 Complete Guide: the LUT is not written into RAW

The most reasonable interpretation is that the Real Time LUT sits inside the camera’s image-processing pipeline, operating before the final JPEG/HEIF output. This effectively rules out the “save a finished 8-bit JPEG, reopen, apply LUT” theory. However, since Panasonic has not published the exact bit depth, processing order, or per-step math for the S9’s LUT implementation, I will not present assumptions about its internal bit depth as official facts.

Furthermore, high-precision mathematical processing doesn’t guarantee invertibility. If Standard’s tone curve or gamut mapping compresses multiple input values into a single output value, that distinction is permanently lost, even if the intermediate math operates in floats. The good news is that my later test shots demonstrated that for normal midtones and colors, we are nowhere near a “most of the data is lost” scenario.

The final test shots: how close is the analytic CST version?

Having composed the official formulas into a technical adapter, I combined it with a Fuji Classic Negative-style V-Log LUT, exported a 33-point Standard/sRGB .cube, and loaded it back into the S9.

Figure 5: Left: V-Log + original LUT (ISO 640, 1/25 s); Right: Standard/sRGB + analytic CST LUT (ISO 100, 1/5 s). Both shot at f/2.8 with AWB. The right frame received roughly 5× the exposure. Note: This is not a rigorous scientific experiment. Variances in shutter speeds, AWB, AF, and IBIS can all contribute to slight differences, making this better suited for judging real-world aesthetics rather than proving precise color mathematical differences.

Visually, the overall color relationships between the two images are remarkably close. A pixel-by-pixel comparison of the JPEGs reveals a mean max-channel difference of about $11.89/255$, with the Standard version’s median luminance rendering roughly 0.229 EV darker. After normalizing brightness using a single monotonic tone curve across all pixels, the mean max-channel residual drops to $3.526/255$ (P95 at $7.367/255$, P99 at $10.687/255$), with median signed RGB residuals clustering tightly around $[-1.16, +0.30, -0.69]/255$.

To me, the primary takeaway isn’t that “the two files are identical”—they clearly aren’t. Rather, it’s that the remaining discrepancies look primarily like normal variances in exposure and Standard vs. V-Log base tone rendering, rather than a massive, systemic color cast. As a base conversion method for out-of-camera stills LUTs, this approach has transitioned from “theoretical conjecture” into a genuinely robust, usable tool.

Is 33 points numerically enough?

The project relies entirely on numpy.float64 for computation and outputs 33-point .cube files to ensure compatibility with the S9 and LUMIX Lab. When comparing the 33-point technical adapter against the continuous analytic formulas over 200,000 random RGB samples, the 12-bit max-channel code-value errors are as follows:

The maximum spread across the three channels on the neutral axis is minuscule—roughly $2.22 \times 10^{-16}$. This confirms that a 33-point grid is more than adequate for representing this smooth technical transform. It does not imply that the final in-camera JPEG error is this small, as unpublished factors like Standard tone rendering, white balance calculations, and exposure variations remain outside the scope of the model.

During on-camera format testing, I confirmed the S9 only imports .cube/.vlt files up to 33 points; 65-point files are flatly rejected. LUMIX Lab’s safe compatibility target is identically capped at a 33-point .cube. Blindly exporting a 65-point LUT would not make the in-camera results any more “scientific.”

My current practical workflow

When a creative LUT is confirmed to expect V-Log/V-Gamut input, this is my current operating procedure:

1. Compose the creative LUT with the analytic CST into a 33-point LUT mapped to a Standard/sRGB base;
2. Set the camera’s base Photo Style to Standard and shoot sRGB JPEGs, freely utilizing Standard’s normal ISO range;
3. Shoot RAW+JPEG for daily use: the JPEG bakes in the desired out-of-camera look, while the RAW retains the untouched original sensor data;
4. Expose for the scene’s highlights. Do not misinterpret “ISO 100 is available” as a mandate to “always expose to the right”;
5. For rigorous testing or comparisons, use a tripod, locked manual white balance, manual focus, consistent lighting, and document every auto dynamic-range optimization and Photo Style parameter setting.

The conversion command in the project is straightforward:

git clone https://github.com/t0saki/lumix-lut-converter.git
cd lumix-lut-converter
uv sync

uv run lumix-lut-converter convert-cst \
  --source /path/to/source-luts \
  --output /path/to/output-standard-srgb

The output LUTs carry the required metadata header:

#LUMIXPHOTOSTYLE STD

along with the technical adapter and a manifest.json useful for checking inputs, parameters, output grids, and file checksums.

What I believe can be established so far

After this extensive adventure, these are the conclusions I am confident stating:

1. The ISO 640 floor of the V-Log base compared to Standard’s ISO 100 has a tangible impact on stills exposure workflows; it is not merely a meaningless menu number.
2. When comparing ISO ratings across different Photo Styles, identical ISO numbers do not guarantee identical RAW responses. On my S9, at the exact same exposure and rated ISO 640, the Standard profile’s RAW code values are about 6.08× higher than V-Log’s.
3. Converting a V-Log creative LUT to a Standard/sRGB base allows for greater actual light exposure while maintaining a similar out-of-camera brightness. This significantly improves RAW midtone and shadow SNR, albeit at the direct expense of an equal amount of highlight headroom.
4. Panasonic’s published V-Log OETF and V-Gamut matrix provide all the necessary math to build a highly accurate, reproducible analytic adapter. “Subjectively fitting the Standard profile” doesn’t need to be the default approach.
5. Real Time LUT is an integral part of the in-camera image processing pipeline, not an afterthought applied to a finished 8-bit JPEG. Furthermore, the LUT is never baked into the RAW file data.
6. “Strict lossless equivalence with the original V-Log workflow” is practically impossible. Standard’s internal tone curve, gamut mapping, and LUT insertion mechanics are proprietary, and any data clipping along the image pipeline is mathematically irreversible.

What I still don’t know

Plenty of blanks remain in this exploration:

• The precise tone curve and gamut mapping of the S9’s Standard Photo Style, both before and after LUT application;
• The exact bit depth and definitive processing order of Real Time LUT implementation inside the S9 hardware;
• Whether the visual residuals remain stable and consistent across different LUMIX bodies, firmware updates, and minor Photo Style parameter tweaks;
• The worst-case error margins in extreme highlights, deep shadows, skin tones, and highly saturated colors;
• The exact RAW response relationship between V-Log ISO 640 and Standard ISO 100 under strictly locked conditions (white balance, exposure, focus, and controlled studio lighting).

If I continue these experiments, I’ll prioritize testing strictly controlled grayscales, skin tones, saturated objects, and highlight roll-offs over reshooting elaborate 3D on-screen charts. The analytic formulas have successfully resolved the “known” variables; future tests should specifically hunt for “what the model failed to explain.”

Closing thoughts

The most interesting part of this journey was watching the problem constantly rename itself.

Initially, I thought I was attempting a “lossless V-Log to Standard LUT conversion.” Then the goal shifted to “inverting Like709,” and later “photographing on-screen charts to mathematically map Panasonic’s Standard profile.” It wasn’t until I was pointed back to the official encoding function and gamut definitions that I realized the truth: the correct approach was never to brute-force the problem with massive datasets. The real solution lay in separating the problem into three distinct buckets: known color transforms, proprietary in-camera processing, and the physical behavior of exposure/ISO.

I am still not a color scientist, but that shouldn’t deter an amateur from methodically dissecting a problem using public documentation, reproducible code, and controlled testing. The goal isn’t necessarily getting every step perfect on the first try; it’s about being willing to admit which test shots were flawed, which conclusions were overstated, and which visual differences were merely byproducts of white balance and exposure—and leaving those corrections clearly on the public record.

Special thanks to @Jackchou00 for his precise guidance. He pointed out that the CST should first be built using Panasonic’s published V-Log encoding function and V-Gamut, and he suggested verifying the physical relationship between V-Log ISO 640 and normal Photo Styles’ base ISOs by examining the RAW data. Those two insights single-handedly pulled this project back from the brink of overly complex black-box fitting and steered it onto a simpler, scientifically explainable path.

If this write-up helps other LUMIX users, I hope the main takeaway isn’t “here is a magic, universal LUT conversion formula,” but rather a much more fundamental lesson: Always determine what input a LUT expects before deciding which color pipeline to drop it into, and always lock down your exposure and white balance before trusting a set of pretty error metrics.

Main references and project records

• Panasonic V-Log / V-Gamut Reference Manual
• Panasonic LUMIX S9 Complete Guide
• Panasonic: Using Real Time LUTs
• Project README
• Research findings and methodology (more technical)