If a new project with a bigger resolution is loaded in, it is cropped to the size of the first loaded project.
Disabling and then enabling the CalibFilter/Undistortion solves this problem; so the error lies in CalibFilter.
The problem is related to the caching the calib filter does. Seems like, despite new intrinsic parameters, the CalibFilter thinks nothing has changed...
During reading of the XML, some changes after reading in the intrinsic parameters trigger on_*_valueChanged slots and in these updateImage is called. Since to this point it's still the old image, CalibFilter creates maps with the size of the old image. And since the intrinsic parameters were already set, afterwards the cached, too small, mappings were used.
We should define a proper closing process for a opened project, e.g., which values need to be unset, invalidated such that a new project can be properly opened.
We save a XML with the default values in the constructor of Petrack. These default values get read in void Petrack::resetSettings() (which kinda makes resetUI obsolete...)
So we have that problem already solved (quite elegantly actually, since everything gets added to this mechanism once it saves to the pet). We "just" need to assure the updated values get propagated to everything correctly (instead of the whole thing crashing because of a changed border size or sth. like that).
Ok, so there are 3 things loaded via other files than the .pet-File, which is already covered. (At least that I am currently aware of, please correct me if I'm wrong) These are:
Points for extrinsic calibration
Images for intrinsic calibration
Trajectories
Trajectories already get deleted when loading a sequence, so this is essentially already covered.
The path to the images for intrinsic calibration (as well as the result of the calibration itself) are saved in the .pet-file, so this is covered as well.
The same goes for the extrinsic calibration. Only the points selected on runtime (via fetch points) do not get reset (which probably is mostly not interesting). Tracking and reverting all runtime changes not saved in the .pet is probably going to be quite error prone. So we should think about a mechanism to control this behaviour differently.
This could mean, actually saving everything, the whole state of all objects, in the .pet.
Or this could mean we have a project-Object saving (transitively) the application-state, which can just be reassigned with a newly constructed one, automatically resetting everything in the process. This is, however, no easily done currently, since a lot of data is in the GUI, which cannot be easily destructed and replaced, see #123
Also im not quite sure yet, how such a project-object should look like ideally.
Of course there might be way better options, I'm currently not seeing.
Also, I'm not quite sure if we want a true reset. Things like, e.g. saved paths for opening file dialogs in the right folder, could be deleted as well.