Recorder docker technicalities and missing features

I mentioned it because when I did the initial test, I did a recording, then clicked on export. The docker seemed to be going through the motions - but didn’t let me know there was a problem (no ffmpeg); So I was sat waiting for it to finish when it wasn’t doing anything… :blush:

1 Like

At this moment ffmpeg is not required to record, it only exports the recording (i.e. joining all the saved JPEG snapshots to the video together)…

As I understand, you pressed “Export…” button on docker, then “Export Timelapse” dialog appeared, you pressed “Export” button, the progress bar with “0%” appeared and… froze, correct? This may be caused by different reasons: incompatible version of ffmpeg, or some platform-specific thing…

If ffmpeg is missing the dialog won’t let you export the video (Export button should be disabled). Can you see a small checkmark symbol to the right side of ffmpeg path field? There is some info about ffmpeg if you hover the mouse cursor.

I couldn’t remember specifically, so I’ve just uninstalled ffmpeg to try and replicate what I did:

In the export options, the ffmpeg field is blank with a red X. If I hover over the folder icon next to it says ‘setup ffmpeg executable location’.

The export button is active and clickable; the processing dialogue opens (but doesn’t do anything):

Screenshot from 2021-05-13 23-01-01

I don’t actually think it’s much of a problem; just if someone tries to use it without much experience, they might not understand why it’s not working without an explicit message to warm them of the missing dependency.

But then - if they’re digging into the options to find and use the recorder, they’re probably savvy enough to figure it out. :man_shrugging:

1 Like

Thank you for clarification, need to fix the “Export” button then, it doesn’t work as intended. Also adding some clarification message would be a good idea.

1 Like

@wolthera can you say the class name of fast krita png encoder? I wasn’t able to find something similar.

It’s kis_png_converter. Here’s an example of the usage for when we generate mergedimage.png for the kra files: plugins/impex/libkra/kis_kra_saver.cpp · master · Graphics / Krita · GitLab

You will proly want to use ‘buildFile’ or ‘buildImage’ instead however, given you’re not compressing them into a zip file.

1 Like

I did a small benchmark using KisPNGConverter you mentioned, but it doesn’t look significantly faster than QT PNG, actually it’s slightly slower. In the test 1 jpeg and 2 png was enabled. Canvas was freezing for seconds, probably because of lock/unlock while buildFile is running… If the lock/unlock is omitted, the captured image sometimes have strong artifacts.

Here is comparation of the current implementation of JPEG with Qt PNG, and KisPNGConverter.

The numbers is the writing time of the corresponding file in milliseconds

JPEG TIME:  101 QPNG TIME:  3580 KPNG TIME:  4001
JPEG TIME:  80 QPNG TIME:  3390 KPNG TIME:  3826
JPEG TIME:  81 QPNG TIME:  3313 KPNG TIME:  4115
JPEG TIME:  88 QPNG TIME:  3581 KPNG TIME:  4255
JPEG TIME:  84 QPNG TIME:  3826 KPNG TIME:  4253
JPEG TIME:  82 QPNG TIME:  3595 KPNG TIME:  4259
JPEG TIME:  89 QPNG TIME:  3622 KPNG TIME:  4119
JPEG TIME:  75 QPNG TIME:  3745 KPNG TIME:  4307

AVG         85             3581.5           4141.9

AVERAGE encoding time per frame:
JPEG: 0.085 second
QT PNG: 3.58 second
KisPNGConverter: 4.14 seconds

Here is the code I did for benchmarking (did I do something wrong?)

KisPNGConverter pngConverter { 0 };

bool writeFrame()
{
    if (!outputDir.exists() && !outputDir.mkpath(settings.outputDirectory))
        return false;


    KisPNGOptions options;

    options.alpha = true;
    options.interlace = false;
    options.compression = 5;
    options.tryToSaveAsIndexed = false;
    options.transparencyFillColor = QColor(0,0,0);
    options.saveSRGBProfile = true;                 //TVPaint can use only sRGB
    options.forceSRGB = false;

    auto image = canvas->image();
    KisPaintDeviceSP device = image->projection();


    QElapsedTimer timer;

    const QString &fileName = QString("%1%2")
                                  .arg(settings.outputDirectory)
                                  .arg(partIndex, 7, 10, QLatin1Char('0'));

    timer.start();
    frame.save(fileName % ".jpg", "JPEG", settings.quality);
    qint64 jpegTime = timer.elapsed();

    frame.save(fileName % ".png", "PNG", 50);
    qint64 qpngTime = timer.restart();

    image->lock();
    pngConverter.buildFile(fileName % "_k.png",
                           image->bounds(),
                           image->xRes(), image->yRes(), device,
                           image->beginAnnotations(), image->endAnnotations(),
                           options, nullptr);
    image->unlock();
    qint64 kpngTime = timer.restart();

    qDebug()
        << "JPEG TIME: " << jpegTime
        << "QPNG TIME: " << qpngTime
        << "KPNG TIME: " << kpngTime;

    return true;
}

Example of snapshots: KisPNGConverter-benchmark – Google Drive

A post was merged into an existing topic: how do you make art?

Ah, pity. It’s something I seemed to recall from the past that it was really fast, but maybe we did a thing that made PNG encoding more heavy in the meantime. :confused:

I think it is possible to speed things up by copying the image, but that might be a tad much.

Yes I have noticed the delay when exporting too.

Hm 85ms are 0.085s, not 0.85s…
not sure which one is correct.

Anyway, deflate (the compression method as used by PNG) isn’t exactly known for great compression speed, and zlib in particular also gets much slower above level 3.

I don’t know if it’s important to have compression, you could just try compression level 0, which should disable compression. Libpng may still waste some time trying to figure out a filtering method though, the documentation is not really clear what it does by default…

1 Like

85ms=0.085s yes

Well, adding PNG support as a storage with Qt PNG encoder looks pretty easy for me to implement. The only thing… We should warn user regarding choosing compression level outside of levels 1…3 (10-30% for Qt encoder) somehow. Like zero is a waste of disk space and 4+ may lead to lack of performance and freezes.

Or maybe just use pre-defined compression level like “2” and hide the “Quality” bar?

Yeah, we can iterate on that later.

1 Like

For information, the Export button is now disabled in case of FFMpeg is not detected, also some useful info is shown when you hover the X mark. This is merged to master branch a hour ago.

2 Likes

Oh! Cool! :slightly_smiling_face::+1:

I faced the similar issue today. I’ve been recording timelapse and decided to save incremental version.

After this the document creation time was changed internally and recorder detected it as a new document and created a new dir for it. I believe this was introduced recently, because I tested recorder with incremental save before and it worked well.

As I noticed the document creation time is only changed in runtime (feels like bug for me because creation time shouldn’t be changed anyway), and if you re-load document with newest incremental version you will get the original timestamp.

1 Like

I think that should be reported to bugs.kde.org

1 Like

Sure but I tried to reproduce this case few times later, and… looks like there are some other circumstances as well…

So… here is PNG support. I only did a smoke test, haven’t performed some deep testing.

Now per-document settings are even more desirable, because if you have two open docs and want to record one in JPEG and second in PNG, you cannot do that. All the docs are recorded in the same format.

Also I’m thinking about disabling the change of recorder settings once when timelapse is started to write, to prevent the occasional change of settings which cause the broken timelapse.

2 Likes