分类目录归档：未分类

无损压缩算法

https://dzone.com/articles/crunch-time-10-best-compression-algorithms

1. LZ77

2. LZR

3. LZSS

4. DEFLATE

5. LZMA

6. LZMA2

4种基于深度学习的图像/视频压缩算法

除了上面介绍的静态压缩算法，还有基于深度学习的压缩算法可供选择。

4种基于深度学习的图像/视频压缩算法

除了上面介绍的静态压缩算法，还有基于深度学习的压缩算法可供选择。

1. 基于多层感知机的压缩算法

多层感知机(Multi-Layer Perceptron，MLP)技术使用多层神经元来获取、处理以及输出数据。它能够被应用到数据降维任务和数据压缩。首个基于MLP的算法于1988年被提出，目前已经被应用到：

  • 二进制编码——标准的双符号编码
  • 量化——限制从连续集到离散集的输入
  • 特定领域内的转换——像素级的数据变更

MLP算法利用分解神经网络上一步的输出来确定最佳的二进制码组合。后面，使用预测技术优化这个方法。预测技术能够通过反向传播基于相邻数据来提升数据准确度。

2. DeepCoder — 基于视频压缩的深度神经网络

DeepCoder是一个基于卷积神经网络(CNN)的框架，它是传统视频压缩技术的替代。该模型为预测信号和残留信号使用单独的CNN。它使用标量量化技术和一个传统的文件压缩算法——霍夫曼编码——将编码特征映射到一个二进制流中。一般认为，该模型的性能要优于著名的H.264/AVC视频编码规范。

3. 基于CNN的压缩算法

CNN是分层的神经网络，通常用于图像识别和特征检测。当应用到压缩时，这些神经网络使用卷积操作来计算相邻像素点之间的相关性。CNN展示出了比基于MLP算法更好的压缩结果，提升了超分辨率下的性能以及减少了伪影。另外，基于CNN的压缩还提升了JPEG图像的品质，因为它减少了峰值信噪比(PSNR)和结构相似性(SSIM)。基于CNN的压缩通过使用熵估计法还实现了HEVC的性能。

4. 基于生成式对抗网络(GAN)的压缩算法

GAN属于神经网络的一种，它使用两个神经网络彼此竞争的方式来产生更精确的分析和预测。最早基于GAN的压缩算法于2017年被提出。这些算法的文件压缩比例是其他常见方法(如JPEG、WebP等)的2.5倍。你可以使用基于GAN的方法通过并行化处理来实现实时压缩。主要的原理是基于最相关的特征来压缩图片。当解码的时候，算法基于这些特征来重建图像。和基于CNN算法相比，基于GAN的压缩算法通过消除对抗损失能够产生更高品质的图像。

添加公钥后报错:sign_and_send_pubkey: signing failed: agent refused operation

添加完报上述错误，该执行如何指令：

eval "$(ssh-agent -s)" >> /dev/null
ssh-add >> /dev/null
如果不将输出输至空设备或其它文件时，会导致SFTP无法登录。


第一种方法：在 vim ~/.bashrc文件尾部添加如下代码，可永久解决问题。

export SSH_AUTH_SOCK=0      #这样则可以永久屏蔽gnome-key的SOCK_AUTH_SOCK的干扰，此时执行ssh xxx@yyy.com时，则可以成功登录。

QLocalSocket和QTcpSocket混用，会影响QTcpSocket的性能吗？

Qt的LocalSocket是基于PIPE实现的，且PIPE的缓冲区被设置为0。

为什么被设置为0呢？它文档说是数据在管道没有被关闭前取出，会导致数据丢失，故在创建时设置其缓冲区为0。那它是如何优化性能呢？它是利用OVERLAPPED_COMPLETION_ROUTINE的能力实现的。无限异步调用ReadFileEx(PIPE)，当数据到达缓冲区后，取回数据又再调用，从而实现数据的快速读取。写入数据呢？也是相似的方法。

那它与QTcpSocket混用是否会影响性能吗？在实际P2P模式压测试下，PIPE的传输效率为每秒5M字节左右，QTcpSocket为14M字节，这压测是在发送1M数据回复一个ACK然后再发送1M数据下取得的结果。

QTcpSocket虽效率高，但占用CPU也相应高，QLocalSocket虽然是低很多，但CPU占用低。
在实际的复杂的网络环境下，其也满足使用。

Qt的QLocalSocket性能高吗

Qt的LocalSocket在Window中是基于Pipe实现的，而Linux中是基于UnixSocket实现的。
按说pipe的性能是不错的，但Qt比较坑，它的内部缓冲区是0，故形成一个阻塞操作，再加上是基于Event事件唤醒，性能整体就比较低下，没有Socket的高。
此事件的使用是与窗口消息共用同一个线程的，为了不影响其它消息的正常处理，它采用WaiForMutipleObject的方法，但等待时间为0，故会出现缓慢。
那Linux呢，是否可以使用呢？也不建议使用，原因是它的缓存只有64K，小数据传送，其效率是比较高的，但大数据传输时，就会出现阻塞的情况，这也影响的整体性能表现。

转：电话号码正则

正则表达式如下：
^1([358][0-9]|4[579]|66|7[0135678]|9[89])[0-9]{8}$

目前匹配号段

中国电信号段
133、149、153、173、177、180、181、189、199
中国联通号段
130、131、132、145、155、156、166、175、176、185、186

中国移动号段
134(0-8)、135、136、137、138、139、147、150、151、152、157、158、159、178、182、183、184、187、188、198

其他号段
14号段以前为上网卡专属号段，如中国联通的是145，中国移动的是147等等。

虚拟运营商

电信：1700、1701、1702

移动：1703、1705、1706

联通：1704、1707、1708、1709、171

Qt执行带管道的命令差异

在Window中执行管道命令时，由于双引号或参数分割或合并的原因是无法执行的，例如以下这条命令：
cmd.exe /c netstat -ano|find “80”|find “62499”
也正因为Window的差异，故Qt提供了一个特殊函数：void QProcess::setNativeArguments(const QString &arguments)
具体执行如下：

#if defined(Q_OS_WIN)
    QString cmd = QString("/c netstat -ano|find \"80\"|find \"%1\"").arg(port);
    qDebug() << "onConnected" << cmd;
    proc->setNativeArguments(cmd);
    proc->start("cmd.exe");
#elif defined(Q_OS_MAC)
    QStringList args;
    args << "-c" << QString("netstat -nat|grep %1|grep 80").arg(port);
    proc->start("/bin/bash", args);
#else
    QStringList args;
    args << "-c" << QString("netstat -ntp|grep %1|grep 80").arg(port);
    proc->start("/bin/bash", args);
#endif

Fix qt5_generate_repc BUG 

macro(qt5_generate_myrepc outfiles infile outputtype)
    # get include dirs and flags
    get_filename_component(abs_infile ${infile} ABSOLUTE)
    get_filename_component(infile_name "${infile}" NAME)
    string(REPLACE ".rep" "" _infile_base ${infile_name})
    if(${outputtype} STREQUAL "SOURCE")
        set(_outfile_base "rep_${_infile_base}_source")
        set(_repc_args -o source)
    elseif(${outputtype} STREQUAL "MERGED")
            set(_outfile_base "rep_${_infile_base}_merged")
            set(_repc_args -o merged)
    else()
        set(_outfile_base "rep_${_infile_base}_replica")
        set(_repc_args -o replica)
    endif()
    set(_outfile_header "${CMAKE_CURRENT_BINARY_DIR}/${_outfile_base}.h")
    add_custom_command(OUTPUT ${_outfile_header}
        DEPENDS ${abs_infile}
        COMMAND ${Qt5RemoteObjects_REPC_EXECUTABLE} ${abs_infile} ${_repc_args} ${_outfile_header}
        VERBATIM)
    set_source_files_properties(${_outfile_header} PROPERTIES GENERATED TRUE)

    qt5_get_moc_flags(_moc_flags)
    # Make sure we get the compiler flags from the Qt5::RemoteObjects target (for includes)
    # (code adapted from QT5_GET_MOC_FLAGS)
    foreach(_current ${Qt5RemoteObjects_INCLUDE_DIRS})
        if("${_current}" MATCHES "\\.framework/?$")
            string(REGEX REPLACE "/[^/]+\\.framework" "" framework_path "${_current}")
            set(_moc_flags ${_moc_flags} "-F${framework_path}")
        else()
            set(_moc_flags ${_moc_flags} "-I${_current}")
        endif()
    endforeach()

    set(_moc_outfile "${CMAKE_CURRENT_BINARY_DIR}/moc_${_outfile_base}.cpp")
    qt5_create_moc_command(${_outfile_header} ${_moc_outfile} "${_moc_flags}" "" "" "")
    list(APPEND ${outfiles} "${_outfile_header}" ${_moc_outfile})
endmacro()

qt5_generate_repc是不支持MERGED特性的，但命令行是已经支持了。故自定议qt5_generate_myrepc函数。

https://doc.qt.io/qt-5/qtremoteobjects-repc.html

linux keycode less and greater

字符串为 < 和 > 在以前的键盘中，映射方式是不一样的。因此可能需要重新设备键位，解决不一致的问题。在老的键盘中，<和>两个字符是在同一个键上的，故在XDisplay中容易出现输入<却显示>的奇怪问题。
xmodmap -e ‘keycode 94 = comma less’