Dispatch visualization

Contains Plotly visualization for simulation results

@bilalshaikh42 Dynamic visualizations should work now once deployed to the K8 cluster. The tests for dispatch-frontend are not passing. I searched about the error it's something related to jest configuration, a lot of people have the same issue online. I  didn't want to change any configuration assuming it would mess up other frontend apps as well. Can you take a look at it?
Otherwise, the PR is ready for review. 3 things remaining on this are:

Handling large JSON
Adding dispatch logging to frontend
Fixing minor bugs

I'll be able to do above 3 tasks better once I test the dynamic visualisations on K8.


RFP - Microsoft OneNote 2016

I am requesting a package to be made for Microsoft OneNote 2016. This is for the better desktop version of the program instead of the crappy limited version that comes with Windows 10. This can be accessed by looking at the page at https://www.onenote.com/download  and ignoring the large obnoxious "Open OneNote" button at the top and instead look under the "Also Available on"  section and click on "Windows Desktop".
I have included the program in a .zip file if it happens to go away.
setuponenotefreeretail.x86.en-us_(1).zip

I am trying to install the package I found on Chocolatey, but it keeps failing with an error:
ERROR: Checksum for 'C:\Users[MyNameRemoved].GIGABYTE-[MyNameRemoved]\AppData\Local\Temp\chocolatey\onenote\16.0.9029.2167\setuponenotefreeretail.x64.en-us_.exe' did not meet 'AEBA2969D2CEBC23BE01B1512AC1AE3CE18E876F00E6E55889F9FE7FECF003C5' for checksum type 'sha256'. Consider passing the actual checksums through with --checksum --checksum64 once you validate the checksums are appropriate. A less secure option is to pass --ignore-checksums if necessary.
The install of onenote was NOT successful.
Error while running 'C:\ProgramData\chocolatey\lib\onenote\tools\chocolateyinstall.ps1'.
See log for details.
Chocolatey installed 0/1 packages. 1 packages failed.
See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).
Failures

onenote (exited -1) - Error while running 'C:\ProgramData\chocolatey\lib\onenote\tools\chocolateyinstall.ps1'.
See log for details.

@Chronoshift111 Can you try reaching out to the package maintainer via the Contact Maintainer link on the package page.


Request for Resolution of Ongoing Issues with Bolt Services

Describe the bug
Dear Bolt team,
I am experiencing ongoing issues with your AI services. Every time I report a code issue, the app remains stuck in a loop of fixes, and the user interface keeps changing without my request.
I would appreciate it if you could focus on resolving the core functionality issues instead of making unnecessary UI changes.
Link to the Bolt URL that caused the error
bolt.new
Steps to reproduce
Focus on Core Issues: Prioritize fixing the reported code issues instead of altering the user interface.
Prevent UI Changes: Ensure that any fixes do not inadvertently change the user interface or functionality that has not been requested.
Clear Communication: Provide regular updates on the status of the reported issues and the steps being taken to resolve them.
Testing Procedures: Implement thorough testing to prevent similar issues from recurring in future updates.
User Feedback: Actively seek and incorporate user feedback before making changes to the app.
Documentation: Maintain clear documentation of changes made and the rationale behind them for transparency.
Expected behavior
Expected Outcome: When I report a code issue, I expect the AI service to address the specific functionality problem without altering the user interface or introducing new issues. The app should operate as intended, maintaining a consistent user experience while resolving the underlying technical issues.
Screen Recording / Screenshot
No response
Platform

OS: [e.g. macOS, Windows, Linux]
Browser: [e.g. Chrome, Safari, Firefox]
Version: [e.g. 91.1]

Additional context

No response

same here, same issues I have spent many tokens and receiving loops answer or unfinished code changes we need an answer from them

same :( I had almost working project, but now I am again at the start - looping the whole day :( and convincing the Bolt to give back the code that was already great and where I did not request any changes.


Most pragmas cannot be set with SQLiteConfig(Properties)

While SQLiteConfig.Pragma lists dozens of possible values, SQLiteConfig(Properties) reads and applies only a handful of those pragmas.
More specifically, "case_sensitive_like" = true cannot be set via properties, which is very unfortunate.
Is this intentional?
Background: the alternative of calling SQLiteConfig#enableCaseSensitiveLike is rather difficult if you also have a connection pooling library and perhaps some abstraction that supports more than one database.

@xerial @gotson would a PR that added general support for setting pragmas with properties be accepted?

My understanding is that it's applied all right.
All the pragma that were not processed before are processed here.

Closing this as no feedback was received.


Profile rename

Last step needed to finally close #85

Codecov Report

Merging #92 into master will decrease coverage by 1.22%.
The diff coverage is 40.69%.

@@            Coverage Diff             @@
##           master      #92      +/-   ##
==========================================
- Coverage   60.37%   59.14%   -1.23%
==========================================
  Files          34       36       +2
  Lines        1229     1312      +83
  Branches       74       76       +2
==========================================
+ Hits          742      776      +34
- Misses        470      518      +48
- Partials       17       18       +1

Impacted Files
Coverage Δ

src/app/core/services/package.service.ts
36.41% <0%> (-0.19%)
:arrow_down:

src/app/profile/services/profile.service.ts
39.07% <27.77%> (-2.11%)
:arrow_down:

src/app/dialogs/services/dialog.service.ts
34% <34%> (ø)

...-profile-dialog/rename-profile-dialog.component.ts
76.47% <76.47%> (ø)

...selection/package-table/package-table.component.ts
49.24% <0%> (+0.75%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c53049f...5815d5b. Read the comment docs.


Update generation commands to use cruft

Now that our collection sync is working, we can recommend cruft over cookiecutter.

Do we need this file in the template, or will the cruft command create it?
https://github.com/PrefectHQ/prefect-great-expectations/blob/main/.cruft.json

Do we need this file in the template, or will the cruft command create it?

Cruft creates that file during generation


Update contributing doc and buttons on readme

I was talking through different scenarios with Alex and thought it might be helpful to write down what I see as the plan for this repo.

Just checking if this is ready to merge?

Umm I should check with @forana again to make sure he's happy with this idea. Probably need to call out the parts that aren't quite there yet too.


Release 1.1.1 updated

 Here is an overview of what got changed by this pull request:

Issues
======
+ Solved 2

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Issues
======
+ Solved 4
- Added 1

Clones added
============
- KumpeHelpers/Helper Utilities/ShowAlert.swift  1

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Issues
======
+ Solved 6

Clones added
============
- KumpeHelpers/Helper Utilities/ShowAlert.swift  1

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Issues
======
+ Solved 7

Clones removed
==============
+ KumpeHelpers/Helper Utilities/ShowAlert.swift  -5

See the complete overview on Codacy


Update version from 0.0.117 to 0.0.118

This is an automated update of version in pyproject.toml. This action is performed by a Github Action from publish.yml.

updated version from 0.0.117 to 0.0.118, @SuleyNL pls review


Update README to correct typo

Missing letter added.

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at<EMAIL_ADDRESS>Thanks!

Thanks @ggamel!


Can't log in

Hi! I tried to log in but during the process said that Apple Music is not available in my country which is, I tried to enable Web Security on config but I can't find it, so I added it on the Advanced section but it does not work. There's a way someone could help?

Duplicate issue, please see #95 for details on troubleshooting.


Logger

IMPORTANT: Please don´t commit to master, we will test your changes first at the beta branch!
1. Tell us something about your changes.
add a logger and compiler class.
logger supports output to stdout and  syslog
profiler has timer to messure execution time of code parts
example for usage will come later in a wiki page.
currently this logger is not used, but now it's there and waiting :-)
2. If this changes affect the .conf file. Please provide the changed section
3. Reference a issue (optional)
Note: For further discussions use our forum: forum.hyperion-project.org

Great work - i genuinely look forward to greppong for all the printf and cout statements !

for those who can't wait:
Logging
use macros in include/utils/logger.h
Don't use the Logger class directly unless there is a good reason to do so.
// *** including
#include <utils/logger.h>

// *** creating
// get a logger, this will create a logger named MAIN with min loglevel INFO, DEBUG messages won't displayed
Logger * log_main = Logger::getInstance("MAIN");

// get a logger, this will create a logger named MAIN with min loglevel DEBUG,  all messages displayed

Logger * log_main = Logger::getInstance("MAIN", Logger::DEBUG);

// *** using
// basic
Debug( log_main, "hello folks!");
Info( log_main, "hello again!");
Warning( log_main, "something is crazy");
Error( log_main, "oh to crazy, aborting");

// a bit mor complex - with printf like format
Info( log_main, "hello %s, you have %d messages", "Dax", 25);

// conditional messages
WarningIf( (value>threshold), log_main, "Alert, your value is greater then %d", threshold );

Profiling
use macros in include/utils/profiler.h
Don't use the Profiler class directly unless there is a good reason to do so.
// *** include
#include "utils/Profiler.h"

//*** messure

// execution time of a block, time from macro name until the scope exists, nested scopes are possible
{
 ... code
PROFILER_BLOCK_EXECUTION_TIME;
 ... code
}

// global time messure withe named timers
// init timer and set start time - name must be uniq!
PROFILER_TIMER_START("SPI timer 1");

// get time until start
PROFILER_TIMER_GET("SPI timer 1");

// get time until start, if condition is fullfiled
PROFILER_TIMER_GET_IF( (transmission_complete == 1), "SPI timer 1");

@redPanther
Pi2 wheezy during compile
/home/pi/hyperion/libsrc/utils/Logger.cpp: In static member function ‘static Logger* Logger::getInstance(std::string, Logger::LogLevel)’:
/home/pi/hyperion/libsrc/utils/Logger.cpp:33:22: error: ‘class std::map<std::basic_string<char>, Logger*>’ has no member named ‘emplace’
libsrc/utils/CMakeFiles/hyperion-utils.dir/build.make:169: recipe for target 'libsrc/utils/CMakeFiles/hyperion-utils.dir/Logger.cpp.o' failed
make[2]: *** [libsrc/utils/CMakeFiles/hyperion-utils.dir/Logger.cpp.o] Error 1
CMakeFiles/Makefile2:967: recipe for target 'libsrc/utils/CMakeFiles/hyperion-utils.dir/all' failed
make[1]: *** [libsrc/utils/CMakeFiles/hyperion-utils.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

fck old debian. emplace is part of c++11 and hyperion use c++11 already. Ok I will replace the emplace with some older stuff. I wish wheezy would die out
http://www.cplusplus.com/reference/map/map/emplace/

We could remove the compatibility for wheezy and move forward, if we just need to workaround again and again :)
Sadly the pi foundation killed wheezy just some months ago.


Using example

Hey, im playing around with the proxy, im trying to put in in between an asterisk box and a sip client, however none of the messages make it through
proxysip % go run . -ip=<IP_ADDRESS>:55600 -dst <IP_ADDRESS>:55600
Nov 10 15:35:56.865082 INF Runtime cpus=8
Nov 10 15:35:56.865839 INF Server routes setuped
Nov 10 15:35:56.866605 INF Http server started address=:8080
Nov 10 15:36:00.598282 WRN Server > SIP request handler not found
Nov 10 15:36:00.598282 WRN Server > SIP request handler not found
Nov 10 15:36:03.683762 ERR RequestWithContext  failed error="udp conn <IP_ADDRESS>:55600 err. write udp <IP_ADDRESS>:55600-><IP_ADDRESS>:55600: sendto: can't assign requested address. transaction transport error"
Nov 10 15:36:04.183834 ERR RequestWithContext  failed error="udp conn <IP_ADDRESS>:55600 err. write udp <IP_ADDRESS>:55600-><IP_ADDRESS>:55600: sendto: can't assign requested address. transaction transport error"
Nov 10 15:36:05.185031 ERR RequestWithContext  failed error="udp conn <IP_ADDRESS>:55600 err. write udp <IP_ADDRESS>:55600-><IP_ADDRESS>:55600: sendto: can't assign requested address. transaction transport error"
Nov 10 15:36:07.188550 ERR RequestWithContext  failed error="udp conn <IP_ADDRESS>:55600 err. write udp <IP_ADDRESS>:55600-><IP_ADDRESS>:55600: sendto: can't assign requested address. transaction transport error"
Nov 10 15:36:10.769874 WRN Server > SIP request handler not found
Nov 10 15:36:11.193927 ERR RequestWithContext  failed error="udp conn <IP_ADDRESS>:55600 err. write udp <IP_ADDRESS>:55600-><IP_ADDRESS>:55600: sendto: can't assign requested address. transaction transport error"

the -ip parameter represents external IP so try using your external inteface IP (non loopback)


Errors using Libcamera Camera Tuning Tool to fix Lens Shading

Hello,
I am trying to achieve Lens Shading Correction for an imx219 camera on Picamera2.
I referred to chapter 6 (Camera Tuning) - https://datasheets.raspberrypi.com/camera/raspberry-pi-camera-guide.pdf and followed the steps to generate a tuning file using ctt.py and two .dng images as input at 5000k.
I generated a tuning file without errors. But when I load the tuning file via Picamera2 api or Libcamera-hello --tuning-file input, I get a segmentation fault error (logs attached below). Seems like it has something to do with the tuning file format generated by ctt.py. I realized that somehow libcamera doesn't accept the headers present in the tuning file generated by ctt.py. If I remove versions, target, and algorithms from my tuning file I was able to apply it correctly. This file has a field for rpi.alsc which I care about the most.
The image generated with the tuning file is different than one generated without the tuning file, but is not lens shading corrected. For a pure white source of light emitted directly into the camera, these are the output images I get:
Raw Image:

Tuned Image:

Seg_fault.txt
Can someone help me use the CTT tool effectively so I can fix lens shading correctly?
My questions are:

Why does the ctt.py tool not generate a tuning-file that I can use as is without modifying it?
Why does the rpi.alsc table generated not correct for lens shading effectively?

Hi, can you attach the tuning file that it made so that we can look at it? Please also attach the output of libcamera-hello --version.
I know that there has been some work recently on adding support for a version 2 tuning file format, so I'm wondering if you might have a version 2 tuning file, but an older libcamera? So maybe also try sudo apt update and sudo apt upgrade and see if that makes any difference. Thanks!

Hey David, thank you for writing back. You may be absolutely right about the version mismatch.
The tuning file that gets generated by the ctt.py tool starts with - version=2.0

Once I modify it to remove the header, it does not give me the segmentation fault error. The modified file looks something like this -

However, doing a sudo apt update and sudo apt upgrade does not help with my libcamera version to match with the tuning file Version 2.0:

I've attached the two tuning files as well, hello.txt is the default file generated. imx219.txt is the modified file that runs without errors but does not produce a white image. The tool generates .json files, converting to .txt so I can upload it here. Is there another way to force match both the CTT tool and Libcamera version?
hello.txt
imx219.txt

Is there another way to force match both the CTT tool and Libcamera version?

The CTT is distributed as part of the libcamera source, so should be in sync with the libcamera library *source".  Are you able to build libcamera libraries manually and install them?  You can find instructions to do that here.

The above imx219.txt file contains only lens shading configuration.  Presumably you are copying this section into a larger tuning file with the rest of the configuration?

Hey Naushir, thank you for looking into this. I tried rebuilding libcamera from the instructions you shared.
In my images folder, I just have images for lens shading and the ctt.py expects both lens shading and macbeth images. So when I run ctt.py it gives me an error saying - ERROR: No usable macbeth chart images found and does not generate a json.
To get around this, I use the script alsc_only.py which seems like a wrapper around ctt.py but for alsc images only. Hence, the imx219.txt that you reviewed has alsc config only. I've tried to apply it both as it is and copying the alsc config block over the uncalibrated.json to create a complete json.
But in both cases, I am still running into the segmentation fault error that I shared initially. The only way I've found to get around this seg fault has been to get rid of these three lines in the json.
    "version": 2.0,     "target": "bcm2835",     "algorithms": [
but the json then isn't effective to correct for lens shading. Here's my libcamera-hello --version after following all the steps from Building Libcamera here

I cannot seen to trace the libcamera version commit 0c55e522 in your build.  Can you share the location of your git tree and the top commit message please?

I'd like to make one extra comment about all this.
The LSC tables in the linked hello.txt are quite different from the standard ones (we've noted often how our standard imx219 modules show very strong colour shading). Anyway, because AWB is calibrated to run after LSC, it means the standard AWB calibration will almost certainly be completely wrong now. This may explain why images are coming out in strange colours.
The "official" answer would be that a complete re-tune is required, you can't just change the LSC tables (at least, not by a very large amount). As a temporary workaround you could find the "bayes" parameter in the tuning file and set it to zero. This will give you simple grey world AWB but in most circumstances you should get a better result. The colour matrices will be wrong too, but that's a less obvious effect than the AWB going haywire (and there too the answer is that a complete re-tune is required).
If you do get this running with the grey world AWB, it would be interesting to know what red and blue gains you have. You could run libcamera-hello -t 0 --info-text "%rg %bg" to see them on the title bar of the preview window.
Out of interest, is this camera going to be running in a controlled environment, or is it likely to be operating in a fairly general range of conditions?

Is there anything more to look at here?  If not, I'll close this down.

Hey David, Naushir,
My sincerest apologies for the delay. I was able to fix the segmentation fault issue by doing these two steps:

Rebuilding libcamera manually by following the steps here.

Running alsc_only.py tool with two raw images captured under a white light. This generates a .json with only alsc correction. I copy and replace the alsc table into the uncalibrated.json file. Now, this .json works for me in terms of segmentation fault. It also has "bayes" set to 0.

In terms of getting a pure white image - this is what I get:
Raw Image:

Using uncalibrated.json under a white light:

So my image is much better, but still not pure white.
Furthermore, when my light source is green, the alsc table does not provide too much of a correction:
Raw:

Using uncalibrated.json under green light

Do I have to input multiple images under different color lights for the alsc table to provide a more accurate correction across color inputs?
To answer your question David - We're using the camera in a controlled environment and our goal is to get true colors. I started pursuing the camera tuning tool for alsc correction because I thought it'd be the quickest. But if you think there's a better way to achieve it, I'm happy to course-correct. I've attached my uncalibrated.json file that generated these images below:
uncalibrated.txt

Do I have to input multiple images under different color lights for the alsc table to provide a more accurate correction across color inputs?

Yes, ideally you want to capture calibration images at a range of colour temperatures, and the algorithm will interpolate between tables based on the current AWB calculated colour temperature.
When you are capturing the LS calibration images, are you pointing the device onto a flat surface, like a wall, or are you using some leds placed into the module lens?

Hey Naushir,
Thank you, let me try giving it more images as input and update this thread. To answer your question - We are using an LED placed under a light diffuser as our input to the camera lens.

@harshilsheth0412 are you able to do a full camera retune (not just the LS block) and report if you are still seeing any issues?

@naushir I assume that by "full camera retune" you mean running the entirety of CTT.py. Unfortunately, we're not able to do this because our camera is, in a sense, trapped. It only points to a diffuser with an LED behind it, so we can't put a lens on it and capture Macbeth color charts. And when CTT.py sees there are no macbeth images, it fails without generating a calibration file...
We are limited by our physical setup. We have an RGB LED pointing at a diffuser, and the camera pointed to the other side of said diffuser. In the past, running PiCameraV1 and Richard Bowman's implementation of Lens Shading, we were able to do the following:

Set the LED to white.
At this point, the camera would capture something like the image below:

The lens shading algorithm knew that it "should" have captured a pure white, uniform image and corrected the color distortion, vignetting, etc by way of a lens shading table.
We would apply that table to all subsequent images captured with the same light source setup, and it worked great.

So we don't actually have a way to modify color temperatures and follow this standard procedure. But shouldn't it be possible to create an adequate lens shading table that achieves this goal for any arbitrary lighting setup?

Otherwise, should we just try creating a "lens shading" file that is the difference between:

a RAW capture of the vignetting + pink and
a pure white image
then applying that to every image we capture?

So for instance, if the camera capture has a pixel at [125, 255, 255], our "lens shading" file would contain [+130, 0, 0] at that pixel, bringing the result to [255, 255, 255] when applied.

The lens shading correction by default provides a roll-off in the correction strength as you go from the centre to the edges of the image.  To stop this and give a fully flat image, you can set "luminance_strength": 1.0 in the rpi.alsc config block.
I assume for your use case, the lighting conditions are fixed?  If so you can also disable the adaptation of the lens shading correction.  This will simply use your calibration table without any adjustments.  To do this, set "n_iter": 0 in the rpi.alsc config block.
Give these a try and see if it helps and we can take it from there.

Hey @naushir,
Yes, our lighting conditions are fixed. We tried moving both the luminance_strength and the n_inter values, and while we see it impacting our image, the tool is probably adding some more correction to prevent a pure white image. Here's our finding for images under white light with the fixed setup that @rarestg described.

So combining both the suggestions you gave, n_iter: 0 and Luminance_strength:1.0 gives us this image-

Also attaching the json we applied to these images.
imx219.txt

By default, the AE will not allow the whole image to reach saturation, so you will not get a full white image.
You can override this by specifying for example --ev 2.0 to force an increased brightness.  Alternatively, if you have fixed lighting, setting --shutter and --gain to some fixed values to your liking would also work.

Hey Naushir,
Setting --ev 2.0 really help with getting a white image.
However, one drawback here is that it also gives out a white image for other light color sources since we're forcing the brightness to be high. So for a green light source, the lens shading table generates a grey image and then forcing --ev 2.0 changes it to white.
Is there a way to retain true colors while performing lens correction such that green can be seen as green?
This is the uncalibrated image:

This is the image after applying the ctt tuning file:

This is the image after forcing --ev 2.0

@harshilsheth0412, I'm afraid you are going to have to help me understand exactly what you are trying to do here from the very beginning.  Could you provide a detailed description along with exact commands you are using to try and achieve this.
Without having much context on your problem, I can only suggest you do not control --ev, and let the AGC converge to it's natural target.  By pushing EV high, you are simply saturating the image to produce white, and in the process losing the actual data in the samples. This is probably not what you want.

Hey Naushir, sure, here's my explanation:
Hardware Setup :

A camera (a combination of imx219 image sensor + a 2.5x objective compound focus lens) fitted vertically facing downwards towards a flat platform. The camera is fixed and placed inside a plastic enclosure.
The flat platform consists of a light diffuser and an RGB LED that is placed under the diffuser. The RGB LED is emitting colored light (white, green blue etc.) vertically going upwards, straight through the diffuser, through the compound lens and onto the imx219 sensor.

Backgroud
Rares and I are working on an application that requires super focused images (think a microscope).
In the past, we worked with the Picamera V1 library where the camera would capture an image like this when the LED was set to white.

Then we would use Richard Bowman's implementation  of the Lens Shading algorithm to correct the color distortion, vignetting etc and get a pure white image. The algorithm would understand that the image should've been a pure white and generates a correction table.
We would then apply the correction table to the picamera library before image capture and we would get a uniform white image for white LED light. This also worked for other RGB color sources from the LED (aka green, blue). Note that the image generated would be white without compromising on the saturation. If I were to add a red dot on top of the diffuser, it would capture the red dot correctly without compromising either red or white.
What we're trying
Now we decided to move to PicameraV2 library which is based on Libcamera. We found the ctt.py tool which from explanation feels like it can do what Bowman's library did for lens shading.

We took 2 images with the same hardware setup under white light

We stored them with the format alsc_XXXXK_1.dng (where XXXX is 4800, 5000).

The two images were similar to the one shown above.

Then we ran ctt.py on the images folder
This failed because the ctt.py file expected both alsc and macbeth images and threw an error: - ERROR: No usable macbeth chart images found
Command used:  ./ctt.py /home/images -o /home/imx219.json

To get around this, we ran alsc_only.py which ran successfully and generated an imx219.json file with only the alsc table.

Command used: ./alsc_only.py -i /home/images -o imx219.json

We couldn't run imx219.json file as it is with the command given below because it would return a Seg Fault error.

Command Used: libcamera-still -r -o result.jpg --tuning-file /home/imx219.json

I manually copy pasted uncalibrated.json file to the imx219.json file so it had all elements of uncalibrated.json + alsc correction table.
Then I ran the following command
command used libcamera-still -r -o result.jpg --tuning-file /home/imx219.json

This generated an image that was grey in color.

At this point we started tuning values in the .json file like n_iter and luminance strength. We also changed --ev and --shutter which helped saturate it to white but we would lose other colors on the image. So if I were to have a red dot on my diffuser, forcing saturation would cause us to lose information which isn't ideal. Also, the setup now doesn't differentiate between white light and green light which won't work for us. We're looking for a clean image for every color without the pink vignetting that's getting added. Then we can apply the correction factor every time we capture an image.
Here's what we see for green:
Raw image using uncalibrated.json :

Image after using imx219.json as --tuning-file :

@harshilsheth0412 thank you for the explanation! I'll start with the following suggestion:

For the shading calibration, you ought to be capturing the images with the camera module placed directly on the LCD, ideally with a diffuser placed in-between.  Are you able to do this?  Additionally, you should take multiple images positioned slightly differently for each colour temperature. This will allow the CTT to average results out.

Once calibrated, you can set shutter and gain to some reasonable values, but ensure you do not saturate the image.  Do not use the ev option.  To get a "pure white" image, you ought to switch to manual white balance, and set the Red/Blue gains appropriately for the colour temperature your LCD emits.  Given your illumination is fixed, I would advise you switch to manual shutter, gain and white balance and disable the auto algorithms entirely.

Hey @naushir, thank you for all the help. We were able to get a non-vignetted pure white image using --shutter 100000 and --gain 1.5.
Here's the command we used:
libcamera-still --tuning-file /home/pi/libcamera/src/ipa/raspberrypi/data/imx219.json --shutter 100000 --gain 1.5
Here's the answer to your questions plus my follow up questions:

Yes, we've placed our Camera Lens Setup directly on top of an RGB LED with a diffuser separating the two. To your point of - take multiple images positioned slightly differently for each colour temperature, we can move our camera lens setup vertically by a few millimeters, so we can capture images positioned differently on the Y axis, however we have no control over determining and controlling the colour temperature. Is there a way around it?

Setting the --shutter was what fixed it for us. So my understanding is that the lens + camera produced a vignetted image because it didn't get enough exposure time and setting the --shutter value helped with that, is that correct?

This may be a Picamera2 question, but I am now trying to emulate the following command into the picamera code using @davidplowman's example here.
The command:
libcamera-still --tuning-file /home/pi/libcamera/src/ipa/raspberrypi/data/imx219.json --shutter 100000 --gain 1.5
My code:
            tuning = Picamera2.load_tuning_file("imx219.json")
            camera = Picamera2(tuning=tuning)
            camera.configure(camera.create_still_configuration(main={"size": (3280, 2464)}))
            algo = Picamera2.find_tuning_algo(tuning, "rpi.agc")
            algo["exposure_modes"]["normal"] = {"shutter": [1000000, 150000], "gain": [1.4, 1.6]}
            camera.start()
            camera.capture_file('test.jpg')
            camera.stop()

But my resultant images are WAY BRIGHTER than what I saw on the command line. Is there some picamera default config that is causing this. I guess this'd be pretty straightforward but maybe my code is missing some basic setup step.
I placed a simple paper with multiple colors colored onto it under my camera and here's the difference between using the libcamera command and picamera.capture_file():
Command image:

Capture File:

Yes, I had the order of setting exposure modes wrong. Works now!!!
Thank you so much folks for all the help and your valuable time! Closing this thread.

Hey @davidplowman, @naushir,
I am reopening this issue to get some more help here. Seems like both the image correction parameters - shutter speed and gain, that worked for me initially provide a true white at the cost of some image data loss, which works when our target capture is well defined, but does not work when we're trying to capture granular details like finer image details under a microscope.
A quick recap:
We're trying to build a microscope using this hardware setup:
Hardware Setup :
A camera (a combination of imx219 image sensor + a 2.5x objective compound focus lens) fitted vertically facing downwards towards a flat platform. The camera is fixed and placed inside a plastic enclosure.
The flat platform consists of a light diffuser and an RGB LED that is placed under the diffuser. The RGB LED is emitting colored light (white, green blue etc.) vertically going upwards, straight through the diffuser, through the compound lens and onto the imx219 sensor.
To get rid of any lens shading that came with this setup, I used the ctt.py tool with one or two images, and as @naushir  suggested, configured the tuning parameters to reflect this:
libcamera-still --tuning-file /home/pi/libcamera/src/ipa/raspberrypi/data/imx219.json --shutter 100000 --gain 1.5
This worked really well when the image under the lens was a colored piece of paper like this:

However, because this device is to act as a microscope, our actual field images require us to capture more granular details, something like this:
This image is a result of only using the camera tuning tool without additional gain or shutter speed adjustments.
Now, any shutter speed over 7500 results in a complete whitening of the image, making it useless. I tried to find the optimum shutter speed and gain (around 4000 and 1.1) but that also results in blurry images and data loss, which isn't ideal for our application.
Based on this, I figured that the best way to get a good white image without losing data is to just use the ctt.py tool and the tuning script it generates and avoid corrections over it. Question is - What inputs do I give it to get an image that's pure white on the edges as well as it is in the centre.

@harshilsheth0412 it sounds like you really ought to switch to manual white balance settings for your use case.  If you have a known fixed colour temperature emitted from you backlight, this likely will give you better results than over-exposing the image to get saturation.  Would you be able to try this with the --awbgains command line argument

Another thought - could the blurriness on the edges be attributed to the lens you have attached?  You may not have seen this effect in the earlier captures because of the lack of fine details.

The colour temperature calibration curve for the imx219 is here. So you can see that the normalised red and blue values (compared to green) for 4600K are 0.6079, 0.6721 (this line). So the gains to try are the reciprocals of these values, i.e. --awb-gains 1.645,1.488. After that you'll probably have to fiddle a bit with trial and error to see what works best for you.

So I tried to fidget around with those two values, but for no value did it seem even close to white.
this is for --awb-gains 1.75, 1.42

I tried a few values from the "ct_curve" list, and it did generate a uniform colored image, just not a uniform white.

Can you provide the exact command line used?

Just wondering very slightly if it's sensitive to the space in between those numbers...?

Just wondering very slightly if it's sensitive to the space in between those numbers...?

That was exactly my thought :)
Trying it out myself - and the parser throws an error if I add a space.

Apologies, I added the space while typing. Here's the copy pasted command I used :)
libcamera-still --tuning-file /home/pi/libcamera/src/ipa/raspberrypi/data/imx219.json --awbgains 1.71,1.44

It might make sense to try and see what the AWB algorithm thinks the gain values ought to be.  If you run
libcamera-still --tuning-file /home/pi/libcamera/src/ipa/raspberrypi/data/imx219.json --info-text "Red: %rg Blue %rg" -t 0

the titlebar should show you what gains AWB has converged to.

That's helpful, the values being used are (0.94,1.36), I think the problem is more with the patchiness of the white as seen on the right side of the image,

Isn't the AWBGAINS more to adjust the overall image red,blue value uniformly across the entire image?

Isn't the AWBGAINS more to adjust the overall image red,blue value uniformly across the entire image?

That's correct, it is applied uniformly across the whole image and in this case, it is giving you your white colour without oversaturating the image data.
The colour around the edges is likely due to not having an accurate lens sharing calibration.  Perhaps this lens produces extreme gains on the edges that we cannot cope with, or perhaps a problem with the calibration procedure? Can you share the table(s) that the CTT has generated?
Are you absolutely sure you are using a 5200K led?  The AWB seem to converge to a completely different value.  @davidplowman assuming there is only a single LS table in the tuning, no interpolation should happen right?  So the AWB detected colour temperature does not matter...?

@davidplowman assuming there is only a single LS table in the tuning, no interpolation should happen right? So the AWB detected colour temperature does not matter...?

Correct. This illumination does seem to have quite high red and blue compared to what we see normally, though I don't think that should matter so long as things as calibrated appropriately.

@naushir, I've attached the correction file that ctt generates below. I used two identical images under the name alsc_5100K_1.dng, alsc_5200K_1.dng. I don't have a way to test the color temperature so I was just relying on an approximate white light that my RGB light emits to be like a white LED Bulb, but yes, from those R and B values, 5200k seems way off. Is there a table that maps all these values to their corresponding color temperatures? Maybe I can reverse engineer the color temp, generate a correction table for the color temp and see if it helps?
imx219.txt

Hey Naushir, unfortunately I don't have the option of changing our lens because of our setup limitations. Is there another way to debug and get to a fully-flat output? Can parse through the generated json and blindly copy a fixed set of center values throughout the table assuming that the center matrix always produces the best white ?

Hey Naushir, unfortunately I don't have the option of changing our lens because of our setup limitations. Is there another way to debug and get to a fully-flat output? Can parse through the generated json and blindly copy a fixed set of center values throughout the table assuming that the center matrix always produces the best white ?

I'm afraid this is not going to work.  Lens shading effects are more extreme on the edges of the image.  The centre coefficients will not correct the edges appropriately.
Can you describe your LED light source a bit more?  Is is in any way adjustable for lux or colour temperature.  Does it require a certain amount to time to become stable for illumination/colour temperature?  Perhaps it is worth keeping the LED on for a period (10mins or more maybe) before taking calibration/test images.  Additionally, are there any external light sources that could be changing?
Would you be able to take a set of DNG calibration images and share them with us?  Ideally, you want to take multiple (2-3)  images with the sensor at 0 degree, 90 degree, 180 degrees, and 270 degrees orientation.

Hey Naushir, here's the LED part number we're using to give you a better idea - ltw-5630azl50. The datasheet suggests the color temperature for our part to be 5000K. We give the light source enough time to settle. Calibration does not happen at bootup, we've tried by letting the LED settle on white for a while (10 minutes) before taking the images but that doesn't help.
The setup is enclosed in a 3D printed black enclosure to prevent any other light from interfering. I can take DNG images yes, but our sensor is fixed so a physical rotation is impossible. Do you mean taking images by just rotating the image using a libcamera --rotation parameter?

The setup is enclosed in a 3D printed black enclosure to prevent any other light from interfering. I can take DNG images yes, but our sensor is fixed so a physical rotation is impossible. Do you mean taking images by just rotating the image using a libcamera --rotation parameter?

Can you rotate the LED in the housing? If you cannot physically rotate the sensor or led, it does not matter much.  Taking multiple images either way would help average out the errors.

If there is nothing further to be done here, I'll close this issue now.

Hi @naushir, a colleague sent me a link to this and I thought I'd chime in: I think you've probably already found most of what I have to say on this topic (a paper and some code) but I will briefly share that I think your problem is not quite what's understood by "camera tuning" because you're not trying to make something that will function well in different conditions.
When I use my microscope, I am trying to answer the question "what is the transmission of my sample", which means I want to cancel out the effect of my illumination. So, I acquire an image with no sample (i.e. it should give 100% transmission) and make sure that calibrates out to white (or at least bright gray, because I don't want saturation anywhere).  Then, images I take should reflect the absorption of the sample, and not the characteristics of my system.
This is a much simpler correction than most cameras do - I am effectively dividing every subsequent image by my initial image, with fixed white balance/exposure/gain/etc. but it's appropriate for a microscope (at least in bright field).  Fixing all those settings also means that a green image should come out green.
Unfortunately, this corrects for less-than-100% transmission of each colour channel, but not for leakage of green light into the red pixels (a result of the CRA compensation on the sensor - described in the paper). That requires not just gain adjustment across the camera, but also a matrix to "unmix" the colours at the edges. This wasn't possible using the old picamera interface (or picamerax, which I hope we can retire soon), but I'd be really interested to know if it's something we could do with the new system. I have not yet had time to get to know it.  Others have mentioned that the three colour channels on your camera are not the full story and that's very true - but unmixing the channels gets you most of the way there if your illumination is fixed.
In short, I would expect that your images could be calibrated to be uniform white with no sample, but that the saturation of the colours will fall off towards the edges. That's something you can correct for in post processing, but not (AFAIK) in real time.
Lastly, when using it for more scientific applications, it may be a good idea to work only with the raw pixel values, if you can cope with the speed penalty. This avoids any nonlinearities that might creep into your system from other processing steps, and puts you in full control. It usually means images look slightly less visually appealing, but personally I am in favour of seeing all the noise then trying to make my measurement, rather than working with already-processed data that may have unexpected artifacts.


Add my word to pats memorial

Maybe wait 2-3 days before merging this in case more people want to contribute.


Implement ADC Driver for Sonata Board

This PR implements an Analogue-to-Digital Converter (ADC) driver for the Sonata Board's Xilinx ADC (XADC).
The relevant documentation can be found on the Sonata System documentation and in the XADC Specification, and is referenced in comments through the driver code.
Sonata's XADC is configured to be initialised with default values that start it in "independent ADC mode", which will by default monitor system internals and sample connected analogue channels. As a result, this driver aims to provide a very simple interface for reading these registers, as well as changing the XADC's clock speed or powering it down so that you can reduce power draw if not using the ADC. I've tried to design the driver so that it should be easily extensible to support more features in the future, so that we can iterate and improve the driver if/as more control is required.
Outdated: ~I've marked this PR as a draft as I'd like some feedback on the way that I'm currently handling the MMIO capability for the ADC. As per the CHERIoT Programmer's Guide, because the complete XADC has a fairly large control structure and I want to avoid defining a C struct covering every single field (many of which are invalid!), I initialise an MMIO_CAPABILITY called registers covering the entire range, which I then access using the class' methods. I can see that in the generic-riscv/platform-plic.hh driver, a setField lambda is used, which might be a nice alternative but might become a bit verbose if setting a lot of fields, and it doesn't allow you to as easily define generic behaviour over the Dynamic Reconfiguration Port (DRP) registers. I'm curious as to others' opinions on what would be a best practice for this in terms of readability.~
The XADC is only present in the most recent 0.4 release (only added a week or so ago), and so I've only added this to the sonata-prerelease.json board description file for now.
I've confirmed that this is working by implementing the following piece of firmware within a single simple compartment:
#include <platform-adc.hh>
#include <debug.hh>
#include <compartment.h>
#include <thread.h>

using Debug = ConditionalDebug<true, "ADC_Testing">;
using SonataAdc = SonataAnalogueDigitalConverter;

[[noreturn]] void __cheri_compartment("adc_test") adc_entry()
{
    SonataAdc::ClockDivider divider = (CPU_TIMER_HZ / SonataAdc::MinClockFrequencyHz) / 2;
    SonataAdc *adc = new SonataAdc(divider, SonataAdc::PowerDownMode::None);

    while (true)
    {
    	Debug::log(
            "ADC A0: {}\t, A1: {}\t, A2: {}\t, A3: {}\t, A4: {}\t, A5: {}\t Temp: {}",
            adc->read_last_measurement(SonataAdc::MeasurementRegister::ArduinoA0),
            adc->read_last_measurement(SonataAdc::MeasurementRegister::ArduinoA1),
            adc->read_last_measurement(SonataAdc::MeasurementRegister::ArduinoA2),
            adc->read_last_measurement(SonataAdc::MeasurementRegister::ArduinoA3),
            adc->read_last_measurement(SonataAdc::MeasurementRegister::ArduinoA4),
            adc->read_last_measurement(SonataAdc::MeasurementRegister::ArduinoA5),
            adc->read_last_measurement(SonataAdc::MeasurementRegister::Temperature)
        );
        thread_millisecond_wait(30);
    }
}

Then, plugging in a power supply to each of the pins A0 through A5 and varying the voltage from 0V to 3.3V I can see the measured voltage being read by the ADC correspondingly vary as expected. Temperature measurement also seems to be consistent with expectations, giving a measurement of around 2600, corresponding to around 46-47°C. Varying the divider to different valid values still measures as expected, and all power down options are behaving as described.

I've rebased on main, made changes to the driver's MMIO access based on the given feedback, and now marked the PR as being ready for review. Running the same tests as in the original post, the ADC driver still seems to be working as intended.


Deprecated OpenCV constants fixed

Hi Robert. I could not build your project with the latest OpenCV version since some of the constants you used have been deprecated and later removed in favor of other ones. I managed to build the project with these changes and it would be great if you could double check that it works for you and merge the pull request.

Thanks for the fix, Dejan! :+1:


Store zone_id in NSEW directions

http://makalo.pe.hu/ezarena-master/adr_zones.php
It seems I'm unable to change zones. Why?

Done.


Block timeline

At the moment this scrolls the selected element into view, but that does not work when synchronising the two views on /planner/graph page. Well, it would without 'smooth' scroll, but then it doesn't feel nice.

Changes are looking good! +1
One thing caught my attention:
When there's a lot of milestones, the page will get cluttered by scrollbars. Is there any way to make this a bit cleaner (while still maintaining the visual cues that they are all scrollable?

I was thinking that its enough that the top view is scrollable, and the bottom view has the scrollbar hidden and just keeps in sync with the top view

For me, the view doesn't scroll to the selected block horizontally. The page only scrolls vertically to the block view component itself, but the block views "internal" horizontal scroll doesnt adjust so that the block is visible.

For me, the view doesn't scroll to the selected block horizontally.

This is due to the synchronisation with the other, and because the timeline has behaviour: smooth on the scroll.
It seem like triggering horizontal scroll on the other prevents the original scrollIntoView from finishing.
Instantaneous scroll worked fine though.
https://github.com/Vincit/VISDOM-Roadmapper/pull/191/files#diff-4a512f36c597da27e59164fb3a7018c40bb875a5723494ce7114b4abb17d0e71R48

              ref={
                index === selected
                  ? (e) => {
                      if (e) {
                        e.parentElement?.parentElement?.scrollTo({
                          top: e.offsetTop,
                          left:
                            e.offsetLeft -
                            e.parentElement.parentElement.offsetLeft,
                          behavior: 'smooth',
                        });
                        console.log(`Scrolling to elem ${e.offsetLeft}`);
                      }
                    }
                  : undefined
              }

This one works for horizontal scrolling, even when synced. I dont know why the original instantenous scrolling worked for you, when I did a bit of googling it seemed that the element.scrollIntoView doesnt even handle horizontal scrolling in the first place

This one works for horizontal scrolling, even when synced. I dont know why the original instantenous scrolling worked, when I did a bit of googling it seemed that the element.scrollIntoView doesnt even handle horizontal scrolling in the first place

https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollIntoView#parameters the inline parameter suggests that it would also handle horizontal positioning...
Finding the correct parent element is simple though, as the BlockView takes inner ref that will be set to the containing div.
Not sure if chaining the refs like that is good though (and not sure how to handle ref object)
        <BlockView
          innerRef={(e) => {
            if (e) ref.current = e;
            if (typeof innerRef === 'function') innerRef(e);
          }}
          {...viewProps}
          className={classes(css.graphInner)}
        >
          {({ item, index, width, height }) => (
            <div
              ref={
                index === selected
                  ? (e) => {
                      if (e) {
                        ref.current?.scrollTo({
                          top: e.offsetTop,
                          left: e.offsetLeft - ref.current.offsetLeft,
                          behavior: 'smooth',
                        });
                      }
                    }
                  : undefined
              }


Create static handler

Convention over configuration
By default, the static handler should be a assets folder in project's root directory, containing 3 subdirectories : scripts, img, stylehseets.
setDirectoryListing to false

created : no inner structure for now, is it important ?


Cannot install Udacimak

Hi, I am unable to download/update udacimak in my windows machine. Previously I tried to download the json files which I had saved but it was not downloading the YT videos. So, I tried to reinstall the toolkit but it didn't work. Please check the terminal print for reference
C:\Users\Rajesh Roy\Documents>npm install -g udacimak
npm WARN deprecated<EMAIL_ADDRESS>request has been deprecated, see https://github.com/request/request/issues/3142
npm WARN deprecated<EMAIL_ADDRESS>node-youtube-dl is deprecated. use `npm.im/youtube-dl-exec` instead.
npm WARN deprecated<EMAIL_ADDRESS>Use cheerio-select instead
npm WARN deprecated<EMAIL_ADDRESS>this library is no longer supported
npm ERR! code EEXIST
npm ERR! path C:\Users\Rajesh Roy\AppData\Roaming\npm\node_modules\udacimak\lib\index.js
npm ERR! dest C:\Users\Rajesh Roy\AppData\Roaming\npm\udacimak.cmd
npm ERR! EEXIST: file already exists, cmd shim 'C:\Users\Rajesh Roy\AppData\Roaming\npm\node_modules\udacimak\lib\index.js' -> 'C:\Users\Rajesh Roy\AppData\Roaming\npm\udacimak.cmd'
npm ERR! File exists: C:\Users\Rajesh Roy\AppData\Roaming\npm\udacimak.cmd
npm ERR! Remove the existing file and try again, or run npm
npm ERR! with --force to overwrite files recklessly.

npm ERR!      C:\Users\Rajesh Roy\AppData\Roaming\npm-cache\_logs\2021-04-04T04_58_59_993Z-debug.log

The log file is certainly of 14000 lines.. let me know whether I should attach it or not

Yes, I am getting similar errors.

I am also getting similar errors.

Hi, is the community still up and running?

I am getting the same error. Any fix?

Is this issue with node version..?


[MRG] use read_raw_fif and not Raw

title says it all
motivation comes from teaching this week to EEG folks trying to do mne.io.Raw on non fif files.

don't review yet.

Coverage decreased (-8.9%) to 81.968% when pulling 6aa5b90fb430502c335f61eca0599987fe291541 on agramfort:use_read_raw_fif into 6cb00360f539c413a79690ec67377e5b920279c2 on mne-tools:master.

@agramfort yes I had exactly the same experience while teaching to EEG people this week :) +1

Coverage decreased (-8.9%) to 81.986% when pulling 6aa5b90fb430502c335f61eca0599987fe291541 on agramfort:use_read_raw_fif into 6cb00360f539c413a79690ec67377e5b920279c2 on mne-tools:master.

ready for review

this was my motivation for writing it :)

LGTM. just noticed that we alternate between using mne.io.read_raw_fif and io.read_raw_fif. do we want them to be consistent or is it fine how it is

It's probably not necessary to unify, not bad to show there are multiple
methods depending on how you import

I also don't mind the forward slashes, probably not worth the effort going
to op.join in all those examples

/ work on windows

ok, cool. merging. thanks @agramfort!


Adding contributor's image list in readme(under Vssoc)

It's there in separate md file just add it to readme.


GAE XMPP support for GCM CCS

What is the desired behavior of the feature? (Be specific!) - Make GAE XMPP API/Service compatible with GCM CCS XMPP

If relevant, why are current approaches or workarounds insufficient? - Current approach/workaround is to use HTTP APIs, which are not as efficient as XMPP. Also CCS XMPP supports bi-directional communication with the client app. In case of HTTP, only downstream is supported. App server has to have a custom implementation for upstream communication.

If relevant, what new use cases will this feature will enable? - Bi-directional messaging with client apps via GCM CCS. A quite a few apps can leverage the robust GCM infrastructure for high performance communication with the client apps from an app hosted on the appengine

P.S.: I was referred to this repo after filing a feature request in GAE repo. https://code.google.com/p/googleappengine/issues/detail?id=12387

:+1:

@dipbhi thanks for submitting your feature request; this issue tracker is mostly for bugs/feature request against the content of the repo. The best way to send feedback for the product is to use the SEND FEEDBACK link that you can find in the docs, e.g. https://developers.google.com/cloud-messaging/

@silvolu it's not easy to know what channel to use...maybe something to improve to avoid this kind of ping-pong? ;-)

@silvolu - thanks for your reply. I will try out the feedback option.
@murrekatt - GAE team closed request on me saying not their problem. GCM team closes the request saying not their code. I guess Google has become too big to be customer friendly, nothing against people replying to my requests though, I appreciate that they are sparing some time to respond.

@dipbhi sorry to hear your frustration; FWIW, I didn't say that it's not our code; I just said that this is not the appropriate channel for product feedback, and pointed you to the appropriate channel.


Exiting minotaur doesn't cleanup workers

I'm running minotaur as a service, and when doing systemctl stop minotaur I need to run minotaur --cleanup to stop workers. Bug?

fixed in master, will be addressed in the next release


Handling swf (flash ads) issue

Some times a swf type ads returns from the server and since I only use HTML5 player. the plugin just try to play the ad and after 15 second the content start play but the controls are disabled and the ad control buttons are shown instead. I think if there is a way to skip playing the ad if its in swf format.

Hi @mirageisme - do you have a sample tag where you're seeing this issue? If you have a tag that only returns SWF, the SDK should notice that there are no compatible ads and fire an error to start playing content - you shouldn't be seeing the 15 second timeout.

@shawnbuso Yes, actually sometimes the VMAP return SWF ads only and yet it tries to play it. here is the VMAP where the issue happens: Sample VMAP
Important note: You need to tell me from which country you are trying to open the link so we add it to the allowed countries.

hi @mirageisme - I'm opening these in the US. I'm seeing the issue you described, but the tag you linked is very complicated so I'm going to need to dive into it a bit to see what the actual issue is. This is what I'm seeing so far:

Ad tag returns a VMAP pre-roll pod with 4 ads
Ad 1

Initial request it to doubleclick

That redirects to adap.tv

That returns a JS VPAID ad (which is supported) that throws an internal error - "An unexpected error occurred within the VPAID creative. Refer to the inner error for more info. Caused by: Error: Error: null"

Ad 2

Doubleclick URL that returns empty VAST

Ad 3

Doubleclick URL that returns empty VAST

Ad 4

Doubleclick URL that returns empty VAST

I'm not sure if what you're seeing is the actual 15 second timeout, or if it's just the amount of time it takes the SDK to make the ~7 network requests it has to make to determine that it doesn't actually have an ad to play.

@shawnbuso Thaks for replaying back so quickly. Yes sometimes it return an empty VAST, it depends on the campaign. But the issue I'm referring too only happens when the ads are redirected to adap.tv and they actually return SWF file and I can see it in the network tab of my browser, the SWF file are fetched but could not be played. so after exactly 15 second the actual media start playing. so I think the 15 second are the timeout.

Do I need to do something special to get that response? I'm seeing the adap.tv redirect, but that points to a JS VPAID ad, not a SWF.

The ads are coming from a 3rd party and we don't have so much control of how they appear. but we prevented them from being requested because we don't support SWF ads.
thanks for the help anyway. If you need any information that could help please u're more than welcome.

I think all I need is a tag that shows the issue :/ Like I said, the sample you provided currently never actually returns a SWF ad that I can see.

I tried to find a SWF ads but unfortunately I could not find one. But here is a URL with a demo player with ads enabled but ad timeout is triggered every time.
Demo: http://competition.mbc.net/shhidhtml5/

Can you confirm that you're using the latest version of the plugin? It
looks like you have a local copy of it, so it may have fallen out of date.
If I plug your tag into our sample
http://googleads.github.io/videojs-ima/examples/advanced/ I see it flip
to content immediately.
Shawn Busolits | Developer Programs Engineer | Interactive Media Ads
SDK | (646)
481-1232
On Sun, May 8, 2016 at 4:53 AM, Mustafa Nabil Dwaikat <
<EMAIL_ADDRESS>wrote:

I tried to find a SWF ads but unfortunately I could not find one. But here
is a URL with a demo player with ads enabled but ad timeout is triggered
every time.
Demo: http://competition.mbc.net/shhidhtml5/
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/googleads/videojs-ima/issues/218#issuecomment-217704333

Can you confirm that you're using the latest version of the plugin? It
looks like you have a local copy of it, so it may have fallen out of date.
If I plug your tag into our sample I see it flip
to content immediately.

I'm currently using version 0.4.0 and yes i'm using a local copy since I use npm package.json to handle dependencies, and I do $ npm update regularly.
Unfortunately I could not provide a SWF ads for you to test sorry about that.

Closing for lack of activity - if you do have a tag that will return a SWF re-open to let me know and I can continue to investigate.


Ensure assemblies listed FileList are not loaded

Fixes #12821
PR Summary
Assemblies listed in FileList of the psd1 should not be loaded when the module is loaded. This change fixes the regression introduced in 6.2.0-preview.2
PR Context
Regression was introduced as a side effect of https://github.com/PowerShell/PowerShell/pull/8073
PR Checklist

[x] PR has a meaningful title

Use the present tense and imperative mood when describing your changes

[x] Summarized changes
[x] Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
[x] This PR is ready to merge and is not Work in Progress.

If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.

Breaking changes

[x] None
OR
[ ] Experimental feature(s) needed

[ ] Experimental feature name(s):

User-facing changes

[x] Not Applicable
OR
[ ] Documentation needed

[ ] Issue filed:

Testing - New and feature

[x] N/A or can only be tested interactively
OR
[ ] Make sure you've added a new test if existing tests do not effectively test the code changed

Tooling

[x] I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
OR
[ ] I have considered the user experience from a tooling perspective and enumerated concerns in the summary. This may include:

Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode (which runs in a different PS Host).
Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.
Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).
Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).

@adityapatwardhan make sure this repros in 7.0.x

@SteveL-MSFT  Do we want to back port this?


debuginfo: Synthesize ORC information

The kernel unwinding mechanism is transparent to us. We don't have to generate the ORC information, nor check for it when using the perf_event_open syscall (or BPF get_stack_id) helpers, which AFAIK use the same mechanisms

I should have clarified more. The idea behind this one was to generate ORC information for the user processes that don't have any unwind information and let the kernel do the unwinding or implement a custom ORC unwinding in eBPF space to the same for user programs since the ORC-based unwinding is simpler to implement.
We can open re-evaluate and open an issue about this when we know more about the space.

I see! Should we then merge it with https://github.com/parca-dev/parca-agent/issues/618? In the end the difference is what's the format we choose, being ORC's, or a custom one, no?

I see! Should we then merge it with #618? In the end the difference is what's the format we choose, being ORC's, or a custom one, no?

Sounds good to me!


Invite creation CRUD in the dashboard

I will start with the community mode of joining since we don't have the different modes yet. Restricting form there based on user roles later seems to make the most sense for me.

[ ] add create invite button

[ ] HTTP endpoint
[ ] outline admindb.InviteService and SQLite schema
[ ] dashboard link
[ ] here is your invite HTML template
[ ] also as JSON for better App integration

[ ] add consume endpoint

[ ] HTTP endpoint
[ ] update active invite token (possible with the public key of the consumee so that the invite creator can follow/allow them)
[ ] returns the tunnel address
[ ] either as a HTML page or ssb-uri redirect depending on the request

Is this done? It seems done

Indeed!


Implement p-hashing method

Implement code to extract image phashes for comparison with each other. #36

closed as this has been implemented by pepe


Try restrict allow origin

Close this one in favor of diving and investigating more at the ticket #472


Add no search results message to search (cache last search term and result count)

In search_view.dart (I think), this is just a matter of adding a Map<String, int> variable to the state, where the String is a search term, and the int is the number of results from the search.
Now, when someone executes a search, check the map to see if the search term exists. If it exists, and the results are 0, show no results. Otherwise, execute the search normally. When results are returned, add or update the search term to the cache with the number of results

In search_view.dart (I think), this is just a matter of adding a Map<String, int> variable to the state, where the String is a search term, and the int is the number of results from the search.
Now, when someone executes a search, check the map to see if the search term exists. If it exists, and the results are 0, show no results. Otherwise, execute the search normally. When results are returned, add or update the search term to the cache with the number of results

My beta branch

My beta branch


Schedule time with existing users to upgrade local testing

Local testing in #135 will break current clusters. This change will prevent future breakages from happening.
@rsignell-usgs @jkellndorfer Giving you the heads up that this is coming in the next week or two. I'll create a PR on your QHub that will manage this transition when it's time to merge the changes.

Sounds good @tylerpotts !     I'm wondering whether we are feeling changes already, as I tried adding a package to my env this morning and the github actions were successful, but no new package appears in my environment.     Is it possible that this package pushed my container size over some limit and there was a failure downstream of the github actions?
Where should I raise this?

@rsignell-usgs sounds like either A) conda environment solve is failing, or B) your conda store is out of space. Solutions for those potential problems:
A) check the latest log file from a user instance in the /home/conda/store/.logs directory. Note that it can take a while (>30 mins) to build complex environments
B) Increase your storage space for conda store in qhub-config.yaml.
Also, I believe that conda store doesn't currently garbage collect (will double check with @costrouc). If that's still the case, the shared NFS volume can fill up quickly with large environments. If you ssh into the pod, you can manually delete all the old environment builds to get more space. This will be a valid step if B) fixes the problem, and I'll write some docs for that if needed

@tylerpotts , does this log from the conda store pod give any clues?

If you ssh into the pod, you can manually delete all the old environment builds to get more space.

Is there an example or doc on how to do that?

that's right, @rsignell-usgs . Essentially started over.

I'm removing the stale tag as this issue raises a good faq to handle conda-store common environment errors.

@viniciusdc The original purpose of this issue is now complete. We were able to help get the USGS cluster destroyed. If you create a new detailing what you mean about conda-store environment errors and permission restrictions we can take it from there.


build fix

@lumber1000 Please, also correct the dependency check task. There is no threshold to vulnerabilities severity configured in the project right now


Release 0.6.2

Codecov Report

Merging #138 (9baaf5a) into main (3b3f2fa) will not change coverage.
The diff coverage is n/a.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #138   +/-   ##
=======================================
  Coverage   23.87%   23.87%
=======================================
  Files          22       22
  Lines        1822     1822
  Branches      910      909    -1
=======================================
  Hits          435      435
  Misses        623      623
  Partials      764      764

@saschagrunert Sorry but can I ask for a release because I have to go to bed?🙏


UnicodeEncodeError when constructing Kiss url

If you call the Kissmetrics python code with a unicode string it blows up because it uses str() to construct a url:
File "/hats/src/kissmetrics/KISSmetrics/__init__.py", line 28, in record
    self.request('e', props)
  File "/hats-0.19.0/hats/src/kissmetrics/KISSmetrics/__init__.py", line 87, in request
    query.append(urllib.quote(str(key)) + '=' + urllib.quote(str(val)))
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-1: ordinal not in range(128)

I am trying to send the username and it doesn't work if the user is using unicode. You guys do support unicode in the url right?

Hi there - any news on this ?

We've merged in some suggested changes from another user. Please let us know if that resolves your issues. Thanks!

Unless I'm mistaken, the fix you applied in Issue #8 isn't going to fix this. You can't pass unicode data into python 2.x urllib which is what you're doing. Here's an example in the python interpreter:
>>> data = {'a': u'田中'}
>>> urllib.urlencode(data)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib.py", line 1281, in urlencode
    v = quote_plus(str(v))
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-1: ordinal not in range(128)

Here's an example in the interpreter using your library:
>>> from settings import KISS_METRICS_API_KEY
>>> from KISSmetrics import KM
>>> km = KM(KISS_METRICS_API_KEY)
>>> km.identify('poswald')
>>> km.record('Signed Up', {'test': u'田中'})

Sure enough, this prints into the log file:
<Wed Nov 30 01:27:18 2011> Could not transmit to trk.kissmetrics.com:8

The Django project recently added code that does something similar.
https://docs.djangoproject.com/en/dev/ref/unicode/#uri-and-iri-handling
https://code.djangoproject.com/browser/django/trunk/django/utils/encoding.py#L132
I'm assuming you want url's to be sent via GET and UTF-8 encoded? Do you guys have any python developers in-house? If so, then please point them to this material and they should be able to figure something out. If you don't have any python devs then I'll try to look into this when I get a chance.
It seems like I don't have permission to reopen this issue but it is still open.


Enter key doesn't work in all apps

Inside F1TV Pro app the enter key doesn't press the selected button, but the button does respond by turning slightly darker for a short moment...
Any suggestions ?

Would it be possible to add a shortcut to press the OK button (the button in the middle of the four direction-buttons on the remote ?

Scrcpy injects the Enter key, how the app reacts is app-specific (and can sometimes be configured, see https://github.com/Genymobile/scrcpy/issues/3157#issuecomment-1122856362).

Would it be possible to add a shortcut to press the OK button

Nope, scrcpy injects keys or mouse events, it could not access the app layout (easily and with good performances).


Add install commands to README

@Steve0x2a @seriouszyx

Fixed by: https://github.com/casdoor/casdoor-python-sdk/pull/12


Avoid failing when delete or rename a branch

The content of #38 has been rebased on current master, it should fix #32 #37 and JENKINS-37500
I've cleaned up the commits from the previous pull requests and added one to prevent the SCM manager to delete any path that doesn't exists in the repository.

This PR is a big deal for us since we are using Jenkins Pipeline with the Github Organization Plugin which creates and deletes nested jobs constantly.
Thanks for your work!

We'd love to see this fix as well, it seems inconsistent but we seem to hit this occasionally even when just deleting "normal" jobs...

I am honestly baffled that such an issue has been discussed from over an year on #32 and it has never seen official feedback from the repository admins. This is a blocker issue that needs to be fixed otherwise the plugin is totally useless.

I think that the right place to complain is the JIRA issue https://issues.jenkins-ci.org/browse/JENKINS-37500

@rodrigc hi! Is there a chance for this PR to be merged and released any time soon?

@rodrigc bump! would really like to add this fix

@rodrigc +1 from me. I have to do the manual workaround daily now.
Is this plugin abandoned? Perhaps you could give it up for adoption.

@rodrigc any eta on this getting merged anytime soon?

@erikhakansson if it's a help for you i've compiled this plugin with the PR applied here:
https://purley.hogarthuk.com/scm-sync-configuration.hpi
replace it with the official one when there's eventually a release of course

Friendly bump. Without this merge this plugin is DOA for any new jenkins projects

Bumping again, confirming this solved our problem and has been working great for use for the past 4 months.

I was wondering why this hasn't been merged yet? We would like to use the multibranch plugin in our current environment that is using the scm sync plugin. If there is something that needs to be done please let us know

The issue is explained in #54
This plugin is orphan, so no one will merge it, unless a new maintainer will arise.

@hogarthj thanks a lot!
in order to fix this issue, you can use the following workaround -

compile your own version of the plugin from this PR (or use @hogarthj version above)
stop jenkins master service
go to $JENKINS_HOME/plugins
Remove the previously expanded plugin directory
Copy the custom HPI file to $JENKINS_HOME/plugins
touch .hpi.pinned
restart your jenkins master

more details on using custom plugin versions here -
https://wiki.jenkins.io/display/JENKINS/Plugin+tutorial

any updates on getting this merged

I have the strong feeling that this plugin is abandoned and this patch will never be merged. I've personally stopped using it in favour of generating the configuration through jenkins-job-builder

@guipal Thanks for looking at this! Hopefully a release can be pushed and bring this plugin back to glory!
@mnencia Merged!

@guipal as you have taken ownership of this plugin, are you able to release a new version now that this has been merged?


Altering python app so that it behaves more like a regular python call

In order to be able to easily make a python script capable of importing gaffer it is important variables like sys.argv have the same value regardless of whether they were called from  "python" or from "gaffer python".
We also want things like return values from the script to be preserved, and that the output from one or the other be similar.
My proposal here is to get rid of the traceback print out, as that was interfering with sys.exit calls, and replacing the return value with "1". That is the behaviour we get if we use python directly.
Also, I'm suggesting we "hack" the sys.argv variable value so that it matches what we'd get from a call to python, as explained in the code:
		# trying to set the sys.argv to the same values as we would expect from a python call
		#
		# the expected gaffer python command line syntax is expected to be:
		#     gaffer python -file <script path> [-arguments <arguments>]
		#
		# given the limitations of the gaffer python app, we can assume that the equivalent python command syntax would be:
		#     python <script path> [<arguments>]
		#
		# python removes the "python" command from the start of the sys.argv list, making the first argument the script path
		# sys.argv should therefore be:
		#     [<script path>] + [<arguments>]
		#
		# sys.argv is assumed to be the base source of information for python argument parsing methods (argparse, getopt, ...)

This is changing the existing behaviour of the gaffer python app, but I'm not aware of any uses, so maybe it would be ok to not preserve full backward compatibility. But if that is an issue, we could create a different app with the changes I'm suggesting (possibly internal to IE).
Note that I'm still passing the argv variable (with an IECore.StringVectorData) as before, as that is not part of regular python.
There is another change that we may consider, which is to alter the __name__ python variable.
When running python with a script, you get that set to __main__. Using the gaffer python app we get __builtin__. Maybe we should set it to __main__? But changing existing code to support both is not difficult, and there could be reasons to keep it as __builtin__ that I'm not aware of.

I like the idea of catching the SystemExit and returning that result as the result for the application. I'll look into that.
And, as the change in the sys.argv value is a requirement right now, I'll also look into implementing the threadsafe-argv-clobbering as well. If it turns out to be too complicated, we'd need to go with a IE-specific application.

Just to clarify, I'm OK with thread-unsafe argv clobbering in Gaffer for now if we stick in a comment about the potential issue. Since we don't currently use the python app inside the same processes as others, I think getting your other improvements into Gaffer is preferable over maintaining something internal to IE in this case.

I've just updated the pull request with your suggestions.
About the thread-safe argv changes, I was able to get something to work, wrapping the list class using the metaclass feature in python, but it seemed like something that could potentially be more problematic than the issue we were trying to address, specially given how unlikely it is that we'd have that app running on a thread.
One think to keep in mind is that even if the thread-safe sys.argv was implemented using a method similar to the one you described (using threading.local), it would potentially cause a generic python script to break if you actually wanted to change the sys.argv from a thread. Very, very unlikely, I know, but still a theoretical possibility...
Anyway, I've updated the comments to include a note that it is not thread-safe, and why we decided to ignore it.

Great - thanks Ivan. I didn't know that finally blocks also get executed from return statements inside the try, so I learned something. The metaclass thing sounds ingenious - good to know there's an option there should it become a real issue.
Just one small note for the future - it's very helpful to me if the first line of the commit message contains some context ("the python app" in this case). It really helps when compiling release notes and trawling back through the history to find problems.


[travis] add setuptools to requirements.txt

The Python 2.7 builds are bombing:
ImportError: No module named 'setuptools'

Well, that failed miserably..

Something looks a bit fishy in this build which is supposedly against python 2.7:
https://travis-ci.org/mikeboers/PyAV/jobs/430275109
I see:
PYAV_PYTHON=python3

The commit that seems to have broken the build is : d31e902c948b71c98b2d023422ad72eff1d602a1

The test suite now passes on Travis! This also fixed the build on appveyor for Python 2.7, only 3.5/Windows remains broken.

I'm so OK with merging it, that I just did it. 😁


Resource: Environment Feature (Install pending update Wave)

Possible implementation
resource powerplatform_environment_feature {
  environment_id = "<guid>"
  feature_name = "April2024Update"
  enabled = true
}

API
https://api.admin.powerplatform.microsoft.com/api/environments/${envId}/features/${featureName}/enable?geo=Na

I think this should be a module using powerplatform_rest resource, because then in the future, in the same module we can encapsulate org level FCB features adding them to /api/data/v9.0/organizations clientfeatureset attribute
@mattdot


daycomics

Source name
daycomics.com
Source link
https://daycomics.com/
Source language
English
Other details
18+
Acknowledgements

[X] I have checked that the extension does not already exist by searching the extension listing and verified it does not appear there.
[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a meaningful title with the source name.
[X] I will fill out all of the requested information in this form.

Man its not ever a duplicate...just trying to ask a question...

Ik..


[Enhancement]: The first page can be improved.

Hello, I am Anshika, GSSoC'24 contributor. The first page of the application starts the game by clicking anywhere on the screen.

It can be enhanced by adding a start button in the middle (that space looks empty too) and only starting when the button is clicked. This would lead to more concise and professional gaming experience.
Kindly assign me this issue and I'll get to it right now.

I mean whenever we click anywhere on the screen, including the yellow part, the game starts. Instead, there should be a particular button on the central rectangular screen for starting the game. We can make a new START button in the centre vacant space. The game should start only on clicking on the particular button, instead of the whole screen.

Hey @Durgesh4993 Please assign this task to me.

Hey @Durgesh4993 Please assign this task to me