[Bug]: mask issue with inpaint if inpaint_only+lama selected

What happened?
When I try to use openOutpaint with control_v11p_sd15_inpaint and inpaint_only+lama selected, it generates errors in the stable-diffusion-webui console window and the controlnet preprocessing is bypassed.  If I run it without a mask it seems to execute without issue.
2023-09-06 12:09:34,155 - ControlNet - INFO - Loading model: control_v11p_sd15_inpaint [ebff9138]
2023-09-06 12:09:34,666 - ControlNet - INFO - Loaded state_dict from [W:\stable-diffusion-webui\webui\models\ControlNet\control_v11p_sd15_inpaint.pth]
2023-09-06 12:09:34,666 - ControlNet - INFO - controlnet_default_config
2023-09-06 12:09:37,784 - ControlNet - INFO - ControlNet model control_v11p_sd15_inpaint [ebff9138] loaded.
2023-09-06 12:09:37,928 - ControlNet - INFO - Loading preprocessor: inpaint_only+lama
2023-09-06 12:09:37,928 - ControlNet - INFO - preprocessor resolution = 64
*** Error running before_process_batch: W:\stable-diffusion-webui\webui\extensions\sd-webui-controlnet\scripts\controlnet.py
    Traceback (most recent call last):
      File "W:\stable-diffusion-webui\webui\modules\scripts.py", line 627, in before_process_batch
        script.before_process_batch(p, *script_args, **kwargs)
      File "W:\stable-diffusion-webui\webui\extensions\sd-webui-controlnet\scripts\controlnet.py", line 972, in before_process_batch
        self.controlnet_main_entry(p)
      File "W:\stable-diffusion-webui\webui\extensions\sd-webui-controlnet\scripts\controlnet.py", line 808, in controlnet_main_entry
        detected_map, is_image = preprocessor(
      File "W:\stable-diffusion-webui\webui\extensions\sd-webui-controlnet\scripts\utils.py", line 75, in decorated_func
        return cached_func(*args, **kwargs)
      File "W:\stable-diffusion-webui\webui\extensions\sd-webui-controlnet\scripts\utils.py", line 63, in cached_func
        return func(*args, **kwargs)
      File "W:\stable-diffusion-webui\webui\extensions\sd-webui-controlnet\scripts\global_state.py", line 35, in unified_preprocessor
        return preprocessor_modules[preprocessor_name](*args, **kwargs)
      File "W:\stable-diffusion-webui\webui\extensions\sd-webui-controlnet\scripts\processor.py", line 489, in lama_inpaint
        prd_color = model_lama(img_res)
      File "W:\stable-diffusion-webui\webui\extensions\sd-webui-controlnet\annotator\lama\__init__.py", line 51, in __call__
        color = color * (1 - mask)
    RuntimeError: The size of tensor a (3) must match the size of tensor b (0) at non-singleton dimension 2

Steps to reproduce the problem

expand "Extensions"
check "ControlNet In/Outpainting"
Set "Inpaint Preprocessor" to inpaint_only+lama
Set "Model" to control_v11p_sd15_inpaint
Stable Diffusion settings, all boxes unchecked, resolution=512, steps=30, CFG Scale=5, Batch=2, Iterations=2, Mask blur=4
Draw a mask on image
Activate Img2img, select area that includes mask
check stable-diffusion-webui console window for errors

What should have happened?
Errors should not have occurred and things should proceed as expected
Commit where the problem happens
2f3c65e
What platforms do you use to access openOutpaint?
Windows
What browsers do you use to access the UI ?
Other (please list in additional information)
Browser Extensions/Addons
Vivaldi 6.2.3105.45 (blocking disabled for 127.0.01)

Script Safe (disabled for <IP_ADDRESS>)
UBlock Origin (disabled for <IP_ADDRESS>)
Privacy Badger (disabled for <IP_ADDRESS>)
Tampermonkey  (no scripts loaded for <IP_ADDRESS>)

AUTOMATIC1111 webUI Commandline Arguments
--upcast-sampling --api --no-half-vae --xformers --medvram --cors-allow-origins *
Additional information
NOTE: inpaint_only+lama works fine using the standard inpaint interface

I just realized it works if "Sync cursor size is checked". Is it possible the mask image isn't being scaled? when Resolution != Cursor Size?

disclaimer: apologies for the extended delay, my brain is terrible and you shouldn't expect much from me
haven't gotten to reproduce this yet? will continue poking, it's highly likely something is indeed broken with extension support because it's extra jank as mentioned


smarter logical combination that keeps truthy/falsy/nullish property

Description
Allows to handle if (unknown && falsy) if (unknown || truthy) if (unknown ?? nullish) in static analysis.
Hint: review each commit on it's own, since the first commit is only changing to a named struct.
Testing Instructions

Allows to handle if (unknown && falsy) if (unknown || truthy) if (unknown ?? nullish) in static analysis.

Which cases were handled before this PR?
Just if (falsy) if (truthy) if (nullish)?
Does this also handle if (unknown && falsy && unknown) etc.?

Which cases were handled before this PR?
Just if (falsy) if (truthy) if (nullish)?

The unknown was the problem. If was able to handle if (truthy || unknown) but not if (unknown || truthy).
The problem is that truthy || unknown => truthy, but unknown || truthy could be unknown (if it's truthy at runtime) or truthy, so the evaluator evaluates it to Alternatives(unknown, truthy). The PR adds an additional info to Alternatives that the combination has a truthy value.

#8890
#8873  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @sokra and the rest of your teammates on  Graphite


Flake8 compliant type checking.

Replicates #303, but by targetting main this won't get overwritten by pre-commit.

Thanks @HGWright !


If I submit a new record with a source metadata ID it can't get data for it should error out

Probably a validation error.


Dynamically generating a tree

Describe the bug
When dynamically generating a tree, the child nodes are not aligned properly
Setup
Please complete the following information along with version numbers, if applicable.

OS [Ubuntu]
Shell [bash]
Locale [en_US.UTF-8]

To Reproduce
Steps to reproduce the behavior:
Run the following program.
Source Code
package main

import (
	"fmt"

	"github.com/charmbracelet/lipgloss/tree"
)

type Node struct {
	Name     string
	Category []Category
}

type Category struct {
	Name  string
	Items []Item
}

type Item struct {
	Name string
}

var categories = []Category{
	{
		Name: "cat1",
		Items: []Item{
			{Name: "item1"},
			{Name: "item2"},
		},
	},
	{
		Name: "cat2",
		Items: []Item{
			{Name: "item3"},
			{Name: "item4"},
		},
	},
}

func main() {
	data := Node{
		Name:     "root",
		Category: categories,
	}

	// Create a new tree
	root := tree.Root(data.Name)

	for _, cat := range data.Category {
		cTree := root.Child(
			tree.New().Root(cat.Name),
		)

		for _, item := range cat.Items {
			cTree.Child(item.Name)
		}
	}

	fmt.Println(root)
}

Expected behavior
root, child, and leaf aligned per the relationships.
Screenshots
$ go run main.go
root
├── cat1
├── item1
├── item2
├── cat2
├── item3
└── item4

Additional context
Add any other context about the problem here.

Hey, the issue here is where you assign the output of root.Child to cTree which makes cTree a pointer to the root tree, not the child.
Here's a working version of what you're looking for:
package main

import (
	"fmt"

	"github.com/charmbracelet/lipgloss/tree"
)

type Node struct {
	Name     string
	Category []Category
}

type Category struct {
	Name  string
	Items []Item
}

type Item struct {
	Name string
}

var categories = []Category{
	{
		Name: "cat1",
		Items: []Item{
			{Name: "item1"},
			{Name: "item2"},
		},
	},
	{
		Name: "cat2",
		Items: []Item{
			{Name: "item3"},
			{Name: "item4"},
		},
	},
}

func main() {
	data := Node{
		Name:     "root",
		Category: categories,
	}

	// Create a new tree
	root := tree.Root(data.Name)

	for _, cat := range data.Category {
		cTree := tree.New().Root(cat.Name)

		for _, item := range cat.Items {
			cTree.Child(item.Name)
		}
		root.Child(cTree)
	}

	fmt.Println(root)
}

Output
 root
 ├── cat1
 │   ├── item1
 │   └── item2
 └── cat2
     ├── item3
     └── item4

Awesome! Thank you.


os: TestDevNullFile is broken on Solaris

I just submitted CL 102457 that added more checks to TestDevNullFile and new test fails on Solaris.
https://build.golang.org/log/924e0064b500c0b807dcadcf4e7acc2f94e232ec
--- FAIL: TestDevNullFile (0.00s)
	os_test.go:1807: Lstat("/dev/null"): wrong file size have 27 want 0
	os_test.go:1810: Lstat("/dev/null"): wrong file mode "Lrwxrwxrwx": ModeDevice is not set
	os_test.go:1813: Lstat("/dev/null"): wrong file mode "Lrwxrwxrwx": ModeCharDevice is not set
FAIL
FAIL	os	0.852s

I do not know enough about Solaris to decide if that is wrong test or broken Lstat implementation.
If anyone knows which, please, let me know, and I will skip Lstat part of the test on Solaris, or remove Lstat part altogether.
Thank you.
Alex

Just to make it more interesting - there are 2 Solaris builders: solaris-amd64-oraclerel (TestDevNullFile failed there) and solaris-amd64-smartosbuildlet (TestDevNullFile succeeded).
Alex

It seems /dev/null is a symlink on solaris-amd64-oraclerel.

I realised that now. Sending a CL.
Alex


Cannot add table data to offline repo

I have created an offline repository and would like to add table data to it. I clicked "Advanced > Beta - Data" and have added tables from a transport request. When I click "Back" there is no visible object type TABU in the repo.
My tables are of category A and their definitions are present in the repo.

Do you mean that it's an offline repo?
I haven't tried but I think it's a limitation of the current design:
https://github.com/abapGit/abapGit/issues/6231#issuecomment-1514140449

Yes, an offline repo, sorry.
Does it mean that the only way to export table data is to an online repo ?

yea, its a bit tricky, it needs the remote attached for it to serialize, for offline repos it means first loading the zip,

Is there a way to bypass the need for an online repo ? I don't want to export sensitive data to an online repo, even a private one.

Is there a way to bypass the need for an online repo ? I don't want to export sensitive data to an online repo, even a private one.

see https://github.com/abapGit/abapGit/issues/6378#issuecomment-1656554506 this is an offline repo with table data

It's a missing feature

I didn't intend to fix this but https://github.com/abapGit/abapGit/pull/6638 fixed this, too 😄


Submissions View - The filter of locked submissions is visible even when there are no locked submissions or no submissions at all

Describe the bug
The filter of locked submissions is visible even when there are no locked submissions.

In this case, this filter is not necessary.
Same situation when there are no submissions.

To Reproduce

Go to Course management
Click on excercises
Click on any exercises
Click on Submissions
Verify that without submission this filter is visible doing nothing
Verify that with all submissions assessed, this filter shows an empty table. No necessary
Verify that with some submissions assessed but no one locked, this filter just show an empty table. Not necessary

Expected behavior

This filter would be visible just when really there are locked submissions.
This filter should not be visible when there are no submissions.

Screenshots
No response
What browsers are you seeing the problem on?
Chrome, Safari
Additional context
No response
Relevant log output
No response

Closed by: https://github.com/ls1intum/Artemis/pull/5308


feat: Add search functionality to the Views page (resolves #184)

[X] This pull request has been linted by running npm run lint without errors
[X] This pull request has been tested by running npm run start and reviewing affected routes
[X] This pull request has been built by running npm run build without errors
[X] This isn't a duplicate of an existing pull request

Description
Add search functionality to the "Views" page.
Now the "Views" page has two sections for displaying static generated content and dynamic search results:

article.static-view section uses nunjucks template to generate static initial pages. Clicking on "Views" menu item shows this section;
article.dynamic-view section uses Vue template to display dynamic search results. It's hidden by default and only shown for searching thru views. When showing the search result, the article.static-view section becomes hidden.

This implementation is to ensure static pages are still generated for fast access while the dynamic section is used for displaying the dynamic search results.
However, displaying the dynamic data causes the problem at displaying the page title in the form of "Views (Page #pageNumber)". This is because the pageTitle can only be set statically. It cannot consume a dynamically calculated page number. The solution for now is to change the page title to "Views" without including the page number.
Steps to test

Go to "Views";
Views posts are shown;
Click through pagination to test other pages;
Perform a search using the search container on the views page.

Expected behavior:
Search results are displayed and satisfies:

All search results are views post without other type of content;
The h1 title shows "Views search results..." to distinguish from the h1 title of "Search results..." when searching with the search container on the header;
The search container shows up below the sentence "We found XX results" and it's filled with the search-for keyword.

Across browsers the placeholder term for the views search is cut off

Should views search bar become thicker when uio enhance inputs is turned on like it the header search bar does?

@TeddTech, thanks for comments. They are all addressed and this pull request is ready for another look.

Across browsers the placeholder term for the views search is cut off

The three dots (...) of the placeholder value is still cut off in safari and chrome when uio enhance inputs is turned on

The three dots (...) of the placeholder value is still cut off in safari and chrome when uio enhance inputs is turned on

Good catch, @TeddTech. It's now fixed and ready for another look. Thanks.

For both header search and views search any query involving the following characters gets stuck searching indefinitely: +, [, \, ?, *, (, )

The problem is fixed by escaping special characters before performing the search. @TeddTech, can you take a look again? Thanks.


Supervisor beginnings

Eventual goal is to have a reconciler which moves state from
actual -> desired. First step along the way is to observe/monitor.
The first step even in that is an initial implementation to get
feedback on the direction.
This PR is a start in that direction

Concept of a supervisor at local participant level
This supervisor will be responsible for periodically monitor
actual vs desired (this is the one which will eventually trigger
other things to reconcile, but for now it just logs on error)
A new interface OperationMonitor which requires two methods
o Check() returns an error based on actual vs desired state.
o IsIdle() returns bool. Returns true if the monitor is idle.
The supervisor maintains a list of monitors and does periodic check.

In the above framework, starting with list of
subscriptions/unsubscriptions. There is a new module
SubscriptionMonitor which checks subscription transitions.
A subscription transition is queued on subscribe/unsubscribe.
The transition can be satisfied when a subscribedTrack is added OR
removed. Error condition is when a transition is not satisfied for
10 seconds. Idle is when the transition queue is empty and
subscribedTrack is nil, i. e. the last transition would have been
unsubscribe and subscribed track removed (unsubscribe satisfied).
The idea is individual monitors can check on different things.
Some more things that I am thinking about are

PublishedTrackMonitor - started when an add track happens,
satisfied when OnTrack happens, error if OnTrack does not
fire for a while and track is not muted, idle when there is
nothing pending.

PublishedTrackStreamingMonitor - to ensure that a published track
is receiving media at the server (accounting for dynacast, mute, etc)

SubscribedTrackStreamingMonitor - to ensure down track is sending
data unless muted.
UPDATE: Added PublicationMonitor in this commit - https://github.com/livekit/livekit/pull/1005/commits/2d0628e2b242a82a00dc49a2af0f26ed614f6e9a. Assuming this pattern of reconciler is okay and the code looks okay, probably a good enough place to pause this effort and get it deployed and watch for anomalies before adding more things like "is the stream actually sending data?". Those things will be a bit more complex.

@davidzhao sync is a concern, but am also trying to not get things too entangled. And also trying to avoid doing too much work (actually tending close to zero work) in the Check and IsIdle methods. Don't want to check too many things there. Currently, it just dequeues the front entry and checks for timeout.
And things are queued. Our subscriptions are queued. Our publications are queued. So, the monitor is also building that queue and processing events as they happen. Because of the queue, out-of-sync is not a major concern as it is a progression and they have to happen. Yes, that does mean calling those events from the right places, but finding the right places to check will anyway be an issue.
This model will run into challenges as we add more monitors as everything is not queued. There is a need for a live tracking model (i. e. is streaming happening?, did layer lock happen?). Will have to see how that model evolves.
This is what I could think of to keep things running independently, i. e. being able to observe without embedding deeply in the existing modules. There surely must be better ways. I may hit upon one as I think more about this :-) . But, my goal is to be safe against unintended consequences. So, separate module with its own goroutine/locking etc. No callbacks (yet). Minimal touch points (by minimal, I mean fast operations in a well defined tight functions) from outside. All with the aim of reducing potential knots. Our ParticipantImpl is again over 2000 LOC :-) Whatever we do, it keeps growing :-)

Going to merge this. Will look at genetic post event thing next. Will also think about other ways of making this better.

@davidzhao sync is a concern, but am also trying to not get things too entangled. And also trying to avoid doing too much work (actually tending close to zero work) in the Check and IsIdle methods. Don't want to check too many things there. Currently, it just dequeues the front entry and checks for timeout.
And things are queued. Our subscriptions are queued. Our publications are queued. So, the monitor is also building that queue and processing events as they happen. Because of the queue, out-of-sync is not a major concern as it is a progression and they have to happen. Yes, that does mean calling those events from the right places, but finding the right places to check will anyway be an issue.
This model will run into challenges as we add more monitors as everything is not queued. There is a need for a live tracking model (i. e. is streaming happening?, did layer lock happen?). Will have to see how that model evolves.
This is what I could think of to keep things running independently, i. e. being able to observe without embedding deeply in the existing modules. There surely must be better ways. I may hit upon one as I think more about this :-) . But, my goal is to be safe against unintended consequences. So, separate module with its own goroutine/locking etc. No callbacks (yet). Minimal touch points (by minimal, I mean fast operations in a well defined tight functions) from outside. All with the aim of reducing potential knots. Our ParticipantImpl is again over 2000 LOC :-) Whatever we do, it keeps growing :-)

The current design is very clean :) Thanks for explaining the thought process. I had a different mental model initially, but the approach of treating it like an operation and closing it out after it's confirmed makes a lot of sense. It wouldn't be possible to use existing participant state following that model.


Add coreos-baremetal to k8s guides

Here is a first crack at adding links to coreos-baremetal...
@robszumski @joshix

Better? @robszumski @joshix

This doesn't quite become the single funnel @robszumski waffled about a little, but I think it LGTM for purpose.

LGTM


Fix additional GPU overdraw on post list

Summary
Fix additional GPU overdraw that wasn't needed.
the post is already background filled at navigator level.
on android's overdraw inspector it makes the post list go from RED to GREEN which means overdraw was reduced
Checklist

[ ] Added or updated unit tests (required for all new features)
[ ] All new/modified APIs include changes to mattermost-redux (please link)
[ ] Has UI changes
[ ] Includes text changes and localization file updates

Device Information
This PR was tested on: [Device name(s), OS version(s)]
galaxy s7, android 7
Screenshots
[If the PR includes UI changes, include screenshots (for both iOS and Android if possible).]

@koxen can you provide before and after screenshots

needs a rebase

eh, I forgot again that my github fork's master doesn't have the commit that changes commas :P causing all these merge conflicts...
fixed


Add cpython & other repos as formatting stability check to CI

We have a script that formats cpython twice and checks that the formatting stays the same, that we only output valid syntax and that we don't panic due to some input. I want to integrate this script into CI to avoid regressions. This also needs documentation on how to run the check locally.

This also needs documentation on how to run the check locally

Is this already solved or is there more that could be helpful to document?

The general way is documented at https://github.com/astral-sh/ruff/blob/main/crates/ruff_python_formatter/README.md#checking-entire-projects. I'm currently working a small but diverse set of projects that we continuously check and will add more instructions once that's done.
I also ran the stability checks with the 3k repo from ruff-usage-aggregate and have to go through all of them and either fix them directly or open issues for each distinct one.

i've posted the initial script in https://github.com/astral-sh/ruff/issues/5828, this ticket is effectively about automating most of the scores from that ticket.

Fixed by #5919


Fit & finish - UI Copy | Open from ABS

Fit & finish - UI Copy | Open from ABS
White cells = existing copy
Yellow/blue cells = new copy (replace original copy with this copy)
Orange = P0, must update
Link to 'live' copy on '  ' tab:
https://microsoft.sharepoint.com/:x:/r/teams/ConversationalAI785/_layouts/15/Doc.aspx?sourcedoc={6B1FACBD-B5FE-4AD2-A35B-995635C1696B}&file=glossary.xlsx&action=edit&mobileredirect=true&wdPreviousSession=36539654-a42b-4b87-be1b-de96507b4422&wdOrigin=TEAMS-ELECTRON.teams.undefined&cid=676cf454-61e0-4182-bd27-39044bb51cea

Shiproom - approving as today is fit and finish day.  must be merged by EOD today


Plumb a user-agent through pretty much everywhere

What this PR does / why we need it:
This is a followup to #422
The most useful thing out of this is the kubeconfig one which should make it easier for cluster operators to look at apiserver logs and find cert-manager's calls.
The others are all just to try and be a good citizen, but probably don't matter much.
I have not tested this other than verifying it compiles.
Release note:
NONE

/retest


update download options

Changes in this PR:
update download options
Actually download NOT show the PDF in the browser and the user has to download the PDF on that screen THEREFORE force to download using download= attribute
change boarder size and remove underline on heading
Trello card / Rollbar error (etc)
https://trello.com/c/8DjcTVhf/1567-✔-aa-more-download-options-panel
Screenshots of UI changes:
Before styling -change boarder size and remove underline on heading

After styling -change boarder size and remove underline on heading

Before
download-top-page.webm
after-download-top.webm
After
after-download-top.webm
after-download-bottom.webm

[ ] Requires env variable(s) to be updated

 ✔ AA | 'More download options' panel


[core] Add backlash

Bashlash can be implemented in the exact same way as flexible joints by a virtual joint with co-located with the true one and with the same DoFs. The "flexible" name should be generalized to distinguish the actual model from the theoretical one. For instance, just true versus theoretical. Getters (basically any utility) for the flexible model should be renamed accordingly.

Fixed by https://github.com/duburcqa/jiminy/pull/767


App crash when presenting login modal - SwiftUI

Hi,
We have a strange crash when we start a payment when user is not signed in to SumUp.
Flow:

start a sumup payment
sumup opens sign in modal screen

Now is the strange part - if we have an ipad with an external keyboard everything works fine.
But if we have an iPad with no external keyboard where the native keyboard pops up - to fill in email and password - crash! (See crash report below)
2020-10-28 14:14:09.363083+0100 Staging iPad App[2878:1379274] [error] precondition failure: no graph: 6984524 AttributeGraph precondition failure: no graph: 6984524.
So as soon as the native keyboard opens the crash happens.
Do you guys have an idea what this can be?
Xcode version 12.1
Sumup SDK version 4.0.0

Hi @AchidFarooq, thanks for reaching out!
In order to help you solve this, can you provide a minimalistic, sample app for us, where it is reproducible?
Is this happening only when using SwiftUI only applications, or how is that related (in the issue title)?
It might not be related, but to be complete, on which iPad and iOS version is this happening?

After a few pod deinits and reinstalls it worked suddenly. Thanks for a fast reply @andraskadar


When updating in loop with 2seconds brokes the file

Describe the bug
I'm trying to update my json every 2 seconds but after couple updateing it will be broken.
This is the normal ending of my json file.

This is the broken json

This is the error code

From the TraceBack, I assume you are using Threads.. Uhhhh.... This package and threads do not work that well.
We might work on a fix, but these days we both are kind of busy with college and other stuff so it will probably take some time.
And sorry for the inconvenience 🙃 .

That's okay thanks for responding :)

@suhasa010 @MrMirhan is it possible for you guys run the test on pysondb-v2 and check whether the same issue happens or not.
install pysondb-v2 with this command.
pip3 install pysondb-v2[all]
make sure that you delete the old version.
and also check the docs.(the names of the methods have changed so that it follow PEP8 conventions)

Did anyone find a fix to the issue?
I want the use the pysondb with backgroundscheduler
and I get the same symptoms


Try OSX again, change build string to include "CUDA" or "CPU"

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Closes #1

@conda-forge-admin, please rerender

Got it finally!


Window placement and sizing.

I'm not sure if the window placement and sizing should be done how it is now.  Sometimes the resizing places the title bar off of the screen to the top (if close to the top of the screen and opening a large Block Diagram).
Options could include:

the top-left corner should be set and resizing is done down and to the right (similar to the Context Help window) with some maximum
the size/position is set and remembered from run-to-run (similar to Quick Drop window)
continue to popup by the selected VI but don't automatically resize for the Block Diagram, ensure doesn't leave the top of the screen
resize how you originally planned, resizing to the VIs previously saved size (Is this available to read somewhere?) but ensure doesn't leave the screen
some other way I haven't thought of

@qalldredge I created a Window-Resize branch which implements the second bullet point (and made a few small changes to make sure the window hides when it should). Let me know if this window behavior is better than what we currently have.

@jacobson3 I think I like this better.  Then it's not always moving and shifting around.


CAMEL-19859: camel-spring-rabbitmq set headerfilter not effective

Description
if i use java code to config spring-rabbitmq component headerfilterstrategy, the doinit() method of SpringRabbitMQComponent will be executed before i config headerfilterstrategy, so the DefaultMessagePropertiesConverter may reference headerfilterStrategy the old value。
Target

[X] I checked that the commit is targeting the correct branch (note that Camel 3 uses camel-3.x, whereas Camel 4 uses the main branch)

Tracking

[X] If this is a large change, bug fix, or code improvement, I checked there is a JIRA issue filed for the change (usually before you start working on it).

Apache Camel coding standards and style

[X] I checked that each commit in the pull request has a meaningful subject line and body.

[X] I have run mvn clean install -DskipTests locally and I have committed all auto-generated changes

/component-test camel-spring-rabbitmq

The CI failure here seems like a false negative. I tested manually and it works OK.


Rule request: Prefer non-alias of ActiveRecord::Base.update and friends

I'd like a rule that enforces consistent use of either update and update! or their aliases update_attributes and update_attributes!.
Eg:
# good
record.update!
return record if record.update

#bad
record.update_attributes!
return record if record.update_attributes

Something like this should be trivial to implement. It's a pity it won't work well in the other direction, but I guess it should be configurable.


Follow mouse with tooltip

Is there a way to enable following the mouse with the tooltip?

Why not override the positionTracker attribute in a component to the position of your cursor?

I'm not using this anymore, but it should still be supported by the library.

Closing the issue since Tooltipster doesn't support this feature at the moment.


Fuchsia builder shows as green in console even if it has step failure

Some fuchsia builders have a failed step but it shows up as a success on the console.
https://ci.chromium.org/p/flutter/builders/prod/Linux Fuchsia/3559

Fixes landed on the following CLs:

https://fuchsia-review.googlesource.com/c/infra/recipes/+/388321
https://flutter-review.googlesource.com/c/recipes/+/2681
https://flutter-review.googlesource.com/c/recipes/+/2682


Chameleon 3 camera: GenTL exception: Parameter not valid or out of range. (Message from the source: Error calling GenTL function system GCRegisterEvent.) (ID: -1009)

Describe the Issue
I try to connect my Camera with Harvester GUI and I get an Error
To Reproduce
Steps to reproduce the behavior:

Launch Harvester gui
Click on open CTI File and load the CTI file given by Spinnaker sdk
Camera correctly shows up
Click on connect camera
Error shows up in terminal

Sample Code
I can show a piece of code that demonstrates the reported phenomenon:

[ ] Yes
[X] No

** Error
  File "C:\Users\Bonno\miniconda3\lib\site-packages\harvesters_gui-0.post0.dev118-py3.10.egg\harvesters_gui\frontend\pyqt.py", line 478, in action_on_connect
    self._ia = self.harvester_core.create(
  File "C:\Users\Bonno\miniconda3\lib\site-packages\harvesters\core.py", line 3082, in create
    return self._create_acquirer(device_proxy=device_proxy, config=config)
  File "C:\Users\Bonno\miniconda3\lib\site-packages\harvesters\core.py", line 3112, in _create_acquirer
    ia = ImageAcquirer(device_proxy=device_proxy_, config=config,
  File "C:\Users\Bonno\miniconda3\lib\site-packages\harvesters\core.py", line 1665, in __init__
    manager(module.register_event(event_type))
  File "C:\Users\Bonno\miniconda3\lib\site-packages\harvesters\core.py", line 228, in m
    return getattr(self._source_object, attribute)(*args)
  File "C:\Users\Bonno\miniconda3\lib\site-packages\genicam\gentl.py", line 2303, in register_event
    return _gentl.System_register_event(self, event_id)
_gentl.InvalidParameterException: GenTL exception: Parameter not valid or out of range. (Message from the source: Error calling GenTL function system GCRegisterEvent.) (ID: -1009)

Expected Behavior
Can't connect
Configuration
Please note that I ported the Harvester GUI over to PyQt6 and python 3.10.
However the error occurred in the Harvesters library

OS: [Windows 11]
Python: [3.10]
Harvester: [1.4.2]
GenTL Producer: [Spinakker SDK]
Camera: []

Reproducibility
This phenomenon can be stably reproduced:

[x] Yes, it happens every time
[ ] No.

** Additional Information
The Camera does work with my own Python libraries that use the official Spinnaker python libraries

[X] I've read the Harvester FAQ page.

edit: Fixed a typo and added what goes wrong

I'm also seeing this on Harvesters 1.4.2, Python 3.10, with Ubuntu 22.04 and a Blackfly S using Spinnaker

I am also experiencing this issue.
Harvesters 1.4.2
Python 3.7.16
Win 10
Point Grey (acquired by FLIR) Grasshopper3 GS3-U3-50S5M
Spinnaker SDK v4 Full


Fixes --segment with multiple raters s.t. first element is used for target

Checklist
GitHub

[x] I've given this PR a concise, self-descriptive, and meaningful title
[x] I've linked relevant issues in the PR body
[x] I've applied the relevant labels to this PR
[x] I've assigned a reviewer

PR contents

[x] I've consulted ivadomed's internal developer documentation to ensure my contribution is in line with any relevant design decisions
[ ] I've added relevant tests for my contribution
[x] I've updated the relevant documentation for my changes, including argparse descriptions, docstrings, and ReadTheDocs tutorial pages

Description

As mentioned in #816, currently running --segment with random sampling of multiple raters gives TypeError: can only concatenate str (not "list") to str at the following lines:
https://github.com/ivadomed/ivadomed/blob/d1b9e118f491d9e5e88523f8d0f0cae65b26ecca/ivadomed/main.py#L297-L299
This is because with random sampling of multiple raters we have a target_suffix specified like [[<suffix1>, <suffix2>]] (i.e. list of lists) as explained in #546. Therefore, in each loop the target variable shown above is a list.
Implementation
The fix I employed in this PR is very simple: check if target is a list and set target to the first element if that's the case (i.e. <suffix1> from the example above).
Results
Following the steps mentioned at https://github.com/ivadomed/model_seg_ms_mp2rage/pull/11 for lesion segmentation, I get the following error (as mentioned in https://github.com/ivadomed/model_seg_ms_mp2rage/issues/27):
Terminal output
(um_main) uzmac@romane:~/model_seg_ms_mp2rage$ ivadomed --segment -c config/seg_lesion.json
2021-12-22 15:24:10.563 | INFO     | ivadomed.utils:init_ivadomed:408 -
ivadomed (git-HEAD-d1b9e118f491d9e5e88523f8d0f0cae65b26ecca*)

2021-12-22 15:24:10.564 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-22 15:24:10.564 | INFO     | ivadomed.config_manager:deep_dict_compare:44 -     log_file: log
2021-12-22 15:24:10.565 | INFO     | ivadomed.config_manager:deep_dict_compare:44 -     loader_parameters: is_input_dropout: False
2021-12-22 15:24:10.565 | INFO     | ivadomed.config_manager:deep_dict_compare:44 -     split_dataset: split_method: participant_id
2021-12-22 15:24:10.565 | INFO     | ivadomed.config_manager:deep_dict_compare:44 -     split_dataset: data_testing: {'data_type': None, 'data_value': []}
2021-12-22 15:24:10.565 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-22 15:24:10.565 | INFO     | ivadomed.utils:get_path_output:371 - CLI flag --path-output not used to specify output directory. Will check config file for dir
ectory...
2021-12-22 15:24:10.565 | INFO     | ivadomed.utils:get_path_data:383 - CLI flag --path-data not used to specify BIDS data directory. Will check config file for dire
ctory...
2021-12-22 15:24:10.565 | INFO     | ivadomed.main:set_output_path:207 - Output path already exists: seg_lesion_output
2021-12-22 15:24:10.759 | INFO     | ivadomed.utils:define_device:135 - Using GPU ID 0
2021-12-22 15:24:10.760 | INFO     | ivadomed.utils:display_selected_model_spec:145 - Selected architecture: Modified3DUNet, with the following parameters:
2021-12-22 15:24:10.760 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   dropout_rate: 0.3
2021-12-22 15:24:10.760 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   bn_momentum: 0.1
2021-12-22 15:24:10.760 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   depth: 4
2021-12-22 15:24:10.760 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   is_2d: False
2021-12-22 15:24:10.760 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   final_activation: sigmoid
2021-12-22 15:24:10.761 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   folder_name: seg_lesion_model
2021-12-22 15:24:10.761 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   applied: True
2021-12-22 15:24:10.761 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   length_3D: [32, 64, 128]
2021-12-22 15:24:10.761 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   stride_3D: [32, 64, 128]
2021-12-22 15:24:10.761 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   attention: False
2021-12-22 15:24:10.761 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   n_filters: 8
2021-12-22 15:24:10.761 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   in_channel: 1
2021-12-22 15:24:10.761 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   out_channel: 1
2021-12-22 15:24:11.225 | INFO     | ivadomed.loader.bids_dataframe:save:289 - Dataframe has been saved in seg_lesion_output/bids_dataframe.csv.
2021-12-22 15:24:11.227 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-22 15:24:11.227 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-22 15:24:11.227 | WARNING  | ivadomed.inference:segment_volume:402 - fname_roi has not been specified, then the entire volume is processed.
2021-12-22 15:24:11.239 | INFO     | ivadomed.inference:segment_volume:435 - Loaded 1 axial volumes of shape [32, 64, 128].
2021-12-22 15:24:14.206 | INFO     | ivadomed.utils:define_device:135 - Using GPU ID 0
2021-12-22 15:24:14.209 | DEBUG    | ivadomed.inference:get_preds:88 - Likely ONNX model detected at: seg_lesion_output/seg_lesion_model/seg_lesion_model.onnx
2021-12-22 15:24:14.209 | DEBUG    | ivadomed.inference:get_preds:89 - Conduct ONNX model inference...
2021-12-22 15:24:14.359 | DEBUG    | ivadomed.inference:get_preds:92 - Sending predictions to CPU
target_list:  [['_lesion-manual', '_lesion-manual2']]
target:  ['_lesion-manual', '_lesion-manual2']
Traceback (most recent call last):
  File "/home/GRAMES.POLYMTL.CA/uzmac/.local/bin/ivadomed", line 11, in <module>
    load_entry_point('ivadomed', 'console_scripts', 'ivadomed')()
  File "/home/GRAMES.POLYMTL.CA/uzmac/ivadomed/ivadomed/main.py", line 591, in run_main
    run_command(context=context,
  File "/home/GRAMES.POLYMTL.CA/uzmac/ivadomed/ivadomed/main.py", line 364, in run_command
    run_segment_command(context, model_params)
  File "/home/GRAMES.POLYMTL.CA/uzmac/ivadomed/ivadomed/main.py", line 300, in run_segment_command
    filename = subject.split('.')[0] + target + "_pred" + ".nii.gz"
TypeError: can only concatenate str (not "list") to str

After git checkout um/segment_with_multiple_raters in ivadomed, the --segment for lesion segmentation works successfully:
Terminal output

(um_main) uzmac@romane:~/model_seg_ms_mp2rage$ ivadomed --segment -c config/seg_lesion.json
2021-12-22 15:27:43.963 | INFO     | ivadomed.utils:init_ivadomed:408 -
ivadomed (git-HEAD-d1b9e118f491d9e5e88523f8d0f0cae65b26ecca*)

2021-12-22 15:27:43.965 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-22 15:27:43.965 | INFO     | ivadomed.config_manager:deep_dict_compare:44 -     log_file: log
2021-12-22 15:27:43.965 | INFO     | ivadomed.config_manager:deep_dict_compare:44 -     loader_parameters: is_input_dropout: False
2021-12-22 15:27:43.965 | INFO     | ivadomed.config_manager:deep_dict_compare:44 -     split_dataset: split_method: participant_id
2021-12-22 15:27:43.965 | INFO     | ivadomed.config_manager:deep_dict_compare:44 -     split_dataset: data_testing: {'data_type': None, 'data_value': []}
2021-12-22 15:27:43.965 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-22 15:27:43.965 | INFO     | ivadomed.utils:get_path_output:371 - CLI flag --path-output not used to specify output directory. Will check config file for directory...
2021-12-22 15:27:43.965 | INFO     | ivadomed.utils:get_path_data:383 - CLI flag --path-data not used to specify BIDS data directory. Will check config file for directory...
2021-12-22 15:27:43.965 | INFO     | ivadomed.main:set_output_path:207 - Output path already exists: seg_lesion_output
2021-12-22 15:27:44.125 | INFO     | ivadomed.utils:define_device:135 - Using GPU ID 0
2021-12-22 15:27:44.126 | INFO     | ivadomed.utils:display_selected_model_spec:145 - Selected architecture: Modified3DUNet, with the following parameters:
2021-12-22 15:27:44.126 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   dropout_rate: 0.3
2021-12-22 15:27:44.126 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   bn_momentum: 0.1
2021-12-22 15:27:44.126 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   depth: 4
2021-12-22 15:27:44.126 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   is_2d: False
2021-12-22 15:27:44.126 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   final_activation: sigmoid
2021-12-22 15:27:44.126 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   folder_name: seg_lesion_model
2021-12-22 15:27:44.126 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   applied: True
2021-12-22 15:27:44.126 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   length_3D: [32, 64, 128]
2021-12-22 15:27:44.126 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   stride_3D: [32, 64, 128]
2021-12-22 15:27:44.126 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   attention: False
2021-12-22 15:27:44.126 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   n_filters: 8
2021-12-22 15:27:44.127 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   in_channel: 1
2021-12-22 15:27:44.127 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   out_channel: 1
2021-12-22 15:27:44.589 | INFO     | ivadomed.loader.bids_dataframe:save:289 - Dataframe has been saved in seg_lesion_output/bids_dataframe.csv.
2021-12-22 15:27:44.591 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-22 15:27:44.591 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-22 15:27:44.591 | WARNING  | ivadomed.inference:segment_volume:402 - fname_roi has not been specified, then the entire volume is processed.
2021-12-22 15:27:44.603 | INFO     | ivadomed.inference:segment_volume:435 - Loaded 1 axial volumes of shape [32, 64, 128].
2021-12-22 15:27:47.383 | INFO     | ivadomed.utils:define_device:135 - Using GPU ID 0
2021-12-22 15:27:47.385 | DEBUG    | ivadomed.inference:get_preds:88 - Likely ONNX model detected at: seg_lesion_output/seg_lesion_model/seg_lesion_model.onnx
2021-12-22 15:27:47.386 | DEBUG    | ivadomed.inference:get_preds:89 - Conduct ONNX model inference...
2021-12-22 15:27:47.551 | DEBUG    | ivadomed.inference:get_preds:92 - Sending predictions to CPU
2021-12-22 15:27:47.569 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-22 15:27:47.569 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-22 15:27:47.569 | WARNING  | ivadomed.inference:segment_volume:402 - fname_roi has not been specified, then the entire volume is processed.
2021-12-22 15:27:47.583 | INFO     | ivadomed.inference:segment_volume:435 - Loaded 1 axial volumes of shape [32, 64, 128].
2021-12-22 15:27:47.584 | INFO     | ivadomed.utils:define_device:135 - Using GPU ID 0
2021-12-22 15:27:47.584 | DEBUG    | ivadomed.inference:get_preds:88 - Likely ONNX model detected at: seg_lesion_output/seg_lesion_model/seg_lesion_model.onnx
2021-12-22 15:27:47.584 | DEBUG    | ivadomed.inference:get_preds:89 - Conduct ONNX model inference...
2021-12-22 15:27:47.729 | DEBUG    | ivadomed.inference:get_preds:92 - Sending predictions to CPU
2021-12-22 15:27:47.748 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-22 15:27:47.748 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-22 15:27:47.749 | WARNING  | ivadomed.inference:segment_volume:402 - fname_roi has not been specified, then the entire volume is processed.
2021-12-22 15:27:47.761 | INFO     | ivadomed.inference:segment_volume:435 - Loaded 1 axial volumes of shape [32, 64, 128].
2021-12-22 15:27:47.762 | INFO     | ivadomed.utils:define_device:135 - Using GPU ID 0
2021-12-22 15:27:47.763 | DEBUG    | ivadomed.inference:get_preds:88 - Likely ONNX model detected at: seg_lesion_output/seg_lesion_model/seg_lesion_model.onnx
2021-12-22 15:27:47.763 | DEBUG    | ivadomed.inference:get_preds:89 - Conduct ONNX model inference...
2021-12-22 15:27:47.888 | DEBUG    | ivadomed.inference:get_preds:92 - Sending predictions to CPU
2021-12-22 15:27:47.901 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-22 15:27:47.902 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-22 15:27:47.902 | WARNING  | ivadomed.inference:segment_volume:402 - fname_roi has not been specified, then the entire volume is processed.
2021-12-22 15:27:47.916 | INFO     | ivadomed.inference:segment_volume:435 - Loaded 1 axial volumes of shape [32, 64, 128].
2021-12-22 15:27:47.918 | INFO     | ivadomed.utils:define_device:135 - Using GPU ID 0
2021-12-22 15:27:47.918 | DEBUG    | ivadomed.inference:get_preds:88 - Likely ONNX model detected at: seg_lesion_output/seg_lesion_model/seg_lesion_model.onnx
2021-12-22 15:27:47.918 | DEBUG    | ivadomed.inference:get_preds:89 - Conduct ONNX model inference...
2021-12-22 15:27:48.037 | DEBUG    | ivadomed.inference:get_preds:92 - Sending predictions to CPU
2021-12-22 15:27:48.049 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-22 15:27:48.050 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-22 15:27:48.050 | WARNING  | ivadomed.inference:segment_volume:402 - fname_roi has not been specified, then the entire volume is processed.
2021-12-22 15:27:48.074 | INFO     | ivadomed.inference:segment_volume:435 - Loaded 1 axial volumes of shape [32, 64, 128].
2021-12-22 15:27:48.075 | INFO     | ivadomed.utils:define_device:135 - Using GPU ID 0
2021-12-22 15:27:48.075 | DEBUG    | ivadomed.inference:get_preds:88 - Likely ONNX model detected at: seg_lesion_output/seg_lesion_model/seg_lesion_model.onnx
2021-12-22 15:27:48.075 | DEBUG    | ivadomed.inference:get_preds:89 - Conduct ONNX model inference...
2021-12-22 15:27:48.189 | DEBUG    | ivadomed.inference:get_preds:92 - Sending predictions to CPU
2021-12-22 15:27:48.206 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-22 15:27:48.206 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-22 15:27:48.206 | WARNING  | ivadomed.inference:segment_volume:402 - fname_roi has not been specified, then the entire volume is processed.
2021-12-22 15:27:48.228 | INFO     | ivadomed.inference:segment_volume:435 - Loaded 1 axial volumes of shape [32, 64, 128].
2021-12-22 15:27:48.235 | INFO     | ivadomed.utils:define_device:135 - Using GPU ID 0
2021-12-22 15:27:48.235 | DEBUG    | ivadomed.inference:get_preds:88 - Likely ONNX model detected at: seg_lesion_output/seg_lesion_model/seg_lesion_model.onnx
2021-12-22 15:27:48.235 | DEBUG    | ivadomed.inference:get_preds:89 - Conduct ONNX model inference...
2021-12-22 15:27:48.414 | DEBUG    | ivadomed.inference:get_preds:92 - Sending predictions to CPU
2021-12-22 15:27:48.428 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-22 15:27:48.428 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-22 15:27:48.428 | WARNING  | ivadomed.inference:segment_volume:402 - fname_roi has not been specified, then the entire volume is processed.
2021-12-22 15:27:48.444 | INFO     | ivadomed.inference:segment_volume:435 - Loaded 1 axial volumes of shape [32, 64, 128].
2021-12-22 15:27:48.446 | INFO     | ivadomed.utils:define_device:135 - Using GPU ID 0
2021-12-22 15:27:48.446 | DEBUG    | ivadomed.inference:get_preds:88 - Likely ONNX model detected at: seg_lesion_output/seg_lesion_model/seg_lesion_model.onnx
2021-12-22 15:27:48.446 | DEBUG    | ivadomed.inference:get_preds:89 - Conduct ONNX model inference...
2021-12-22 15:27:48.591 | DEBUG    | ivadomed.inference:get_preds:92 - Sending predictions to CPU
2021-12-22 15:27:48.608 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-22 15:27:48.608 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-22 15:27:48.609 | WARNING  | ivadomed.inference:segment_volume:402 - fname_roi has not been specified, then the entire volume is processed.
2021-12-22 15:27:48.627 | INFO     | ivadomed.inference:segment_volume:435 - Loaded 1 axial volumes of shape [32, 64, 128].
2021-12-22 15:27:48.629 | INFO     | ivadomed.utils:define_device:135 - Using GPU ID 0
2021-12-22 15:27:48.629 | DEBUG    | ivadomed.inference:get_preds:88 - Likely ONNX model detected at: seg_lesion_output/seg_lesion_model/seg_lesion_model.onnx
2021-12-22 15:27:48.629 | DEBUG    | ivadomed.inference:get_preds:89 - Conduct ONNX model inference...
2021-12-22 15:27:48.779 | DEBUG    | ivadomed.inference:get_preds:92 - Sending predictions to CPU
2021-12-22 15:27:48.797 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-22 15:27:48.797 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-22 15:27:48.797 | WARNING  | ivadomed.inference:segment_volume:402 - fname_roi has not been specified, then the entire volume is processed.
2021-12-22 15:27:48.812 | INFO     | ivadomed.inference:segment_volume:435 - Loaded 1 axial volumes of shape [32, 64, 128].
2021-12-22 15:27:48.813 | INFO     | ivadomed.utils:define_device:135 - Using GPU ID 0
2021-12-22 15:27:48.813 | DEBUG    | ivadomed.inference:get_preds:88 - Likely ONNX model detected at: seg_lesion_output/seg_lesion_model/seg_lesion_model.onnx
2021-12-22 15:27:48.814 | DEBUG    | ivadomed.inference:get_preds:89 - Conduct ONNX model inference...
2021-12-22 15:27:48.946 | DEBUG    | ivadomed.inference:get_preds:92 - Sending predictions to CPU
2021-12-22 15:27:48.961 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-22 15:27:48.961 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-22 15:27:48.961 | WARNING  | ivadomed.inference:segment_volume:402 - fname_roi has not been specified, then the entire volume is processed.
2021-12-22 15:27:48.977 | INFO     | ivadomed.inference:segment_volume:435 - Loaded 1 axial volumes of shape [32, 64, 128].
2021-12-22 15:27:48.978 | INFO     | ivadomed.utils:define_device:135 - Using GPU ID 0
2021-12-22 15:27:48.978 | DEBUG    | ivadomed.inference:get_preds:88 - Likely ONNX model detected at: seg_lesion_output/seg_lesion_model/seg_lesion_model.onnx
2021-12-22 15:27:48.979 | DEBUG    | ivadomed.inference:get_preds:89 - Conduct ONNX model inference...
2021-12-22 15:27:49.119 | DEBUG    | ivadomed.inference:get_preds:92 - Sending predictions to CPU
2021-12-22 15:27:49.139 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-22 15:27:49.139 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-22 15:27:49.139 | WARNING  | ivadomed.inference:segment_volume:402 - fname_roi has not been specified, then the entire volume is processed.
2021-12-22 15:27:49.153 | INFO     | ivadomed.inference:segment_volume:435 - Loaded 1 axial volumes of shape [32, 64, 128].
2021-12-22 15:27:49.155 | INFO     | ivadomed.utils:define_device:135 - Using GPU ID 0
2021-12-22 15:27:49.155 | DEBUG    | ivadomed.inference:get_preds:88 - Likely ONNX model detected at: seg_lesion_output/seg_lesion_model/seg_lesion_model.onnx
2021-12-22 15:27:49.155 | DEBUG    | ivadomed.inference:get_preds:89 - Conduct ONNX model inference...
2021-12-22 15:27:49.298 | DEBUG    | ivadomed.inference:get_preds:92 - Sending predictions to CPU
2021-12-22 15:27:49.313 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-22 15:27:49.313 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-22 15:27:49.313 | WARNING  | ivadomed.inference:segment_volume:402 - fname_roi has not been specified, then the entire volume is processed.
2021-12-22 15:27:49.330 | INFO     | ivadomed.inference:segment_volume:435 - Loaded 1 axial volumes of shape [32, 64, 128].
2021-12-22 15:27:49.331 | INFO     | ivadomed.utils:define_device:135 - Using GPU ID 0
2021-12-22 15:27:49.332 | DEBUG    | ivadomed.inference:get_preds:88 - Likely ONNX model detected at: seg_lesion_output/seg_lesion_model/seg_lesion_model.onnx
2021-12-22 15:27:49.332 | DEBUG    | ivadomed.inference:get_preds:89 - Conduct ONNX model inference...
2021-12-22 15:27:49.469 | DEBUG    | ivadomed.inference:get_preds:92 - Sending predictions to CPU
2021-12-22 15:27:49.486 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-22 15:27:49.486 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-22 15:27:49.486 | WARNING  | ivadomed.inference:segment_volume:402 - fname_roi has not been specified, then the entire volume is processed.
2021-12-22 15:27:49.500 | INFO     | ivadomed.inference:segment_volume:435 - Loaded 1 axial volumes of shape [32, 64, 128].
2021-12-22 15:27:49.501 | INFO     | ivadomed.utils:define_device:135 - Using GPU ID 0
2021-12-22 15:27:49.501 | DEBUG    | ivadomed.inference:get_preds:88 - Likely ONNX model detected at: seg_lesion_output/seg_lesion_model/seg_lesion_model.onnx
2021-12-22 15:27:49.502 | DEBUG    | ivadomed.inference:get_preds:89 - Conduct ONNX model inference...
2021-12-22 15:27:49.673 | DEBUG    | ivadomed.inference:get_preds:92 - Sending predictions to CPU
2021-12-22 15:27:49.704 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-22 15:27:49.706 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-22 15:27:49.707 | WARNING  | ivadomed.inference:segment_volume:402 - fname_roi has not been specified, then the entire volume is processed.
2021-12-22 15:27:49.719 | INFO     | ivadomed.inference:segment_volume:435 - Loaded 1 axial volumes of shape [32, 64, 128].
2021-12-22 15:27:49.721 | INFO     | ivadomed.utils:define_device:135 - Using GPU ID 0
2021-12-22 15:27:49.721 | DEBUG    | ivadomed.inference:get_preds:88 - Likely ONNX model detected at: seg_lesion_output/seg_lesion_model/seg_lesion_model.onnx
2021-12-22 15:27:49.721 | DEBUG    | ivadomed.inference:get_preds:89 - Conduct ONNX model inference...
2021-12-22 15:27:49.848 | DEBUG    | ivadomed.inference:get_preds:92 - Sending predictions to CPU
2021-12-22 15:27:49.859 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-22 15:27:49.859 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-22 15:27:49.859 | WARNING  | ivadomed.inference:segment_volume:402 - fname_roi has not been specified, then the entire volume is processed.
2021-12-22 15:27:49.872 | INFO     | ivadomed.inference:segment_volume:435 - Loaded 1 axial volumes of shape [32, 64, 128].
2021-12-22 15:27:49.874 | INFO     | ivadomed.utils:define_device:135 - Using GPU ID 0
2021-12-22 15:27:49.874 | DEBUG    | ivadomed.inference:get_preds:88 - Likely ONNX model detected at: seg_lesion_output/seg_lesion_model/seg_lesion_model.onnx
2021-12-22 15:27:49.874 | DEBUG    | ivadomed.inference:get_preds:89 - Conduct ONNX model inference...
2021-12-22 15:27:50.001 | DEBUG    | ivadomed.inference:get_preds:92 - Sending predictions to CPU
2021-12-22 15:27:50.011 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-22 15:27:50.011 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-22 15:27:50.011 | WARNING  | ivadomed.inference:segment_volume:402 - fname_roi has not been specified, then the entire volume is processed.
2021-12-22 15:27:50.031 | INFO     | ivadomed.inference:segment_volume:435 - Loaded 1 axial volumes of shape [32, 64, 128].
2021-12-22 15:27:50.033 | INFO     | ivadomed.utils:define_device:135 - Using GPU ID 0
2021-12-22 15:27:50.033 | DEBUG    | ivadomed.inference:get_preds:88 - Likely ONNX model detected at: seg_lesion_output/seg_lesion_model/seg_lesion_model.onnx
2021-12-22 15:27:50.033 | DEBUG    | ivadomed.inference:get_preds:89 - Conduct ONNX model inference...
2021-12-22 15:27:50.167 | DEBUG    | ivadomed.inference:get_preds:92 - Sending predictions to CPU
2021-12-22 15:27:50.182 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-22 15:27:50.182 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-22 15:27:50.183 | WARNING  | ivadomed.inference:segment_volume:402 - fname_roi has not been specified, then the entire volume is processed.
2021-12-22 15:27:50.195 | INFO     | ivadomed.inference:segment_volume:435 - Loaded 1 axial volumes of shape [32, 64, 128].
2021-12-22 15:27:50.196 | INFO     | ivadomed.utils:define_device:135 - Using GPU ID 0
2021-12-22 15:27:50.196 | DEBUG    | ivadomed.inference:get_preds:88 - Likely ONNX model detected at: seg_lesion_output/seg_lesion_model/seg_lesion_model.onnx
2021-12-22 15:27:50.197 | DEBUG    | ivadomed.inference:get_preds:89 - Conduct ONNX model inference...
2021-12-22 15:27:50.325 | DEBUG    | ivadomed.inference:get_preds:92 - Sending predictions to CPU
2021-12-22 15:27:50.335 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-22 15:27:50.336 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-22 15:27:50.336 | WARNING  | ivadomed.inference:segment_volume:402 - fname_roi has not been specified, then the entire volume is processed.
2021-12-22 15:27:50.352 | INFO     | ivadomed.inference:segment_volume:435 - Loaded 1 axial volumes of shape [32, 64, 128].
2021-12-22 15:27:50.353 | INFO     | ivadomed.utils:define_device:135 - Using GPU ID 0
2021-12-22 15:27:50.354 | DEBUG    | ivadomed.inference:get_preds:88 - Likely ONNX model detected at: seg_lesion_output/seg_lesion_model/seg_lesion_model.onnx
2021-12-22 15:27:50.354 | DEBUG    | ivadomed.inference:get_preds:89 - Conduct ONNX model inference...
2021-12-22 15:27:50.484 | DEBUG    | ivadomed.inference:get_preds:92 - Sending predictions to CPU
2021-12-22 15:27:50.497 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-22 15:27:50.497 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-22 15:27:50.498 | WARNING  | ivadomed.inference:segment_volume:402 - fname_roi has not been specified, then the entire volume is processed.
2021-12-22 15:27:50.513 | INFO     | ivadomed.inference:segment_volume:435 - Loaded 1 axial volumes of shape [32, 64, 128].
2021-12-22 15:27:50.515 | INFO     | ivadomed.utils:define_device:135 - Using GPU ID 0
2021-12-22 15:27:50.515 | DEBUG    | ivadomed.inference:get_preds:88 - Likely ONNX model detected at: seg_lesion_output/seg_lesion_model/seg_lesion_model.onnx
2021-12-22 15:27:50.515 | DEBUG    | ivadomed.inference:get_preds:89 - Conduct ONNX model inference...
2021-12-22 15:27:50.642 | DEBUG    | ivadomed.inference:get_preds:92 - Sending predictions to CPU
2021-12-22 15:27:50.655 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-22 15:27:50.655 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-22 15:27:50.655 | WARNING  | ivadomed.inference:segment_volume:402 - fname_roi has not been specified, then the entire volume is processed.
2021-12-22 15:27:50.670 | INFO     | ivadomed.inference:segment_volume:435 - Loaded 1 axial volumes of shape [32, 64, 128].
2021-12-22 15:27:50.671 | INFO     | ivadomed.utils:define_device:135 - Using GPU ID 0
2021-12-22 15:27:50.671 | DEBUG    | ivadomed.inference:get_preds:88 - Likely ONNX model detected at: seg_lesion_output/seg_lesion_model/seg_lesion_model.onnx
2021-12-22 15:27:50.672 | DEBUG    | ivadomed.inference:get_preds:89 - Conduct ONNX model inference...
2021-12-22 15:27:50.799 | DEBUG    | ivadomed.inference:get_preds:92 - Sending predictions to CPU
2021-12-22 15:27:50.811 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-22 15:27:50.811 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-22 15:27:50.811 | WARNING  | ivadomed.inference:segment_volume:402 - fname_roi has not been specified, then the entire volume is processed.
2021-12-22 15:27:50.830 | INFO     | ivadomed.inference:segment_volume:435 - Loaded 1 axial volumes of shape [32, 64, 128].
2021-12-22 15:27:50.831 | INFO     | ivadomed.utils:define_device:135 - Using GPU ID 0
2021-12-22 15:27:50.831 | DEBUG    | ivadomed.inference:get_preds:88 - Likely ONNX model detected at: seg_lesion_output/seg_lesion_model/seg_lesion_model.onnx
2021-12-22 15:27:50.832 | DEBUG    | ivadomed.inference:get_preds:89 - Conduct ONNX model inference...
2021-12-22 15:27:50.992 | DEBUG    | ivadomed.inference:get_preds:92 - Sending predictions to CPU
2021-12-22 15:27:51.017 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-22 15:27:51.017 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-22 15:27:51.017 | WARNING  | ivadomed.inference:segment_volume:402 - fname_roi has not been specified, then the entire volume is processed.
2021-12-22 15:27:51.044 | INFO     | ivadomed.inference:segment_volume:435 - Loaded 1 axial volumes of shape [32, 64, 128].
2021-12-22 15:27:51.045 | INFO     | ivadomed.utils:define_device:135 - Using GPU ID 0
2021-12-22 15:27:51.045 | DEBUG    | ivadomed.inference:get_preds:88 - Likely ONNX model detected at: seg_lesion_output/seg_lesion_model/seg_lesion_model.onnx
2021-12-22 15:27:51.046 | DEBUG    | ivadomed.inference:get_preds:89 - Conduct ONNX model inference...
2021-12-22 15:27:51.178 | DEBUG    | ivadomed.inference:get_preds:92 - Sending predictions to CPU
2021-12-22 15:27:51.194 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-22 15:27:51.194 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-22 15:27:51.194 | WARNING  | ivadomed.inference:segment_volume:402 - fname_roi has not been specified, then the entire volume is processed.
2021-12-22 15:27:51.207 | INFO     | ivadomed.inference:segment_volume:435 - Loaded 1 axial volumes of shape [32, 64, 128].
2021-12-22 15:27:51.209 | INFO     | ivadomed.utils:define_device:135 - Using GPU ID 0
2021-12-22 15:27:51.209 | DEBUG    | ivadomed.inference:get_preds:88 - Likely ONNX model detected at: seg_lesion_output/seg_lesion_model/seg_lesion_model.onnx
2021-12-22 15:27:51.209 | DEBUG    | ivadomed.inference:get_preds:89 - Conduct ONNX model inference...
2021-12-22 15:27:51.345 | DEBUG    | ivadomed.inference:get_preds:92 - Sending predictions to CPU
2021-12-22 15:27:51.356 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-22 15:27:51.357 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-22 15:27:51.357 | WARNING  | ivadomed.inference:segment_volume:402 - fname_roi has not been specified, then the entire volume is processed.
2021-12-22 15:27:51.372 | INFO     | ivadomed.inference:segment_volume:435 - Loaded 1 axial volumes of shape [32, 64, 128].
2021-12-22 15:27:51.374 | INFO     | ivadomed.utils:define_device:135 - Using GPU ID 0
2021-12-22 15:27:51.374 | DEBUG    | ivadomed.inference:get_preds:88 - Likely ONNX model detected at: seg_lesion_output/seg_lesion_model/seg_lesion_model.onnx
2021-12-22 15:27:51.374 | DEBUG    | ivadomed.inference:get_preds:89 - Conduct ONNX model inference...
2021-12-22 15:27:51.525 | DEBUG    | ivadomed.inference:get_preds:92 - Sending predictions to CPU
2021-12-22 15:27:51.542 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-22 15:27:51.543 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-22 15:27:51.543 | WARNING  | ivadomed.inference:segment_volume:402 - fname_roi has not been specified, then the entire volume is processed.
2021-12-22 15:27:51.560 | INFO     | ivadomed.inference:segment_volume:435 - Loaded 1 axial volumes of shape [32, 64, 128].
2021-12-22 15:27:51.561 | INFO     | ivadomed.utils:define_device:135 - Using GPU ID 0
2021-12-22 15:27:51.561 | DEBUG    | ivadomed.inference:get_preds:88 - Likely ONNX model detected at: seg_lesion_output/seg_lesion_model/seg_lesion_model.onnx
2021-12-22 15:27:51.561 | DEBUG    | ivadomed.inference:get_preds:89 - Conduct ONNX model inference...
2021-12-22 15:27:51.696 | DEBUG    | ivadomed.inference:get_preds:92 - Sending predictions to CPU
2021-12-22 15:27:51.708 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-22 15:27:51.708 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-22 15:27:51.708 | WARNING  | ivadomed.inference:segment_volume:402 - fname_roi has not been specified, then the entire volume is processed.
2021-12-22 15:27:51.720 | INFO     | ivadomed.inference:segment_volume:435 - Loaded 1 axial volumes of shape [32, 64, 128].
2021-12-22 15:27:51.721 | INFO     | ivadomed.utils:define_device:135 - Using GPU ID 0
2021-12-22 15:27:51.721 | DEBUG    | ivadomed.inference:get_preds:88 - Likely ONNX model detected at: seg_lesion_output/seg_lesion_model/seg_lesion_model.onnx
2021-12-22 15:27:51.722 | DEBUG    | ivadomed.inference:get_preds:89 - Conduct ONNX model inference...
2021-12-22 15:27:51.849 | DEBUG    | ivadomed.inference:get_preds:92 - Sending predictions to CPU
2021-12-22 15:27:51.859 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-22 15:27:51.860 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-22 15:27:51.860 | WARNING  | ivadomed.inference:segment_volume:402 - fname_roi has not been specified, then the entire volume is processed.
2021-12-22 15:27:51.872 | INFO     | ivadomed.inference:segment_volume:435 - Loaded 1 axial volumes of shape [32, 64, 128].
2021-12-22 15:27:51.873 | INFO     | ivadomed.utils:define_device:135 - Using GPU ID 0
2021-12-22 15:27:51.873 | DEBUG    | ivadomed.inference:get_preds:88 - Likely ONNX model detected at: seg_lesion_output/seg_lesion_model/seg_lesion_model.onnx
2021-12-22 15:27:51.873 | DEBUG    | ivadomed.inference:get_preds:89 - Conduct ONNX model inference...
2021-12-22 15:27:52.001 | DEBUG    | ivadomed.inference:get_preds:92 - Sending predictions to CPU
2021-12-22 15:27:52.012 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-22 15:27:52.012 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-22 15:27:52.013 | WARNING  | ivadomed.inference:segment_volume:402 - fname_roi has not been specified, then the entire volume is processed.
2021-12-22 15:27:52.024 | INFO     | ivadomed.inference:segment_volume:435 - Loaded 1 axial volumes of shape [32, 64, 128].
2021-12-22 15:27:52.026 | INFO     | ivadomed.utils:define_device:135 - Using GPU ID 0
2021-12-22 15:27:52.026 | DEBUG    | ivadomed.inference:get_preds:88 - Likely ONNX model detected at: seg_lesion_output/seg_lesion_model/seg_lesion_model.onnx
2021-12-22 15:27:52.026 | DEBUG    | ivadomed.inference:get_preds:89 - Conduct ONNX model inference...
2021-12-22 15:27:52.157 | DEBUG    | ivadomed.inference:get_preds:92 - Sending predictions to CPU
2021-12-22 15:27:52.168 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-22 15:27:52.168 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-22 15:27:52.168 | WARNING  | ivadomed.inference:segment_volume:402 - fname_roi has not been specified, then the entire volume is processed.
2021-12-22 15:27:52.179 | INFO     | ivadomed.inference:segment_volume:435 - Loaded 1 axial volumes of shape [32, 64, 128].
2021-12-22 15:27:52.180 | INFO     | ivadomed.utils:define_device:135 - Using GPU ID 0
2021-12-22 15:27:52.180 | DEBUG    | ivadomed.inference:get_preds:88 - Likely ONNX model detected at: seg_lesion_output/seg_lesion_model/seg_lesion_model.onnx
2021-12-22 15:27:52.181 | DEBUG    | ivadomed.inference:get_preds:89 - Conduct ONNX model inference...
2021-12-22 15:27:52.337 | DEBUG    | ivadomed.inference:get_preds:92 - Sending predictions to CPU
2021-12-22 15:27:52.364 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-22 15:27:52.364 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-22 15:27:52.364 | WARNING  | ivadomed.inference:segment_volume:402 - fname_roi has not been specified, then the entire volume is processed.
2021-12-22 15:27:52.382 | INFO     | ivadomed.inference:segment_volume:435 - Loaded 1 axial volumes of shape [32, 64, 128].
2021-12-22 15:27:52.395 | INFO     | ivadomed.utils:define_device:135 - Using GPU ID 0
2021-12-22 15:27:52.395 | DEBUG    | ivadomed.inference:get_preds:88 - Likely ONNX model detected at: seg_lesion_output/seg_lesion_model/seg_lesion_model.onnx
2021-12-22 15:27:52.395 | DEBUG    | ivadomed.inference:get_preds:89 - Conduct ONNX model inference...
2021-12-22 15:27:52.540 | DEBUG    | ivadomed.inference:get_preds:92 - Sending predictions to CPU

And here are the segmented files as a result:
Terminal output
(um_main) uzmac@romane:~/model_seg_ms_mp2rage$ ls seg_lesion_output/pred_masks/
sub-P001_UNIT1_lesion-manual_pred.nii.gz  sub-P013_UNIT1_lesion-manual_pred.nii.gz  sub-P025_UNIT1_lesion-manual_pred.nii.gz
sub-P002_UNIT1_lesion-manual_pred.nii.gz  sub-P014_UNIT1_lesion-manual_pred.nii.gz  sub-P026_UNIT1_lesion-manual_pred.nii.gz
sub-P003_UNIT1_lesion-manual_pred.nii.gz  sub-P015_UNIT1_lesion-manual_pred.nii.gz  sub-P027_UNIT1_lesion-manual_pred.nii.gz
sub-P004_UNIT1_lesion-manual_pred.nii.gz  sub-P016_UNIT1_lesion-manual_pred.nii.gz  sub-P028_UNIT1_lesion-manual_pred.nii.gz
sub-P005_UNIT1_lesion-manual_pred.nii.gz  sub-P017_UNIT1_lesion-manual_pred.nii.gz  sub-P029_UNIT1_lesion-manual_pred.nii.gz
sub-P006_UNIT1_lesion-manual_pred.nii.gz  sub-P019_UNIT1_lesion-manual_pred.nii.gz  sub-P030_UNIT1_lesion-manual_pred.nii.gz
sub-P007_UNIT1_lesion-manual_pred.nii.gz  sub-P021_UNIT1_lesion-manual_pred.nii.gz  sub-P031_UNIT1_lesion-manual_pred.nii.gz
sub-P010_UNIT1_lesion-manual_pred.nii.gz  sub-P022_UNIT1_lesion-manual_pred.nii.gz  sub-P033_UNIT1_lesion-manual_pred.nii.gz
sub-P011_UNIT1_lesion-manual_pred.nii.gz  sub-P023_UNIT1_lesion-manual_pred.nii.gz  sub-P034_UNIT1_lesion-manual_pred.nii.gz
sub-P012_UNIT1_lesion-manual_pred.nii.gz  sub-P024_UNIT1_lesion-manual_pred.nii.gz  sub-P035_UNIT1_lesion-manual_pred.nii.gz

As mentioned https://github.com/ivadomed/model_seg_ms_mp2rage/issues/27
Linked issues

Resolves #816.

Two thoughts:

An alternative implementation might include implementing the fix the segment_volume() function

https://github.com/ivadomed/ivadomed/blob/d1b9e118f491d9e5e88523f8d0f0cae65b26ecca/ivadomed/inference.py#L321
which returns the target_list in the first place. I just thought target_list with multiple raters might be utilized in a future use case after its returned by segment_volume() so this is why I didn't touch it there.

Is getting the first element in the list a plausible solution? As shown in my results above, a target_suffix with [["_lesion-manual", "_lesion-manual2"]] will yield segmentation files with names XXX_lesion-manual_pred.nii.gz. Other possibilities include

getting rid of _lesion-manual all together
creating a new suffix for the multiple rater cases, e.g. _multirater (probably a bad idea?)

Any other ideas / thoughts?

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 2 (0.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.02%) to 69.401%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

ivadomed/main.py
0
2
0.0%

Totals

Change from base Build<PHONE_NUMBER>:
-0.02%

Covered Lines:
4010

Relevant Lines:
5778

💛  - Coveralls

An alternative implementation might include implementing the fix the segment_volume() function
which returns the target_list in the first place. I just thought target_list with multiple raters might be utilized in a future use case after its returned by segment_volume() so this is why I didn't touch it there.

Yes, segment_volume is more tricky as it is the API used by SCT and ADS to do the segmentation, and is used by object detection. I'm not sure but I think it might fail as well with multiple raters in those cases, this would need to be tested. If it doesn't fail, I would go with the fix in run_segment_command.

Is getting the first element in the list a plausible solution? As shown in my results above, a target_suffix with [["_lesion-manual", "_lesion-manual2"]] will yield segmentation files with names XXX_lesion-manual_pred.nii.gz. Other possibilities include

I think that getting the first element is a good idea in the current implementation but would not always give meaningful results. It works great in your cases but with the example from #546, the files would be called XXXX__gmseg-manual-ucl_pred.nii.gz and  XXXX__wmseg-manual-ucl_pred.nii.gz which is not ideal.
 "target_suffix": [["_gmseg-manual-ucl", "_gmseg-manual-unf", "_gmseg-manual-vanderbilt", "_gmseg-manual-zurich"],
                            ["_wmseg-manual-ucl", "_wmseg-manual-unf", "_wmseg-manual-vanderbilt", "_wmseg-manual-zurich"]],

getting rid of _lesion-manual all together
creating a new suffix for the multiple rater cases, e.g. _multirater (probably a bad idea?)

We can't get rid of _lesion-manual all together because if you have more than one class, you will need a distinction between the two classes, as shown in the example above.
Creating a new suffix yield the same issue (how to distinguish 2 classes).
The whole question comes back to a previous issue we discussed recently about the naming of prediction files in #1006.
We might want to tackle this other issue first, or go with the "first element" for the time being in this PR.

Any other ideas / thoughts?

I think it would be great to have opinions of others as well on this.

This PR is closed as a new PR #1043 is implemented which addresses the discussions and linked issues in the comments above.


fix ini #13648

Divided ini file(use comment ;) and other like ini file (use comment #)
and use INI syntax highlighting for Sublime Text 2
related #8709

Thanks @Ikuyadeu . There's a spelling mistake in propaties. Other than that the changes look good.

@aeschli ,　Thank you for correcting my mistakes.
typo was fixed.

Thanks @Ikuyadeu, PR accepted!

I made a change to use the same grammar ("./syntaxes/properties.plist") for both ini and properties.
It's not clear where https://github.com/clintberry/sublime-text-2-ini comes from. We can only add it to VSCode if the license allows it.


[vcpkg] WIP: Versioned portfile provider

Implementation of VersionedPortFileProvider which is responsible for retrieving sources for a port at a specific version.
It should offer an interface similar to other portfile providers, but take versioning specs:
::get_port_versions(std::string port_name) -> const std::vector<VersionSpec>&
::get_control_file(VersionSpec spec) -> ExpectedS<const SourceControlFileLocation&>

/azp run

@strega-nil @BillyONeal @ras0219
I think this is ready for merge now. I will investigate the git archive method in a separate PR.

/azp run

/azp run


Position.direction_to() should return all directions which are shortest path

Currently, Position.direction_to(target_pos: Position) -> DIRECTIONS will return only a single direction. However, most of the time there are two possible directions for the shortest path. For implementing a move optimizer it is important to know all possible shortest path directions as there are usually 2 (unless some coordinate is identical).
Therefore, I suggest to implement the function as Position.direction_to(target_pos: Position) -> Set[DIRECTION] which returns a set of all directions in order to most quickly reach the destination.
For example Position(1,1).direction_to(Position(2,2)) -> {"s", "e"}

per discussion on discord. Not sure if this will be added as I also think this is a matter of preference. Leaving this issue open so that other competitors can see and also consider using since it is helpful depending on how your navigation algo works

Or the new function could be called directions_to(...)
Then one can leave the old function. Even though I cannot imagine that someone would not care about knowing all directions. If the arbitrary direction is blocked, it would be a hassle trying to figure out the remaining optimal direction. Unless you are fine with workers standing still due to being blocked and not going the equally shortest path.


[dev_1.2.1]Workflow instance does not show dependencies

@break60

+1
------------------ 原始邮件 ------------------
发件人<EMAIL_ADDRESS>发送时间: 2020年1月13日(星期一) 下午2:32
收件人<EMAIL_ADDRESS>抄送: "数码港"<790061044<EMAIL_ADDRESS>主题: Re: [apache/incubator-dolphinscheduler] [dev_1.2.1]Workflow instance does not show dependencies (#1810)
@break60
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.


🫡 Wallet Resume PSBT for COMMIT & REVEAL are NULL

When running Resume, more than 6 blocks after maturity of commit, the reveal transaction is broadcasted, but in the console it shows NULL for PSBT in both the commit and the reveal transactions printed.
Can someone please include the PSBT of these transactions in RESUME? 🙏🙏

What's the purpose of this though after it's broadcasted, what's the use of PSBT?

It's more helpful before it's broadcasted no?

@ryguy077 Have fixed it anyway for other usecases, should fix this issue too here - https://github.com/ordinals/ord/pull/3714


Integration into the image crate

Would you be interested in adding jxl-oxide integration to the image crate?
It would be very convenient if users of image could decode jxl-oxide through its format-agnostic API without having to write code specific to JPEG XL themselves.
The format integrations are not complicated. For example, here's the qoi codec integration: https://github.com/image-rs/image/blob/master/src/codecs/qoi.rs

FWIW the zune-image library already uses jxl-oxide, but it is not as widely used as image because it supports fewer formats and its API is still unstable.

this was rejected by image-rs maintainers https://github.com/image-rs/image/issues/1979
I no longer plain on maintaining the PR to add it unless something changes

I see. Thank you!

Strange for a Microsoft employee to have such a hard-line stance on what denotes a "free" format. I would not hold my breath on this, unfortunately.

It is possible to provide APIs for easy interoperability with the image crate's types without having to modify the image crate itself. For example, https://crates.io/crates/turbojpeg does this behind the image feature.
If the integration PR is already written, perhaps it's best to just put the integration into this crate behind a feature flag instead.

It is possible to provide APIs for easy interoperability with the image crate's types without having to modify the image crate itself. For example, https://crates.io/crates/turbojpeg does this behind the image feature.

this could be nice to have. Considering the maintainer of the image crate doesn't seem to want JXL inside of it, it may be the best route forwards or maybe a small shim crate.

@Shnatsel I completely forgot to mention this a while ago, zune-image provides interop with the image crate, which is probably going to be good enough

zune-image stores all the channels in separate vectors. So if one were to load a JPEG XL image into zune-image and then back into image, it would waste CPU cycles and memory on deinterleaving and then interleaving the data right back.

What is the most performant way to convert decoded file in jxl-oxide to DynamicImage?
I use for now this code, but is slow and hotspot shows, that most of the time is spend not in my code
pub fn decode_jxl_image(path: &str) -> anyhow::Result<JxlImage> {
    let buf_reader = std::io::BufReader::new(File::open(path)?);
    JxlImage::builder().read(buf_reader).map_err(|e| anyhow::anyhow!("Failed to read jxl file {e}"))
}

pub fn get_jxl_image(path: &str) -> anyhow::Result<DynamicImage> {
    let decoder = decode_jxl_image(path)?;
    let width = decoder.width();
    let height = decoder.height();
    let frame = decoder.render_frame(0).map_err(|e| anyhow::anyhow!("Failed to render jxl frame {e}"))?;
    let planar = &frame.image_planar();
    let pixfmt = decoder.pixel_format();
    let bits_per_sample = decoder.image_header().metadata.bit_depth;

    if bits_per_sample.bits_per_sample() == 8 && pixfmt == PixelFormat::Rgb && planar.len() == 3 {
        let zips = planar[0].buf().iter().zip(planar[1].buf().iter()).zip(planar[2].buf().iter());
        let pixels = zips.flat_map(|((r, g), b)| [(r * 255.0) as u8, (g * 255.0) as u8, (b * 255.0) as u8]).collect::<Vec<_>>();
        let data = ImageBuffer::<Rgb<u8>, Vec<u8>>::from_vec(width, height, pixels).ok_or_else(|| anyhow::anyhow!("Failed to create rgb image buffer from jxl data"))?;
        Ok(DynamicImage::ImageRgb8(data))
    } else if bits_per_sample.bits_per_sample() == 8 && pixfmt == PixelFormat::Rgba && planar.len() == 4 {
        let zips = planar[0].buf().iter().zip(planar[1].buf().iter()).zip(planar[2].buf().iter()).zip(planar[3].buf().iter());
        let pixels = zips
            .flat_map(|(((r, g), b), a)| [(r * 255.0) as u8, (g * 255.0) as u8, (b * 255.0) as u8, (a * 255.0) as u8])
            .collect::<Vec<_>>();
        let data = ImageBuffer::<Rgba<u8>, Vec<u8>>::from_vec(width, height, pixels).ok_or_else(|| anyhow::anyhow!("Failed to create rgba image buffer from jxl data"))?;
        Ok(DynamicImage::ImageRgba8(data))
    } else {
        return Err(anyhow::anyhow!("Unsupported number of planes: {}", planar.len()));
    }
}

I expect the performance to be about the same, but Quackdoc w/ COSMIC does it like this:
https://github.com/Quackdoc/cosmic-bg/commit/600d15279297e3ba4c2d9f86072fc2a41558d0a7#diff-c5bc08d47db869d79896a5debf57e1745456e6edbdf2dcc09c9297689c03827aR394
If you want to profile that as well I would be curious, but tirr-c might know of any better options?
This feature would certainly be appreciated given the image crate stance!

@qarmin: Decoding would be rather slow if multithreading is disabled (it's enabled by rayon feature which is on by default), which seems to be the case in the flamegraph above.
@xangelix: .stream() is better when retrieving output because it does less buffer allocations and copies, but as for now it can only output F32 samples. I plan to extend this API to be able to output also U8 or U16.

jxl-oxide git head now has an integration to the image crate under image feature flag.


Compare deeprank-core and deeprank features

Features that we currently have in deeprank-core, with the nomenclature in the hdf5 files.
Edge features (edge_features Group in the hdf5 files):

metafeatures: "_name", "_index"
generic features: "same_chain", "same_res", "distance"
interactions: "covalent", "electrostatic", "vanderwaals"

Node features (node_features Group in the hdf5 files):

metafeatures: "_name", "_chain_id", "_position"

residue core features: "res_type", "charge", "polarity", "res_size", "res_mass", "res_pI", "hb_donors", "hb_acceptors"

variant residue features: "variant_res", "diff_charge", "diff_size", "diff_mass", "diff_pI", "diff_polarity", "diff_hb_donors", "diff_hb_acceptors", "diff_conservation"

protein context features: "bsa", "hse", "sasa", "res_depth"

conservation features: "pssm", "info_content", "conservation"

atom core features: "atom_type", "atom_charge", "pdb_occupancy", "vdw_parameters"

[ ] Which ones are not needed for grids?

[ ] Which ones are missing from the original deeprank for grids?

I did not find the feature list in the Nat. Comm. paper... The feature list was printed out in the log file. The log file was not backed up. So the easiest way I think is to run the example of DeepRank-CNN for "A . Generate the data set (using MPI)": https://github.com/DeepRank/deeprank. Make sure to set "compute_features='all' "

I remember that the Deeprank-CNN has the following features:

electrostatic
vanderwaals
charge
bsa
pssm, info_content, conservation
atomic densities per atom-type

I recently noticed that the original deeprank stores features per chain. Examples:

vdwaals_chain1
vdwaals_chain2

Does this need to be done like this in deeprank-core as well?

I did not find the feature list in the Nat. Comm. paper... The feature list was printed out in the log file. The log file was not backed up. So the easiest way I think is to run the example of DeepRank-CNN for "A . Generate the data set (using MPI)": https://github.com/DeepRank/deeprank. Make sure to set "compute_features='all' "

I tried running this script, but "compute_features='all' is not a valid input. Instead, I used all the feature module names I found in the features folder, assuming there were no other feature generating modules anywhere else.
compute_features=[
        'deeprank.features.AtomicFeature',
        'deeprank.features.BSA',
        'deeprank.features.FullPSSM',
        'deeprank.features.PSSM_IC',
        'deeprank.features.ResidueDensity']

I uploaded the hdf5 file to this branch: https://github.com/DeepRank/deeprank-core/tree/279_compare_cnn_features_dbodor/tests/data/hdf5
The following features are present in the hdf5 file:

bsa, charge, coulomb, vdwaals, pssm_ic

all of these also exist in deeprankcore

PSSM

20 separate features; 1 per amino acid
in deeprankcore we have a single PSSM feature that contains all of these in one-hot encoding

7 x RCD

total + 6 permutations of polar/apolar/charged
I believe RCD stands for residue contact density
I don't know whether we have an equivalent of this in deeprankcore (see features listed by Giulia above)

In addition, there is a separate group called "features_raw", which contains the same named features as the "features" group, but with different and differently shaped values.
Finally, there is a group called "mapped_features", which has all above mentioned features as well, but in duplicate, once per chain. In addition, mapped features has an "AtomicDensities" group with 8 subgroups: C, N, O, and S for each chain.

@cbaakman and @LilySnow, could you please take a look at my comment above and let me know:

Did I catch all the features using the 5 modules I listed above, or are there others I missed?
Re: RCD features

what are these precisely
do we have an equivalent of them current deeprank (see top comment by Giulia for full list)
if not, do we need them in deeprankcore as well?

Re: AtomicDensities group in mapped_features

do we need these in deeprankcore as well?
if so, would it be covered by the RCD stuff listed above, or is it something separate?

Is the difference between "features" and "features_raw" something we need to implement in deeprankcore?

If so, please explain what these are

Do we need to do a careful comparison of the content/shape of the different features in addition to just looking at their existence?

I don't know the answers to most of these questions. But I always understood that features_raw was no longer used.
Also, atomic densities seem to be a feature that should be available, but it can not be mapped to the grid with the current deeprank-core code.

Indeed, we do not currently have a feature module to compute that.
Looking at the ResidueDensity.py module in deeprank (CNN), it appears that this feature is just a count of the number of other residues within a certain cutoff radius; either the total number or the number of a certain polarity.
It shouldn't be too difficult to add a feature to deeprankcore to count these as well. I'll open an issue for that.

Also, atomic densities seem to be a feature that should be available, but it can not be mapped to the grid with the current deeprank-core code.

If I understood @DarioMarzella correctly, these represent the proportion of the voxel that is occupied by each atom. Is that right? If so, I assume that the "Feature_Ind" group is the equivalent of that, where the features are mapped onto the grid.
If all this is true, then I believe the current code can and does actually create the atomic denisty features. To test it quickly, I created an atom level grid (adjusting the integration test was the quickest/easiest way to do it) with all the features. I believe that the the "atom_type_000" (etc) features of this file  are equivalent to the "AtomicDensity" features from the original deeprank hdf5 file, except that they are one-hot encoded instead of names by atom type.
Can you check and confirm this please, @cbaakman.

I made a script to compare the data:
import h5py
import numpy as np
from typing import Tuple

def _inflate(index: np.array, value: np.array, shape: Tuple[int]):

    data = np.zeros(shape[0] * shape[1] * shape[2])
    data[index] = value[:,0]

    return data.reshape(shape)

def test_compare():

    with h5py.File("deeprank_CNN.hdf5", 'r') as f5:

        chain1_c_group = f5["1AK4_cm-it0_745/mapped_features/AtomicDensities_ind/C_chain1"]
        chain1_c_index = chain1_c_group["index"][:]
        chain1_c_value = chain1_c_group["value"][:]

        old_chain1_c_data = _inflate(chain1_c_index, chain1_c_value, (30, 30, 30))

        chain2_c_group = f5["1AK4_cm-it0_745/mapped_features/AtomicDensities_ind/C_chain2"]
        chain2_c_index = chain2_c_group["index"][:]
        chain2_c_value = chain2_c_group["value"][:]

        old_chain2_c_data = _inflate(chain2_c_index, chain2_c_value, (30, 30, 30))

    with h5py.File("grid_atomic.hdf5", 'r') as f5:
        new_c_data = f5["atom-ppi-1ATN_1w:A-B/mapped_features/atom_type_000/value"][:]

    assert np.all(np.abs((old_chain1_c_data + old_chain2_c_data) - new_c_data) < 0.001), "not the same"

However, it turns out that the two datasets do not have the same grid box settings. So comparing is impossible. I do think that your theory is correct. Where is your code located?

Where is your code located?

You mean to create the hdf5 file? Honestly, I did a quick & dirty adjustment of the test_integration_cnn() function and didn't save it. I just changed the prefix to a local folder so that it wouldn't get deleted by rmtree.
For the hdf5 file from deeprank (not core), I followed the readme instructions

Not sure whether we need atomic density in fact, because when we map the one-hot encoded feature for each atom to grid, we already used Gaussian

Not sure whether we need atomic density in fact, because when we map the one-hot encoded feature for each atom to grid, we already used Gaussian.

Do you mean we don't need it as a separate feature from the current "atom_type_" features, or do you mean that we don't need either?
The first I agree, because they are the same thing. The second I don't see why we wouldn't want the atom type feature.
I also don't understand what you mean by "we already used Gaussian". Is that the way to map the features onto the grid?


Support of v-prefixed tags?

Hey,
Are v-prefixed tags supported?
With a little experiment I did (with the latest version of autotag), this didn't seem to work for me:
My latest tag was v1.0.4,  so I'd expect my next (patch) tag would be v1.0.5. From some reason, I've got 1.0.5 (without v):
❯ git describe --abbrev=0 --tags
v1.0.4

and when running autotag:
❯ ./bin/autotag -n
1.0.5

I even saw there is a flag that let you disable it (-e, --empty-version-prefix   Do not prepend v to version tag), so that hints it should work by default, no?
Is it on purpose? If yes, what am I doing wrong and how can I config it to work with v-prefixed tags?
Thanks!

Ok, I think I've found the issue:  regardless whether the tag is prefixed or not, The print line is without it (as can be seen here). Since I used the -n flag, it didn't apply the prefix logic (here), and just logged the latest version (which is always without v). This is why I thought it didn't work.
I think this is a bit misleading, and maybe it's best to log the exact tag which is going to be created.

I see your point. I think the intent here is to communicate just the numeric version that will be iterated. Historically we had used this for storing some related info that did not want the v prefix. I see how coming into the tool fresh means this behavior may be a bit surprising.  I don't think we should change the default behavior as it's already being used as-is. Though I think it's a good candidate for a next  "major" bump or as a new flag, but I am also weary of adding more flags.

@spheromak thanks for the answer. I guess I can manually prefix the v before pushing the tag, just wanted to raise awareness of that behavior

it makes sense to me that -n (print next version; don't create git tag) would output with the same v prefix as would be used if a tag was created. but as @spheromak mentioned this would be a breaking change. i'm not sure we would even want to fix it in a v2 release though


Use void as argument, sometimes error and sometimes no

`
function a(b: void) {
}
a();
`
There's an error here as follow:

TS2554: Expected 1 arguments, but got 0

How do I fix it, Thank you in advance!!!

No error I can see Playground
There are limitations around void params and conditional types and generics but simple stuff should work (https://github.com/microsoft/TypeScript/issues/29131)

No error I can see Playground
There are limitations around void params and conditional types and generics but simple stuff should work (#29131)

but I get errors using webstorm

Is there a configuration problem?

No error I can see Playground
There are limitations around void params and conditional types and generics but simple stuff should work (#29131)

The reason is that my typescript version is too low, thank you very much


Update control_flow opcode cost.

This change backports changes from the 1.4.9 release onto the dev branch and fixes all the affected tests due to the control_flow opcode increase.
All necessary changes from private release-1.4.9 are squashed into one commit, with extra changes essential due to many merge conflicts.

bors merge

bors merge