https://bugs.kde.org/show_bug.cgi?id=478426
--- Comment #16 from Noah Davis <noaha...@gmail.com> --- (In reply to Niklāvs Koļesņikovs from comment #15) > Crisper screenshots are neat but why pick OpenCV? At least back when I > worked with it about a decade ago, it was mostly a prototyping tool and a > teaching tool for the classroom. > > OpenCV even has a weird BGR internal format which, I note, is still the case > in 2024, since the new code is using RGBA8888 format instead of ARGB32 in an > attempt to work around that limitation (see: > https://invent.kde.org/graphics/spectacle/-/commit/ > 00c90e574ae93b146e703b8f5a7cb6db42fda465#52e7fd6a687cf1a70a640ed6accd701837a2 > 0b5c_385_435 ). It's also worth pointing out that Linux desktop is supposed > to be working towards supporting higher bit depth for HDR purposes, so, yes, > Spectacle will be encountering more than 8 bit color channels soon enough. > > This choice is particularly weird since OpenCV is not known for its scalers, > which is the domain of the libplacebo ( https://libplacebo.org/ ). Please > reconsider? I basically searched "c++ image processing libraries". OpenCV was among the top of the results. I went with OpenCV because: - It seemed to have healthy development (major). - Documentation (API, examples and Q&A website answers) was fairly plentiful (major). - It seemed to have lots of optimizations including hardware acceleration (major). - I wanted a way to apply Gaussian blur to a QImage for another patch (major). - Some other users asked for optical character recognition, which OpenCV has a module for (minor). - Some other KDE projects already used it, so I wouldn't have to ask sysadmin to update the CI (minor). LibVips was almost chosen and I even got it working, but: - The documentation was not great and examples/answers for how to use it were not plentiful. - The source code was hard to follow (GLib stuff with macros is harder than Qt/KDE code for me), so that makes documentation deficiencies harder to deal with. - No OCR. - No other KDE projects using it. I didn't want to spend ages trying different libraries, so I went with OpenCV. The BGR issue doesn't really apply as long as I use RGBA instead of ARGB. It's not as optimal as QImage::Format_ARGB32_Premultiplied for QPainter, but Qt still says it's among the most optimal formats for QPainter. Qt even uses QImage::Format_RGBA8888_Premultiplied for the QImage that QQuickPaintedItem uses internally. RGBA is more compatible with OpenGL, so that's probably why. I'm aware of the growing relevance of HDR on Linux, but I don't have the expertise necessary to deal with that right now. There are probably alternative formats to Format_RGBA8888_Premultiplied that can be used with OpenCV without conversion, but that's a problem for someone™ in the future. I'm not that sure about my choice, so I'm open to other options, but the documentation for libplacebo seems to be very lacking. -- You are receiving this mail because: You are watching all bug changes.
