I'm working on two models under the title LusicDreamer: an anime-style model and a semi-realistic model. While I plan to integrate them in the future, I'm currently conducting extensive experiments with both models through full fine-tuning.

The latest version of the anime model is ver.0.72A, and the latest version of the semi-realistic model is ver.0.71SR. There are also NeoSD versions using the same methodology and dataset with SD1.5 and Qwen-Image version. Currently, everything is experimental.

ver.0.83 Anime （ZiBase）

This version was trained using the same family of source materials as LD0.82 but with an expanded dataset of images. While it offers improved responsiveness to certain prompts, it may not be superior in every respect. For this release, I am providing only the BF16 and standard FP8 versions, as I believe these represent the best choices.

ver.0.82 Anime (ZiBase)

I had previously released LucidDreamer 0.81 and its derivative, LucidDreamer 0.82, in LoRA format. Personally, I believe LoRAs offer a wider range of applications than full checkpoint (ckpt) models. While a LoRA cannot perfectly replicate a full checkpoint, it can capture the essential characteristics. LoRAs allow for versatile combinations and are lightweight models.

After version 0.8, I had intended to release only LoRAs for the foreseeable future, but I decided to release a checkpoint version for this specific iteration as well. As explained on the LoRA page, you can achieve results close to 0.82 by combining LucidDreamer 0.80 with four specific LoRAs. However, since that approach involves a potential drop in quality and added complexity, a standalone checkpoint version may still offer value.

In terms of training data, 0.82 did not undergo extensive training; it utilized a dataset of approximately 11,000 images. This is only half the volume used for 0.81, which already had a limited dataset. The key difference is that while previous datasets relied on "Illustrious"-style assets, this version utilizes "Anima"-style assets. Although the dataset size isn't large enough to drastically alter prompt behavior, it may produce images with a slightly different aesthetic. I decided to release the checkpoint version to allow users to verify these nuances for themselves.

As I mentioned in a previous comment, I hold a negative view of Anima itself; it is legally problematic. While I do release models, I generally avoid heavily modifying existing ones. However, since there are no issues with the generated images themselves, I will continue to use Anima assets in the future (though, admittedly, I only recently noticed that the Anima terms of service had changed).

I don't quite understand INT8.

I tried creating an INT8 version, too. It has a reputation for being fast and lightweight, but it isn't fast at all. In terms of speed, it’s slower than BF16 and even slower than the conventional FP8 version. Purely in terms of speed, the Scaled FP8 version was the fastest.

Then there is the matter of quality. Here, I’m looking at how close the output is to the original BF16 version. Trouble is, the results for Scaled FP8?which ought to offer the highest precision?are completely disappointing. There are no differences in the processing layers or the like (except for the conventional FP8). The INT8 version performs reasonably well. However, the conventional FP8?which should theoretically have the lowest precision?actually yields the best results. It involves a process that is essentially just a simple type conversion rather than true quantization, yet for some reason, the quality is remarkably high. It has long been a puzzle that this FP8 variant?which shouldn't logically produce good quality?delivers surprisingly high-quality results. According to Google, the Scaled version might be underperforming due to insufficient calibration data; apparently, improper scaling can actually be detrimental. I can't verify if that's true, though. Just to be safe, I created a version using ConvRot instead of SVD, but there was no significant difference.

VRAM usage is another issue; there isn't much difference even with INT8. In the updated ComfyUI, sampling is supposed to occur in INT8, but it looks as though the data is being converted to BF16 for processing. Removing the Distill LoRA makes almost no difference. Even a clean install of ComfyUI yields the same result. I don't fully understand the process yet, so there might be an error in the conversion, but I got the same results when trying INT8 implementations published by others. Since those were built for ComfyUI, it would be strange if they didn't work properly. ComfyUI seems to support only ConvRot, yet the results with SVD feel similar. It is possible the ConvRot format is incorrect. If anyone has any insights, please let me know. (I recall VRAM usage being significantly lower with FP8 previously, but in the new ComfyUI, the VRAM usage for that format is now not much different from BF16.)

The table below shows the total VRAM usage for the workflow?monitored via Task Manager?starting from a state where the model and model cache were unloaded. Specifically, it lists the VRAM consumption during KSampler execution (calculated by subtracting the pre-execution VRAM usage from the usage during workflow execution) and the time required for the KSampler step when generating a 1024×1536 image across 4 batches. These results were obtained using an RTX 5090 with Distil LoRA for an 8-step generation process.

INT8: 18.6 GB, 53.486 sec

FP8: 16.8 GB, 47.284 sec

BF16: 19.1 GB, 49.672 sec

FP8svd: 17.6 GB, 41.191 sec

While there is some slight variation in processing time between runs, VRAM usage remains virtually unchanged.

At this stage, it is clear that INT8 is neither fast nor lightweight. The lower accuracy of ConvRot is particularly noticeable compared to the SVD-based method. Scaled FP8 is slightly faster but suffers from poor accuracy. Currently, the best balance of low VRAM usage and high accuracy is offered by standard FP8 (created simply by converting the data type).

Therefore, I have decided to release files for BF16, FP8, INT8 (ConvRot), and INT8 (SVD).

ver.0.80 Anime (ZiBase)

This model was rebuilt starting from version 0.72 after I discovered that the training settings for the 0.7 series were incorrect midway through the process. I have discontinued the use of "tick-tock" data and am using only anime-style assets. Since semi-realistic assets are excluded, the scope of the training data is narrower; to compensate for this, I have made the dataset for the 0.80 series larger.

The samples were generated using 8 steps with a slightly increased CFG scale and settings that allow for the use of negative prompts. Regardless of the specific strength used, the use of Distill LoRA is intended.

ver.0.79 SemiReal(ZiBase)

This is a semi-real version. It's less Asian than I expected, so it's a relatively general-purpose model. Since the base is an anime model, anime-style drawings will also appear.

Please be careful to specify the pose, composition, background, etc. Up until now, I had tried to get random poses as much as possible, but at some point it started to get really weird. I was spoiled for pose learning, so there are pros and cons.

ver.0.79x SemiReal (ZiBase)

This is an intermediate model in the development of ver.0.79SR. Simply put, it's a semi-realistic version based on ver.0.78A, which was an anime model. It's trained using approximately 32,000 output images from 7 SDXL models. The character is Western-looking. The final version will be more photorealistic, but at this stage, it's not very realistic.

I plan to add Asian-looking assets to finish it, but I've decided to release this Western-looking semi-realistic model for now.

0.79x Interim Version: Western-looking Semi-Realistic

0.79y Interim Version: Asian-looking assets added

0.79 Final Version: Asian-looking assets slightly adjusted

+ Face LoRA

The above is a rough outline, but 0.79y will involve quite extensive revisions (and will likely not be released). The assets I've prepared are quite different from before, so it might fail. That's one of the reasons for releasing this version now.

I'll also release a test version of the Face LoRA at this time. Three different LoRA datasets are used, each with slightly different training processes. All are of Asian origin. They are designed to be used in combination, and combining them also improves photographic representation.

ver.0.78 Anime (ZiBase)

Animation model based on 0.78 dataset. The image quality is higher than the Turbo version simply because the quality of the learning materials is higher.

I recommend using Distill LoRA in this model, but applying it in 1.0 seems overkill. When using the 4Step version, we recommend operating Distill LoRA:0.6, 5Steps.

As for Distill LoRA, I previously recommended the 4Step version over the 8Step version, but since both versions work fine with the 2603 version, it may be a good idea to use them depending on your preference. It seems that the color development and the angle of view of the picture are different.

Almost all samples are output using the 2603 4step version, Euler, and Simple.

When not using Distill LoRA, try using ER_SDE+Beta with CFG scale around 5.5. Euler doesn't produce decent pictures. It is created assuming Distill LoRA, so we strongly recommend using Distill LoRA.

Adjust the amount of Distill LoRA applied depending on the image to be output. This greatly affects the stability of your fingers. Also, the stability standards for FP8 are different from those for BF16, so please adjust them individually.

ver.0.777 Anime (ZiTurbo)

This is a quick update, but here's the Turbo version, 0.777. It was trained by adding lightweight supplemental material equivalent to 0.78 to 0.775. While 0.76 produced a more detailed, cool style, and 0.775 a clean, cute style, this outputs standard anime illustrations. The accuracy is slightly lower, and fingers and other details might be unstable. Due to CIVITAI's limitations, the samples are mainly vertical images, but it probably performs better with horizontal images.

Using the ckpt LoRA mentioned in the comments for 0.775, it approaches 0.76 in the negative direction and 0.775 in the positive direction. A range of around ±0.4 is probably practical. Applying around 0.3 reduces the roughness of the output image (maybe I should have merged them).

ver.0.775 Anime (ZiTurbo)

This is an anime model for Z-Image Turbo using the dataset for version 0.77. While version 0.76 produced a much more detailed image, this version produces a simpler picture. Because it's based on version 0.76, it should also be compatible with differential LoRA.

ver.0.77 Anime (ZiBase)

My approach is wavering. I've abandoned the tick-tock method because it has its drawbacks. This model was built based on 0.75 to produce simple and clean images. There are still some parts that need improvement, so I'm wondering whether to start over from the base. The next model will also be anime-style.

ver.0.76 Anime (ZiTurbo)

It's been a while since I've used Z-Image Turbo. Since Z-Image Base came out, I've been using that exclusively, but I hadn't properly fine-tuned a Turbo model, so I did some simple fine-tuning. I used 0.3ZiT as the base model and trained it for about 5 hours. Of course, that wasn't stable enough, so I made some adjustments to finish it. The dataset used was a subset of 0.75.

As a result, I was able to confirm a certain level of performance even with minimal computational cost. Recent models have all been simplifying training, but this is the first time I've reduced it this much.

Personally, I think Base has more room for improvement, but using Turbo again after a long time makes me realize it's a completely different model. The advantages include less unwanted text on the screen and easier NSFW correction.

ver.0.75Anime

This time, the plan was to move from semi-realistic to anime-style, but this model hasn't quite returned to that style. Since the previous model was quite realistic semi-realistic, some might think this one is more semi-realistic. Of course, it produces anime-style images, but it also produces photographic images. I ultimately intended to create a model that could produce both, or rather, a variety of images, so this was a bit unexpected.

The Tick-Tock mechanism, designed to avoid wasting training data, doesn't seem to be working properly. Even the AI ??seems to advise against it. I will reconsider what to do next.

While there are improvements compared to 0.72A, the overall result is less impressive. For anime-style images, I think 0.72A produces more interesting results. This model is an intermediate form between semi-realistic and anime-style, excelling at semi-realistic images that lean towards painting, and images with anime characters on realistic backgrounds.

Of course, adding "anime" to the prompt will produce anime-style images.

ver.0.74 SemiReal

This is the next TikTock semi-realistic model (MyJuice was just a detour).

For this experiment, I wanted to make it possible to switch between two semi-realistic styles, but it's barely functional.

Going forward, I'll focus on:

- Increasing the development pace (cutting corners more often)

- Addressing NSFW issues

Simplifying development is a main theme, and I'll pursue it further. I had anticipated that NSFW issues would gradually resolve themselves as more data was collected, but that seems to have been a bit too optimistic, so I plan to increase the data further.

Also, while I've previously focused on slightly unusual styles with easily noticeable changes, I plan to include more standard styles.

ver.0.73 MyJuice test

This time, I've changed direction a bit and created a more realistic semi-realistic model. As part of a labor-saving test, I focused on gathering data from Asian women's faces for training. Men? None included.

The data is relatively small, just over 1500 images, aiming for low accuracy and short training time. Since the base model is the same as previous models, I thought that even with less data, there wouldn't be any problems with NSFW, but that wasn't the case at all. The base model had been trained to the point where it could somewhat hide the Z-Image quirks, but when new data was added, it seemed to loosen up a bit and the quirks became more prominent again. Please note that this version is not NSFW compatible.

ver.0.72Anime ZiBase

I trained based on 0.7 using a dataset created with different images from the same series as 0.6.

Since 0.7 is based on the 0.6 series, it means that the information has been inherited. For a while, I will try the Tick-Tock method, which uses the anime model and semi-realistic model as a base to improve accuracy. Even in the anime series, I was worried about whether to use a different style from the previous one, but since the previous style seemed to be popular, I decided to stick to the same style this time.

Actually, the output image itself is not much different from the 0.6 series. The strange quirks of Z-Image have been reduced, the colors are darker, and the semi-realistic influence remains in some areas. Some people may think that 0.6 is preferable for things like color depth.

The phenomenon of the body becoming thicker than expected with 0.6 has been resolved. Prompt fidelity has also been slightly improved. If you do not specify the background, it may not appear properly.

It's not that it's completely better than the previous version; the atmosphere has shifted from Light to Rich, and from Cute to Cool (just a little). I think it's a good idea to try the same prompt on both.

I am conducting an experiment intended to reduce training time. The number of new images this time was approximately 28,000, and the training time was approximately 46 hours. Considering that 0.6 was running for about a week, this is a considerable simplification. In the future, I plan to do short-term iterations with approximately 30,000 additional images.

ver.0.71 Semi Real ZiBase

This is a semi-realistic model with final training added to the preliminary training version.

+Improved image detail, such as faces

+Improved prompt accuracy

+Saturated colors

+Increased contrast

-Colors may be too saturated

-Faces are displayed larger, slightly altering the composition

In prompts with very detailed facial features, the face may be emphasized more than necessary. In this case, place prompts related to facial details at the end. The example below rearranges prompts from the order of face-body-background-pose to background-body-pose-face.

It seems I provided too much detailed facial information during the learning process....

ver.0.7 Semi Real ZiBase test

This is a semi-realistic version currently under construction. It is still in the preliminary learning stage, but I'm releasing it on a trial basis.

I am using a completely different learning method from the ver. 0.6 anime version. 0.6 was not originally supposed to work so well, but it is working better than expected, which is a bit disconcerting. This time I am testing in the complete opposite direction, so the results may not be good, but in theory there should be many improvements.

The current drawback is the low image quality. This is planned to be improved in the future.

ver.0.6112 Anime ZiBase

This is the final version FT tested on the ver. 0.6 dataset. The colors are a little lighter than 0.68, but this is partly due to a dataset issue. It's not necessarily better than 0.66 or 0.68, but I think it's easier to produce a more stable image.

Distll LoRA and output settings are surprisingly important. For stable operation, I recommend using both the 4-step version and ver. 1 version at 0.8 and outputting at 5 steps. The image remains almost the same even at 4 steps, so I recommend outputting at 4 steps and increasing the step only for the parts that look good. If you're prioritizing atmosphere, using ver. 1 as the main output and outputting at 8 steps or more will produce interesting results. Faces and other features will change slightly, however.

This was my first FT with Z-Image, and while I discovered various issues along the way, I was a little surprised that the image turned out surprisingly well. I'm also slightly changing my Z-Image captioning strategy, and next time I'll try completely different settings.

ver.0.68 Anime ZiBase Finetuned

Due to file upload problems, the BF16 version of ver.0.68 has been uploaded as the BF16 Full version of ver.0.66.

ver.0.66 Anime ZiBase Finetuned

This is the new FT version. It's more stable than the first one. There are two versions of BF16, but I tried uploading it as a trial and was able to upload it, so I will also be releasing the next version at the same time (it is labeled as the full version). The next epoch is being created while I'm uploading it, but I can't seem to do anything about it. . .

It is not recommended to use it as is. It takes over 30 steps. Please use 4Step LoRA. For this case, I think it's okay to do it in 4 steps (if the details are rough in the FP8 version, use 8 steps).

You can use it as is, but since it does not display only anime pictures, it is recommended to add anime to the prompt. The output of my pictures has gradually become more stable, but compositions and poses also tend to be uniform. In such cases, we recommend using the 4-step version of LoRA at strength 0.5 and trying 6-step execution. If you do this, the colors will fade, the details will become rough, and the body structure will often become questionable, but it seems that making the generation more unstable reflects the learning contents more strongly, so there is a higher possibility that you will get a rough but interesting picture. Keep the Shift value low (3 or less). Normally, 4-step execution with 4-step LoRA:1.0 is OK, but please try it when you want more variety. Most of the samples this time are from 6-step execution of 0.5 (that's why the colors are whitish).

LoRA: 1.0 can produce images with a sufficient amount of information, but 0.5 is closer to the model's intent, as it has an excessive amount of information. Please be careful as lowering the Shift value will result in a more complex shadow being cast.

For problems with washed out colors and low contrast, please refer to the sample workflow using color adjustment nodes on ComfyUI attached to an image of a girl drinking tea.

ver.0.6 Anime Finetuned (test)

This is the FT version using the ver.0.6 dataset.

To be honest, based on the sample images, I was expecting a proper image to be released around the middle of next week, but I found some images that looked surprisingly usable even at low epochs, so I decided to release them quickly. Currently, uploading to CIVITAI is extremely heavy, so only the FP8 version is available.

The samples are outputted in 4 steps using 4-step LoRA in the BF16 version, but for the FP8 version, please use around 8 steps using 4-step LoRA. As I wrote before, using 8 steps in the 4-step version is recommended over the 8-step version.

The anime images are not yet stable, so I recommend adding "anime" to the prompt. However, since there is a tendency for the animation images displayed to be those stored in Z-Image rather than those that have been learned, I found that a simple "[[anime]]" or "[[[anime]]]" to lightly indicate that the image is anime picture would be better. This affects shading as well as faces.

Tip: This is only available in Forge Neo, but specifying a value for an undefined word affects the entire image (e.g., image:0.5). Be careful when trying out a prompt imported from somewhere else. You can also use this, such as image:0.9 or image:1.1. Values below 1 result in lighter colors and increased sharpness. Values above 1 result in darker colors and a blurrier image.

Now that I'm finally able to display an image using Z-Image FT, the overall quality will likely improve, but overwriting Z-Image concepts isn't necessarily the best approach. I think intermediate versions have a certain meaning. Adding [[anime]] allows you to fully confirm the learning effect. Currently, a specific area of weakness is NSFW content.

However, there's no way to know if the FT model wasn't usable without conversion...

ver.0.8 Anime (ZiBase)

This is an anime model that was trained using ver.0.5 as a base model.

All samples use Distill LoRA.

Sampler: euler/euler a, Scheduler: simple, step: 7, CFG scale: 1.0, Shift: 16

When not using Distill LoRA, set Step 30 or higher and CFG scale to about 4.5.

This time, I mainly use the 4-step version of LoRA with 7-step output. If you use the normal 8-step version, the composition will look a little strange. 8-Steps-2602_UDCAI Edit version does not work well even if I use LCM. However, although it is a completely wrong usage, using both 4step version and 8-Steps-2602_UDCAI Edit version with 1.0 seemed to be the best choice for this model.

If the steps are too low, the quality of the picture itself will drop, so try changing the number of steps depending on your purpose.

ver.0.6 Anime (ZiBase)

Although it includes a small amount of version 0.5, most of it is a model made with new materials. It supports more anime-like and delicate designs. There are areas where physical stability has improved and areas where it has become unstable compared to 0.5. This model is at its best at low shift values, but the body structure becomes more fragile.

This model focuses on producing a variety of pictures rather than producing stable pictures. However, there are also unstable aspects.

If you want to produce stable images, it is better to set ModelSamplingAuraFlow quite high (about 20) and CFG scale high. It may be better to fix the denoise value to 1.0 as well.

If you think that Z-Image or Qwen-Image images are boring, you may occasionally get better images if you try lowering the Shift value.

If you enter an existing prompt and get a shabby picture, it's probably filled with stupid parentheses, so delete them all. If noise appears in the picture with ComfyUI, please update ComfyUI.

The colors seem to be a little paler and brighter on this model. You can adjust it using CFG scale, but if you're concerned about the image changing, try adjusting it with comfyui-latent-vae-tweaker. This tool was originally designed for SD1.5/SDXL, and 16-bit formats such as Flux.1 and Z-Image cannot be edited at the latent stage, but they can be edited at the image stage. Please refer to the workflow for the added images.

*I've made comfyui-latent-vae-tweaker compatible with 16ch latent format. I don't think it's something that an average person can control, but just for reference.

ver.0.5 Anime (ZiBase)

This is a test model based on a new anime dataset. Captioning and other features were trained using conventional methods.

While the training resolution was only 1280, the image quality was clearly improved from ver.0.4, so it seems that lowering the accuracy of the previous training test was not effective after all. It did use less memory, though.

This time, the base model used was a 16-step run of Z-Image Base, with a small amount of Z-Image Turbo layers mixed in. The basic settings for generating the sample images are: Sampler: DDIM, Scheduler: simple, Steps: 16, CFG: 8.0, Denoise: 0.85, ModelSamplingAuraFlow: 8.0.

I have uploaded three types of files: BF16, FP8, and GGUF Q6_K.

~~Sorry, something wrong.~~ Fixed.

IF YOU USE GGUF FILE, PLEASE REPLACE loader.py IN THE ComfyGGUF FOLDER.

Due to convenience, it has been uploaded as training data.

The included lcpp.patch and convert.py are not necessary for ordinary people. Please use only those who understand. I also intend to make it compatible with flux.2, but its operation has not been verified.

・more speed?

Although this model uses its own speed-up method to reduce the number of steps, it is not very fast. Several high-speed LoRA versions have been announced for Z-Image Base.

Z-Image-Fun-Lora-Distill : doesn't work

Z-Image (base) Distilled Lora | Extracted: works but looks plastic

So add "anime" to prompt.

The picture will change, but it may be useful in some cases.

ver.0.4 SemiReal (ZiTurbo)

This version uses the exact same materials as the 0.4 SR Base version. This version has a more semi-realistic look. The base model is a mix of Z-Image Turbo and a small amount of Z-Image Base. This may improve the ability to express details a little.

The sample images make extensive use of high CFG settings. CFG 3 is recommended, but this may fail depending on the sampler and scheduler. At the same time, the image quality is controlled by the ModelSamplingAuraFlow shift value (and denoise value). Please refer to the sample and try various options.

ver.0.4 SemiReal (ZiBase)

This model was created as a test run using Z-Image Base.

I was aiming for a semi-realistic model, but the resulting model produced a variety of different images. The captioning is outdated, the resolution is only 1280 (which results in moiré), and the calculation accuracy was minimal.

It can be used in the same way as a regular ZiB model, but I recommend setting the CFG scale higher (around 6).

I created the GGUF version in 6 bits, but since CIVITAI only supports 16/8/4, I uploaded it as 8 bits for convenience.

ver.0.3 Anime

This is a new version of the animation version. Full fine-tuning has been difficult, so this version also uses LoRA. The amount of data has been increased by more than three times. I think the body stability has improved compared to the previous version, but it may still not be sufficient.

Since a wide range of images was used for training this time, it is easier to produce photographic images than the previous version. Adding "anime" to the prompt is effective. However, please note that specifying a number such as "anime:2" will cause the image to break down.

ver.0.2 Real

This is a realistic version of LucidDreamer. I'm having difficulty adjusting the prototype, so I've decided to release it as a test version. I'm still getting used to using DiT, but with Z-Image, body structures tend to be more distorted than with other models using DiT. As a result, combining LoRA results in a greater loss of quality. Since finetune isn't working properly, this can't be helped for the time being. This time, I created three models by applying the three types of LoRA I prepared to create one ckpt at slightly weaker rates. These were materials for finetune, but it seems that using each alone produces better results than using multiple LoRAs.

In terms of datasets, 1 and 2 are completely different, while 3 is a subset of 2. 1 is packed with miscellaneous elements and turned out more illustrative than I expected. 2 has a relatively large number of Western women (especially NSFW) and a fair amount of data, but you may not see any particularly cute girls. 3 is an Asian-style model extracted from 1. Please note that if you leave it unspecified, it often results in a white background.

This series has been adjusted to obtain a wide variety of output with a single prompt, so if no image is specified, the seed will result in larger changes in the image and pose.

In terms of dataset type, it is in the same series as the anime version 0.2, so it is called ver.0.2R.

ver.0.2 Anime

I increased the number of training images. I think stability is improved compared to ver.0.0 and 0.1.

Because it was trained with a wide variety of images, the image style is not stable.

If you don't specify anything in the prompt, the image tends to have a cool(?) style. Sometimes it will look more like a photo. By adding "anime," it will stabilize to an anime style. Adjust to your liking.

By the way, my fine-tuning failed. After a long time, all I got was noise...

There are still issues with the body structure and prompt tracking, but I don't think the other models are much different...

ver.0.1

I believe Z-Image is expected to be a replacement for SDXL. In ver. 0.0, LoRA was applied quite heavily in that direction. It was adjusted to produce a variety of images similar to those in SDXL. On the other hand, it was a bit of a stretch, and it had significant limitations on body structure, etc.

So, I gave up on trying to create anime-style images using the model alone, and created ver. 0.1, which assumes anime:2 prompts.

So, please add "anime" or "anime:2" to the prompt. Tags like "masterpiece" are not very effective. Sometimes they are effective, but more often than not it's better to remove them.

I've also added two more materials. The body structure still looks strange, but since there seem to be many elements missing from the basic ZiT model, I'll have to add them little by little. Please wait for testing with the finetuning version.

ver. 0.1 produces sharper results than 0.0. The image's body stability has also been improved (though it's still not perfect).

ver.0.0

This is my first model created with Z-Image Turbo. It may be a bit difficult to handle. I created an anime-style model, but the body structure is unstable.

I haven't set a trigger word, but adding "anime" makes it relatively stable. If it's not enough, try adding "anime:2."

Files with SHA256: d8d14a087686525c4aa12104f5f89980c38ea38cb913a778c950cd66439064ce