When setting a temporary CameraInit node, the intrinsics of the actual
CameraInit node are used, meaning that the temporary CameraInit has all
the intrinsics information we need to fill the intrinsics table.
However, when a temporary CameraInit node is set, the parsing of the
intrinsics and the model update are not performed. If the active CameraInit
group does not change, this is not directly visible as the table keeps on
displaying the intrinsics from the actual CameraInit node.
If the active group changes, we attempt to fill the table with the
intrinsics of the temporary CameraInit node, which is being re-set for the
active group. The intrinsics are thus not available, leading to an empty
table, and the parsing is never retriggered once the temporary CameraInit
has been fully set.
Instead of re-parsing the intrinsics when the CameraInitIndex is updated,
the parsing is triggered when the intrinsics are updated, since this
ensures they will be available and its covers all the cases we could
be facing.
When there is a temporary CameraInit, it means that either the "Visualize
HDR images" or "Preprocessed images" options are enabled.
If several CameraInit groups are available, and if the currently selected
image in the GridView is the first one (index = 0), there is a possibility,
depending on the input images, that the first images in two different
groups are not identical but have the same view ID. If that happens, there
will be no update of the Viewer2D, as the selectedViewId property will not
have been modified.
By setting the selectedViewId property to -1 when there is a temporary
CameraInit and the current index in the GridView is 0, we trigger an
update of the viewer even when there is no apparent change in the view ID.
A project needs to be saved in order to be submitted to the renderfarm.
Prior to this commit, attempting to submit an unsaved project would not
prompt any dialog in the UI despite the exception that was thrown on the
Python side.
A warning dialog is now opened to let the user know that the project
cannot be submitted until it is saved.
"Load Template" allows to load an .mg file as a regular project file,
without taking into account if it is a template.
If the project file is not a template, it will be opened exactly as if the
"Open File" menu had been used. If it is a template and it contains
"Publish" nodes, they will not be filtered out (whereas they will be if
the template is opened with "Open File" or through the "New" actions).
This ensures that each node's status is correct before being computed,
submitted, or before having its data deleted. This is especially useful
when the File Poller is in minimal node, and only monitors the nodes that
are currently submitted or running.
If a graph is being opened in two different instances of Meshroom, and
computations are started on it in one of the instances, the other one will
not be aware of it (as the signals indicating computations have started
will have been emitted in the first instance, so no chunk will be added
to the monitoring in the second one). By forcing the update of the statuses
before actually starting computations or deleting data, we ensure that
there will not be any computational conflicts (same nodes submitted twice
in farm, for example) and that the users can know at all times what they
are doing without manually triggering a refresh.
This is not critical for the "Delete Data" part, as the action can already
be triggered even with there is no data to delete, but is still useful
to keep the displayed nodes as up-to-date with their actual status as
possible.
The default auto-refresh mode of the file watcher checks, every 5 seconds,
every single chunk's status, which may be overkill. Instead of simply
disabling the file watcher, this commit adds a third option that checks,
every 5 seconds, the status of submitted and running chunks. If no chunk
is currently submitted or running, then the file watcher's thread keeps
on running but does nothing.
Additionally, the file watcher is automatically disabled by default if
Meshroom is started without a submitter.
By default, the file watcher polls every single node's file every 5
seconds, independently from their status. This commit adds a button
in the GraphEditor to disable or enable the file watcher at will.
The SfmStatsView and SfmGlobalStats components used to be loaded once
and for all with "Component.onCompleted". With the upgrade to Qt 5.14,
it is needed to load and explicitly unload the component (by resetting its
source) for the statistics to always be correctly displayed. Otherwise,
they can be loaded and viewed only once per session; after being shown for
the first time, they are set to null and never reloaded.
This commit uses the same type of loading/unloading as all the other
components in the 2D Viewer.
"Clear Images" used to clear the intrinsics and viewpoints for all the
existing CameraInit nodes in the graph. There was no-user friendly way
to clear the images of a specific CameraInit node.
This commit modifies the behaviour of "Clear Images" so that it only
deletes the intrinsics and viewpoints of the current CameraInit. A new menu
action, "Clear All Images", is added in the "Advanced" sub-menu, and
deletes all the intrinsics and viewpoints for all the CameraInit nodes.
The way images are cleared is also modified: instead of removing the
intrinsics and viewpoints attributes, they are reset. To be undone
properly, a corresponding "ClearImagesCommand" has been added. This offers
a great performance increase (clearing 1000 images now takes 1s).
Tooltips have been added to make the distinction clearer for users.
Selecting any filter in the Image Gallery changes the displayed content of
the gallery according to the filter. Unselecting any filter automatically
switches the displayed content back to the "input images" filter (which
simply displays all the input images), but the "input images" button is
never reselected, meaning that there can be a display corresponding to a
filter without any filter being selected.
This commit prevents unselecting a filter without reselecting the one
corresponding to the display. Since the "input images" is always the
display that is reverted to, unselecting any filter automatically selects
its button.
This commit fixes an "Unable to assign QJSValue to QObject*".
In IntrinsicDisplayDelegate, initialize the "attribute" variant to null
and set it as a parameter during the instantiation in ImageGallery.
All references to "model.display" in IntrinsicDisplayDelegate have been
replaced with a correct use of "attribute".
The tooltip now displays both the invalidation message, followed by the
comments. The invalidation message is displayed first in bold font,
followed by an empty line and the comments in regular font.
The tooltip now appears if at least one of the invalidation or comment
messages exists.
The invalidation and comment messages are formatted with HTML tags prior
to their display. The descriptions of both attributes is also updated
to indicate which one is displayed in bold or regular font.
The "label", "color" and "comment" properties are not constant anymore,
their changes in value are notified with the internalAttributesChanged()
signal, like the "invalidation" property.
This implies that the connection on "internalAttributesChanged" on the
QML side is not needed anymore.
Setting this attribute allows the user to change the color
of a node, either by directly providing an SVG color name or an
hexadecimal color code, or by picking a color with the selector.
Add two internal attributes, "Comment" and "Invalid comment", in
a specific "Notes" tab, which will contain any further internal
attribute. Internal attributes exist for all nodes.
The "Clear Images" action was performed solely on the QML side, updating
the graph with every intrinsics removal, which considerably slowed down
the whole process.
The QML action now calls a slot on the Python side, which can disable
the graph updates at every modification, thus greatly improving the speed
of the process.
As a point of comparison, clearing 511 PNG images took approximately 38s
on the QML side, against 8s on the Python side. Clearing 1000 PNG images
took 2min39 on the QML side, against 32s on the Python side.
As we rely on the thumbnails cache, the images are already downscaled at
a small resolution. So there is no more need to force a max resolution
on the Qml Image.
