Created attachment 103473 [details] The logfile for for the 'Fetching pallete' phase, during Render Animation I was directed here via tumblr so, here is some information about my issue: 1.) My OS is Windows 10. 1 b.)The version of ffmpeg I downloaded was labelled "ffmpeg-latest-win64-static.zip" The READ ME file stated it was "FFMpeg version 20170116-e664730". 2.) I acquired the file at the url: https://ffmpeg.zeranoe.com/builds/win64/static/ and just stored it in my downloads folder. The destination of my exported animation would have been elsewhere though, in a subfolder in my Documents. My Documents is also where I found my logfiles. 3.) I just ran a quick test for this animation. I just used the pen tool and wrote 1, 2, 3, and then 4 on consecutive frames. The animation is running on 24fps and is only 4 frames (frame 0 - 3). The dimensions are 1960x1080 The bit depth is 32-Bits Float, and the Background is not transparent. It's a solid white background. I hope to hear back from you guys soon! I'd really love to animate with this software!
Created attachment 103548 [details] Same issue on Ubuntu 16.04 Hey, thanks a lot! This is exactly what we needed to know! And even better, due that, I was able to reproduce on Ubuntu! Turns out that the problem is the 32bit float depth. You cannot save out 32bit float into png(because 32bit float is 128bit in total, it's per channel, and png can only handle 8bit and 16bit per channel.). So, when we convert the image to a png sequence, Krita cannot save to png, but the biggest problem here it is silently failing instead, whle still telling ffmpeg to convert. And then ffmpeg cannot find the frames, because duh, there's no frames to begin with! So, what we can do is any of the following: 1. Fail to render but telling the user that they should convert to 8bit themselves. 2. Automatically convert the image to 8bit before rendering. 3. Use exr for the floating point exports instead. This will need some experimenting to see if this is at all possible with ffmpeg. (Apparently it can use exrs as frames, but I am not sure if it can handle them with all the gif features we use)
Ok, a bit of an update. 1. exr frame export saves odd. It saves as frame.*0000.exr and so on. This is silly. 2. While ffmpeg can do all the tricks with exr that it can with png, it does NOT take into account that exr files are always linear encoded, so the colors are off. We might be better warning the user that we will automatically convert to 8bit, and that if they want higher quality output they'll need to use external software.
(In reply to wolthera from comment #2) > Ok, a bit of an update. > > 1. exr frame export saves odd. It saves as frame.*0000.exr and so on. This > is silly. > > 2. While ffmpeg can do all the tricks with exr that it can with png, it does > NOT take into account that exr files are always linear encoded, so the > colors are off. We might be better warning the user that we will > automatically convert to 8bit, and that if they want higher quality output > they'll need to use external software. Okay, so I tried to make an animation with the same dimensions as before, but with 8-Bit Float depth. And it was a success!!! I was able to render the animation as a .GIF as well as a .MP4 file (the mp4 was actually smaller in memory size)! ^^ Albeit, I believe there was a slight discoloration like you said. What is it you mean by "external software"? Is there a way to make the animation render with proper colour? Is that the current mystery undergoing investigation?
Well, I am somewhat surprised that you need 32bit float per channel, 8bit integer per channel is the maximum 90% of all computers can show at all... The discolouration might be caused by converting from a linear to a gamma-corrected colorspace, which changes the result of layer blending. You can try merging all layers together before converting to avoid that type of change. People often confuse 8bit per channel with 8bit color in total. The latter is like the maximum colors gif can have, 2^8=256. But 8bit per channel is that per color channel, so for RGBA, that is 4 channels, 8*4=32 so the total amount of colors in a 8bit per channel image is 2^32, which is a bit more than 16 million, and quite a bit more than 256 colors. :) 32bit float per channel then is 32*4=128, so it's 2^128 colors, which is kinda a lot. You can use applications like blender to render exrs to video files, but unless you are doing specialised things with mixing colors, you should not be needing 32bit float per channel. I am telling you this because it can make your files super-big. It's like, the type of color quality used for Hollywood movies, it seems a bit odd to use it for small gifs :D There's more on it in the manual: https://docs.krita.org/Bit_Depth https://docs.krita.org/Gamma_and_Linear https://docs.krita.org/Color_Managed_Workflow#Exporting
Oh, for your other question. We've found the problem, but are kind of wondering what is friendliest way to solve it. 32bit float images need some color management to display and convert right. Krita has all that, but ffmpeg doesn't. So if we export exr to ffmpeg, we give supersmooth colors, but ffmpeg will make the colors way too dark because it cannot do that color management. So we can also try to convert it down to 8bit, but then ffmpeg cannot make the super-smooth colors go into the file(though the maximum any video format can have is 10bit per channel... That's about a billion). But, that might be accetable? Because poeple who need to use 32bit float might be quite smart people who might prefer to use the exrs to render in another program. The render they do in Krita might just be tiny example videos. So we're trying to choose between these two.
Git commit b69c194901f915917d6e2be5786ffd6d45fe9cab by Boudewijn Rempt. Committed on 01/03/2017 at 14:52. Pushed by rempt into branch 'master'. Convert floating point channel depths to 8 bit integer when saving PNG As per warning. This also fixes: M +11 -0 libs/ui/kis_png_converter.cpp https://commits.kde.org/krita/b69c194901f915917d6e2be5786ffd6d45fe9cab
Git commit f2292e2528a52f001880425ba94561dbcfd4d4d1 by Boudewijn Rempt. Committed on 01/03/2017 at 14:53. Pushed by rempt into branch 'krita/3.1'. Convert floating point channel depths to 8 bit integer when saving PNG As per warning. This also fixes: M +11 -0 libs/ui/kis_png_converter.cpp https://commits.kde.org/krita/f2292e2528a52f001880425ba94561dbcfd4d4d1