Allow installation of previous versions alongside latest version — new versions constantly broken
If we’re going to push the limits and add features at a pace that constantly breaks fundamental features of the app, then at least let us downgrade to previous versions so that we can actually have a chance at completing large reconstructions using reliable software.
-
Yea, I mean the very nature of this software is that for a certain subset of users it is handling huge amounts of incredibly varied data over very long amounts of time, so it must be impossible to find edge-case bugs for those users before releasing an upgrade to the general public. It’s pretty easy to test against simple datasets, but the power users are going to throw some crazy challenges at the software that will reveal bugs that may require days or even weeks of reconstruction time to even find, let alone fix.
This is all fine, just part of the process, but also I can’t just wait around wasting days and weeks of my year, trouble shooting issues, and waiting for fixes, when I’m on a deadline and I know that previous versions just worked.
-
You can download installation file for a wanted release here: https://support.capturingreality.com/hc/en-us/sections/115001056925-New-Releases
To uninstall you current version, you need to have its installation file and open that file.
-
Hi,
is there any progress on that front? Being able to download older installers is fine and all, but we're not able to run them because we're forced into updating the older version to the current one. 1.2.0 broke our workflow and it would be nice to be able to just use 1.1 Blaze again.
-
Hi S_SC_, there weren't any changes there.
-
this shows the textured reconstruction vs the ground truth on the bottom.
it's a bit of a constructed example, because we usually use 24MP source images instead of 12MP like here, but it's demonstrating the issue we have with our textures (and that's probably a result of the alignment/reconstruction) since 1.2.0. In Blaze the results from that same setup looked crisp. The camera positions are exported via XMP as locked.
-
we are creating sort of a calibration with a calibration object, export the XMPs and then use these for all subsequent captures. that worked very well until 1.2.0 came out. we've now tried for weeks to find the issue with the capturing, camera positions etc pp, but the only difference to when it last worked, is the software version of RC.
-
we use 3 cameras, it's a turntable, yes. for calibration we use a couple of CPs and some ground control points to fix the coordinate system, and then we export the XMPs and the reconstruction region from the calibration project. the reconstructed calibration looks prestine and the textures are very good there, so the alignment in the calibration project is great.
-
it was recommended to export the XMPs as fixed positions, so that's what we did and that worked fine before. now the alignment seems to be just a little bit off between the images, even when the intervals between captures are precise (which they are not always), but Blaze managed to compensate for slight mistimings in the capturing process and still created good looking results. we just assume by now, that something changed internally in how the XMP calibration is being treated or whatever, we just cannot put a finger on it and how to solve it.
-
Yes, sure, can you send me the link to the data on trhond@capturingreality.com address?
Please sign in to leave a comment.
Comments
24 comments