Re: [Development] QAbstractVideoFilter, the pipeline and QImage

2019-01-08 Thread Jason H
I'm still plugging away at this. My life is being made difficult by not being able to get a pointer to the buffer. For OpenCV, some routines want a color image, others want an 8 bit gray scale. It would be really great if I could use both of these at the same time.

 

For example, take the color video frame, make it gray scale, then run houghLlines on it, using that information to highlight the lines in the color frame. I tried to do this with a simple QMap but there's no way I can access it, because there's no QAbstractBuffer *QVideoFrame::buffer(). I might be able to hack it in using QAbstractPlanarVideoBuffer, but that feels very hacky (plane 0= color, plane2=B) in addition sometimes the type needs to change from quint8s to floats.

 

I feel like I'm really off in the weeds here and would like someone to chime in, if I'm completely missing something or if these are shortcomings in the Qt API?

 

 

Sent: Monday, January 07, 2019 at 5:22 PM
From: "Jason H" 
To: "Jason H" 
Cc: "Pierre-Yves Siret" , "Qt development mailing list" 
Subject: Re: [Development] QAbstractVideoFilter, the pipeline and QImage




I'm trying to implement a QAbstractVideo buffer that uses cv::Mat (or my own custom type, CvMatVideoBuffer or ByteArrayVideoBuffer respectively), but I'm running into a mental block with how this should work. Only map() gives pixel data, I really want a QAbstractVideoBuffer *QVideoFrame::buffer() which I can then cast to my custom type.  Generally when I'm fighting Qt in this way, I'm doing something wrong.

 

I can convert between QImage/cv::Mat with:


cv::Mat qimage_to_mat_cpy(QImage const , bool swap)
{
    return qimage_to_mat_ref(const_cast(img), swap).clone();
}


QImage mat_to_qimage_ref(cv::Mat , QImage::Format format)
{
    return QImage(mat.data, mat.cols, mat.rows, static_cast(mat.step), format);
}

cv::Mat  qimage_to_mat_ref(QImage , int format)
{
    return cv::Mat(img.height(), img.width(), format, img.bits(), img.bytesPerLine());
}



 

Is there an example of how to "properly" use Qt's video pipleline filters, frames, and buffers with OpenCV?  I think there should be class(es) that converts a QVideoFrame to a cv::Mat, and one that converts from cv::Mat to QVideoFrame:

filters: [toMat, blur, sobel, houghLines, toVideoFrame]

 

Many thanks in advance. 

 

 

Sent: Monday, January 07, 2019 at 10:57 AM
From: "Jason H" 
To: "Jason H" 
Cc: "Pierre-Yves Siret" , "Qt development mailing list" 
Subject: Re: [Development] QAbstractVideoFilter, the pipeline and QImage




I have been thinking about this more, and I think we also need to convert when the pipeline switches between internal formats. This would allow standard filter tooklits to be "a thing" for Qt. 

 

For example, if my pipeline filters are written to use QImage (because scanline() and pixel()) , and someone else's use cv::Mat (OpenCV), alternating between formats is not possible in the same pipeline. I think the panacia is to be able to convert not just at the end, but for any step:

[gauss, sobel, houghLines, final] -> formats: [QVideoFrame->cv::Mat, cv::Mat, cv::Mat->QImage, QImage->QVideoFrame] where each format step is the (inputFormat -> outputFormat)

 

Just my 0.02BTC.

 

 

Sent: Wednesday, January 02, 2019 at 12:33 PM
From: "Jason H" 
To: "Pierre-Yves Siret" 
Cc: "Qt development mailing list" 
Subject: Re: [Development] QAbstractVideoFilter, the pipeline and QImage



Thanks for pointing that out. I guess that could work. It's not as elegant as what I want, where everyhing presents the same way. Now each and every filter has to have

 

if (flags & QVideoFilterRunnable::LastInChain) {

   ... generate the frame for the backend per the surfaceFormat

}


 

As there are many surfaceFormats, that if(){} block is huge, and duplicated in each filter. True, I can create a "final filter" that does this to avoid all that boilerpate code that takes the frame and converts it back to what it needs to be. But what I suggested was Qt should provide this automatically both in the filter chain. The difference is this:

 

 

VideoOutput {

   filters: [sobel, houghLines]

}

 


VideoOutput {

   filters: [sobel, houghLines, final]

}

 

Ideally that final filter checks the frame matches what it expects and only if it does not, performs a conversion.  Maybe there's a way to register a conversion from a custom type to a QVideoFrame?

Also, if the VideoOutput is not needed* the final filter need not be invoked.

 

By not needed, I mean the video output element is not visable, or it's area is 0. Sometimes, we want to provide intel about the frames, without affecting them. Currently, this is inherently syncronous, which negatively impacts frame rate.

I should be able to use two (or more) VideoOutputs, one for real-time video display and another for info-only filter pipeline, and these can be distributed across cpu cores. Unfortuantely, the VideoOutput takes over the video source forcing source-output mappings to be 1:1. It would 

Re: [Development] Requesting a repository for shared components between Qt Creator and Qt 3D Studio.

2019-01-08 Thread Thomas Hartmann
Hi,


There is no standalone release planned. This will be a submodule of Qt Creator 
and Qt 3D Studio and part of their releases.


Best Regards,

Thomas Hartmann


From: Development  on behalf of Thiago 
Macieira 
Sent: Tuesday, January 8, 2019 3:21:34 PM
To: development@qt-project.org
Subject: Re: [Development] Requesting a repository for shared components 
between Qt Creator and Qt 3D Studio.

On Monday, 7 January 2019 06:23:47 PST Thomas Hartmann wrote:
> The name of the repository should be 'qtdesigntools' and license of these
> components will be GPLV3. I will be responsible.

What will the release model be for the content there? Will you use submodules
and thus integrate that content as part of the other two's tarballs? Or will
there be full releases?

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development


Re: [Development] Requesting a repository for shared components between Qt Creator and Qt 3D Studio.

2019-01-08 Thread Thiago Macieira
On Monday, 7 January 2019 06:23:47 PST Thomas Hartmann wrote:
> The name of the repository should be 'qtdesigntools' and license of these
> components will be GPLV3. I will be responsible.

What will the release model be for the content there? Will you use submodules 
and thus integrate that content as part of the other two's tarballs? Or will 
there be full releases?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development


Re: [Development] Corrupted ML archive

2019-01-08 Thread André Hartmann

Hi,

The Qt Creator archive seems broken too.

https://lists.qt-project.org/pipermail/qt-creator/2019-January/thread.html 
only contains two mails, but I'm pretty sure there has been more.


Regards,
André

Am 08.01.19 um 12:20 schrieb Edward Welbourne:

On 21/11/2018 13.10, Danila Malyutin wrote:

It looks like [the archive] has lost all mails from 4th of November
up until now. [...]
I don't know if there any mirror/way for someone
not subscribed to this ML to see these mails


Our sysadmins tell me the archive is now repaired.
A cursory look shows, indeed, many mails between the 4th and 21st of
November.  Please check for anything you remember sending in the
interval to verify it has indeed been restored !

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development


[Development] Changes to maintainership of the Qt build system (including qmake)

2019-01-08 Thread Kai Koehne
Hi,

Oswald Buddenhagen has recently left the Qt Company, and also wanted to step 
down from his current maintainership in the build system area. IMO he did a 
tremendous job in maintaining both qmake and the Qt build system in the last 
years, so thank you Ossi! 

This obviously leaves a hole in our list of maintainers. Given that there's no 
natural successor yet who can take over all of the areas, I'm proposing to 
leave the official maintainer role vacant for now.

Anyhow, that doesn't mean that issues won't be triaged or fixed ! For now, 
Joerg Bornemann (joerg.bornem...@qt.io, IRC jobor) and me (kai.koe...@qt.io, 
IRC kkoehne) will take over the handling of the issues in the JIRA components 
"Build System", "Build Tools: Other", and "Build tools: qmake" as part of a 
virtual "Build System Team". This team is now also the default assignee for 
issues in these component. If you feel you can help out in these areas too, 
please reach out to us!

Regards

Kai

PS: We've also a vacant position in this area: 
https://www.qt.io/open-positions/software-engineer-tooling-1543483062

--
Kai Koehne, Senior Manager R | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development


Re: [Development] Requesting a repository for shared components between Qt Creator and Qt 3D Studio.

2019-01-08 Thread Lars Knoll
+1 from my side.

Cheers,
Lars

On 7 Jan 2019, at 16:47, Thomas Hartmann 
mailto:thomas.hartm...@qt.io>> wrote:

Hi,

I am requesting a repository for shared components between Qt Creator and 
Qt3DStudio.

The Qt Company is developing shared components for Qt Quick Designer/Qt Design 
Studio
and Qt3D Studio. The first component we develope is a curve editor for 
animations, but there are more
shared components planned.

The name of the repository should be 'qtdesigntools' and license of these 
components will be GPLV3.
 I will be responsible.

Best Regards,
Thomas Hartmann

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development


Re: [Development] Corrupted ML archive

2019-01-08 Thread Edward Welbourne
On 21/11/2018 13.10, Danila Malyutin wrote:
>> It looks like [the archive] has lost all mails from 4th of November
>> up until now. [...]
>> I don't know if there any mirror/way for someone
>> not subscribed to this ML to see these mails

Our sysadmins tell me the archive is now repaired.
A cursory look shows, indeed, many mails between the 4th and 21st of
November.  Please check for anything you remember sending in the
interval to verify it has indeed been restored !

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development


Re: [Development] [Releasing] HEADS-UP: Branching from '5.12' to '5.12.1' started

2019-01-08 Thread Tuukka Turunen

Thanks, Jani.

I would like to remind that just like with Qt 5.9 LTS, we aim to have frequent 
patch releases of Qt 5.12 LTS. So there is no need to get every possible fix 
into Qt 5.12.1 as the Qt 5.12.2 is anyway coming soon, after that Qt 5.12.3 and 
so on. 

So let's keep pushing bug fixes into the 5.12 branch, it won't be long until 
these are part of a patch level release.

Yours,

Tuukka 

On 08/01/2019, 10.04, "Releasing on behalf of Jani Heikkinen" 
 wrote:

Hi all,

Branching from '5.12' -> '5.12.1' is finally (almost) done; qtbase and 
qttools is  still ongoing, there were some conflicts and so on manual merge + 
normal integration is needed there. Work is ongoing and should be ready today. 

So from now on '5.12.1' is for soon coming Qt 5.12.1 release and staging 
there is restricted to release team only. And '5.12' is for Qt 5.12.2.

Target is to get Qt 5.12.1 out as soon as possible. We will create initial 
changes files soon so please finalize those immediately to be able to proceed 
with the release. Release blocker list here: 
https://bugreports.qt.io/issues/?filter=20430 Please make sure all release 
blockers are visible in the list!

We will release first snapshot for Qt 5.12.1 during this week as well

br,
Jani

From: Development  on behalf of Jani 
Heikkinen 
Sent: Monday, January 7, 2019 7:37 AM
To: Aleksey Kontsevich; ekke; developm...@lists.qt-project.org
Subject: Re: [Development] HEADS-UP: Branching from '5.12' to   '5.12.1'
started

> -Original Message-
> From: Development  On Behalf Of
> Aleksey Kontsevich
> Sent: lauantai 5. tammikuuta 2019 12.23
> To: ekke ; developm...@lists.qt-project.org
> Subject: Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1'
> started
>
> Hi,
>
> What about QTBUG-72687 and QTBUG-72227?
>
QTBUG-72687 or QTBUG-72227 aren't really a release blocker, sorry.

br,
Jani
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Releasing mailing list
releas...@qt-project.org
https://lists.qt-project.org/listinfo/releasing


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development


Re: [Development] New linguist maintainer nomination

2019-01-08 Thread Lars Knoll
> After Ossi stepping down as maintainer for Linguist and related tools 
> (lupdate/lrelease) I would like to propose Kai Koehne to take over. Kai has a 
> long history working on Qt and even more specifically with Qt's translation 
> tools. 

+1 

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development


Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' started

2019-01-08 Thread Jani Heikkinen
Hi all,

Branching from '5.12' -> '5.12.1' is finally (almost) done; qtbase and qttools 
is  still ongoing, there were some conflicts and so on manual merge + normal 
integration is needed there. Work is ongoing and should be ready today. 

So from now on '5.12.1' is for soon coming Qt 5.12.1 release and staging there 
is restricted to release team only. And '5.12' is for Qt 5.12.2.

Target is to get Qt 5.12.1 out as soon as possible. We will create initial 
changes files soon so please finalize those immediately to be able to proceed 
with the release. Release blocker list here: 
https://bugreports.qt.io/issues/?filter=20430 Please make sure all release 
blockers are visible in the list!

We will release first snapshot for Qt 5.12.1 during this week as well

br,
Jani

From: Development  on behalf of Jani 
Heikkinen 
Sent: Monday, January 7, 2019 7:37 AM
To: Aleksey Kontsevich; ekke; developm...@lists.qt-project.org
Subject: Re: [Development] HEADS-UP: Branching from '5.12' to   '5.12.1'
started

> -Original Message-
> From: Development  On Behalf Of
> Aleksey Kontsevich
> Sent: lauantai 5. tammikuuta 2019 12.23
> To: ekke ; developm...@lists.qt-project.org
> Subject: Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1'
> started
>
> Hi,
>
> What about QTBUG-72687 and QTBUG-72227?
>
QTBUG-72687 or QTBUG-72227 aren't really a release blocker, sorry.

br,
Jani
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development