Recherche avancée

Sur d’autres sites (9874)

• convert 16bit grayscale raw video by ffmpeg for analysis in openCV

  15 février 2015, par user3730845

  I have 16bit grayscale stream of scientific data which I want to analyse in openCV. I tried to look for some conversion of data, however it seems that grayscale is a trouble for ffmpeg and available codecs.

  My idea is to use 3 colours of video wisely and stream my grayscales into 3 colours, one by one and then in openCV access each colour and do my analysis there. Is such a thing possible ?

  When I convert stream by : ffmpeg -f rawvideo -y -s 256x256 -pix_fmt gray16be -i rawfile.bin -an -vcodec ffv1 video.avi, I get weird colour space but I can open the result in openCV.

  If there is any other way to do such a thing can you point me towards libraries/howtos, ultimately I need to do thresholding, cross-correlation, edge filtering, centre of gravity types of functions and I need to do this as quickly as possible for datasets of >10GB

  My raw files/streams are set of 256x256 16bit b&w images, with 256 bytes header and gaps

• Revision 3d655805f2 : Use same intra prediction for all block size The commmit changed to use same in

  23 avril 2013, par Yaowu Xu

  Changed Paths :
   Modify /vp9/common/vp9_reconintra.c

  
   Modify /vp9/common/vp9_reconintra4x4.c

  
  
  Use same intra prediction for all block size

  The commmit changed to use same intra prediction function for all
  block sizes.

  Some details on the changes :
  1. All directional modes except DC/TM/V/H now have built-in filtering
  for all pixels with filter taps either (1, 2, 1)/4 or (1, 1)/2.
  2. Above edge get automatic extended to double width (bw*2), which
  makes a lot of the prediciton mode computation simpler.
  3. Same intra prediction function is called with different size
  for i4x4_pred and all other larger size.

  Overall, the change helped keyframe only coding for both cif size
  and std-hd size test sets by .5% consistently on all encodings.
  For normal coding with single/auto key frame, the change now also
  is consistently net positive for all encodings. The overall gains
  is about .15% on std-hd set.

  Change-Id : I01ceb31fbc73d49776262e6bdc06853b03bbd1d1

• New cookie behaviour in browsers may cause regressions

  24 février 2020, par Matomo Core Team — Community, Development

  Last year the Chromium browser team announced they would change their default behaviour for cookies. In particular about a property called samesite. Over the last few months, we have made various changes to our cookie handling to get Matomo ready for this. Depending on your setup and the features you use, some things may not work anymore.

  You can avoid most of the issues by using HTTPS on your Matomo, and ideally also use HTTPS on your website(s).

  If you are not running the latest version of Matomo yet (3.13.3 at the time of writing), then we highly recommend that you upgrade as soon as possible. Previous versions are not compatible with these cookie browser changes.

  Opt out screen

  If you embed the opt out screen on your website running on HTTP, there is a chance the Matomo opt out no longer works. In these cases it may still work over http:

  • when the privacy policy page that embeds the opt out screen (via iframe) also has the Matomo JavaScript tracker embedded,
  • and when both the opt out and the JS tracker point to the same Matomo installation.

  In other cases when HTTP is used, the opt out feature will likely be broken.

  We recommend you test whether the opt out on your site still works by opening your privacy policy page in an incognito browser window. Then test to opt out of tracking, and then reload the page. If the checkbox “You are not opted out. Uncheck this box to opt out.” is still ticked, then your opt out is not working.

  If the opt out is not working anymore, it is most likely due to HTTP being used. In that case you should change the opt out URL to HTTPS. For example change from &lt;iframe src=”<strong>http://</strong>…” to &lt;iframe src=”<strong>https://</strong>...” . If your Matomo doesn’t support HTTPS yet, you will need to contact your webhoster or system administrator to get SSL enabled on your Matomo domain.

  JavaScript tracker

  In most cases, everything related to the JavaScript Tracker will still work as expected.

  But there is an edge case : when you are also reading Matomo’s cookie server side. You may be affected by this edge case issue when :

  • you track part of the user behaviour in the browser (using Matomo JS Tracker),
  • and also track user behavior in your server (for example using one of Matomo SDKs in PHP, Java, Python, C#, etc.).

  In that case, for you to still be able to read the so-called visitorId on your server, we recommend you add this line to your JS tracking code :

  _paq.push([‘setSecureCookie’, location.protocol === 'https:']);

  The cookie can be only retrieved if your website is loaded through HTTPS.

  Should you have any questions, or notice anything isn’t working as expected, please visit our forum.

  Third party cookies

  If you are using third party cookies, using HTTPS on your Matomo is now a requirement to make them work across different domains. Otherwise Chrome and in the near future other browsers would not accept the cookie. If you don’t know if you are using third party cookies or first party cookies, you’re likely using first party cookies and this does not affect you.