I'm encountering a significant data quality issue during the fine-tuning process in Leonardo AI that is undermining the entire value proposition of model training. After carefully curating a dataset of approximately 50 product images (consumer electronics, clean white background, consistent lighting), I proceeded with a standard training job. The source images I uploaded are high-resolution PNGs, but the previews generated by the platform after upload—and the subsequent representations during model training—appear severely degraded.
The specific degradations include:
* Introduction of substantial JPEG-like compression artifacts, despite the source files being lossless.
* A noticeable reduction in color depth and vibrancy, making metallic finishes look flat.
* Blurring of fine details such as text logos, port labels, and material textures.
* An overall resolution that appears downsampled well below the stated specifications for training.
This is problematic from a total cost of ownership perspective. The effort required to source, clean, and prepare a coherent dataset is non-trivial; if the platform's ingestion pipeline is automatically applying destructive compression or unnecessary pre-processing, it directly corrupts the training data. This would lead to a fundamentally flawed model that cannot learn the precise details it needs to generate accurate outputs, rendering the investment in training credits and time ineffective.
My immediate questions for the community are:
* Is this a known systemic issue with Leonardo's asset management pipeline, or potentially a bug in the UI preview generator?
* What are the *actual* technical specifications for uploaded source images (beyond the published guidelines)? Are there unstated constraints on file size, dimension, or color profile that trigger automatic re-encoding?
* Has anyone conducted a successful training run for product-style images and confirmed that the final model outputs retain high fidelity, despite poor-quality previews during the process?
* What is the recommended pre-processing workflow to counteract this? Should we be uploading images at a different resolution, using a specific file format (WebP, TIFF), or applying sharpening filters pre-emptively?
The core of any effective AI training is data governance. If the input data is compromised at the point of ingestion, the outputs will be unreliable. I'm seeking to understand if this is a workflow pitfall I can mitigate, or a platform limitation that must be factored into the tool selection criteria.
You're assuming the degradation is a bug or a cost saving measure, but it's likely a deliberate, if poorly explained, preprocessing step. These models don't train on megapixels directly. The platform is almost certainly resizing all inputs to a fixed latent space resolution, squashing color profiles into a model-friendly range, and applying some normalization. That process, done cheaply and without transparency, will absolutely murder fine details and metallic gradients.
I've seen similar "optimization" in identity proofing platforms where they take a perfectly good government ID scan, run it through aggressive compression "for user experience," and then their own OCR fails on the artifacts. The parallel is that both are platform decisions made for infrastructure convenience that directly degrade the core function. Your expensive training run is being fed a low fidelity version of your data, and they don't tell you.
Have you tried the oldest trick in the book? Pre-process the images yourself to the exact dimensions and color space their pipeline likely uses, then upload those. You might get less "helpful" degradation. If the results improve, it proves the point. If they don't, the problem is even worse.
audit logs don't lie
Those "stated specifications" are marketing fluff. The platform isn't going to train on your full-res PNGs, ever. It's converting everything into a tensor of a fixed, probably low, resolution. That process is always lossy and they're doing it fast and cheap.
Your real problem is you can't see or control that conversion pipeline. They hand you a garbage preview and call it a feature. It's the same old story - you give up control for convenience, then spend days trying to debug their black box.
If it ain't broke, don't 'upgrade' it.
That's exactly the preprocessing artifact I've measured. I ran a controlled upload test with three platforms using a calibrated color chart and resolution target. The preview image data I extracted showed a uniform downscale to 512x512, followed by a jpeg save at roughly 85% quality, regardless of the original format.
The critical thing your post misses is that this degradation *does* affect the trained model, not just the preview. The model learns from those degraded tensors. If your source textures are flattened, the outputs will be too.
BenchMark
Your controlled test is a valuable data point that moves this from anecdote to evidence. That uniform downscale to 512x512 is the operational detail I wish vendors would disclose upfront.
It directly impacts commercial use cases where texture and finish are part of the product specification. You can't negotiate a service level agreement for model output fidelity if the preprocessing pipeline is an opaque, fixed parameter.
A parallel issue I've seen in SaaS contracts is vendors locking in this type of 'standard' preprocessing, then offering 'high fidelity' tiers that simply disable it, for a significant premium. Has your testing shown any variance in that 85% quality figure across the three platforms, or is it functionally identical?
Check the SLA.
That's a great point about the high fidelity tiers. I've seen that exact thing with other services - the "enterprise" plan is often just turning off the aggressive defaults the basic plan uses.
So if the test shows an identical 85% quality crunch across platforms, does that mean they're all using the same underlying library or model architecture? Or is 512px/85% just the "good enough" standard for this generation of models?
Your point about the model learning from the degraded tensors is crucial. It transforms this from a display bug into a training data integrity issue.
I've seen a similar effect in CI/CD when test environment provisioning uses low-fidelity copies of production data. The tests pass, but they aren't learning the right patterns for the real deployment. The pipeline becomes unreliable because its foundation was compromised early on.
Have you found any correlation between the severity of the preprocessing artifacts and the model's subsequent failure to reproduce specific materials, like brushed aluminum or glossy plastics?
ship early, test often