If creating panoramas, the resulting pic has half of the resolution than original pics with 150. So, any tiny amplification shows up with primitiy quality gaps as steps as a results of unsatisfying resolution. Half of the resolution of original pic is wasted (according to numbers in digiKam exif-data). Reproducible: Always Steps to Reproduce: 1. just run digiKam "stitching pics into panorama" 2. 3. Actual Results: minor quality Expected Results: should have at least the same resolution than original pics, better more (to gain some reserves)
First, what do you mean by "with 150"? I've seen since behavior in the past and I didn't find any solution at the time. At the moment, my best guess is that Hugin (the software behind this plugin) reduces the resolution of the overall panorama such that it doesn't extropolate (create new) pixels at both ends of the image. In fact, in these regions, the image is far more stretched than in the center, especially for large panorama, such that two pixels of the original photos becomes several pixels in the panorama if the resolution is kept the same as in the originals for the center of the panorama. If this is your case, my advice is to use Hugin and switch to a different projection. This plugin is not meant for obtaining good results with any scenario, but only in the simplest ones, for example with a row of 3 photos, or to get a first impression of the stitching quality before processing the panorama more thoroughly with Hugin.
When going to EXIF-Data, image information, I see "300" as resolution of any original pic. With panorama stitched pics, resolution halfes to "150". I take this for serious limitation, as the resulting panorama pic is base of additional treatment steps. So, refining steps as "minimizing noise", "smoothening", "sharpening" and other treatment further decrease original qualities. I did some resarch myself concerning settings within HUGIN- without success. Besides, I tried extensively to get helpful info of Prof. Dersch's homepage at Furtwangen Highschool, Germany. He seems to be one of the developers of panorama tool <http://webuser.hs-furtwangen.de/~dersch/>. You may want to check out his pages. Stitching tool is very hlpfukl in simply caeses, as you express. As much as I remember, I suggestet it for precisely this scenario some time ago... Axel --- Am 31.10.2012 21:47, schrieb Benjamin Girault: > https://bugs.kde.org/show_bug.cgi?id=309339 > > Benjamin Girault <benjamin.girault@gmail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |benjamin.girault@gmail.com > > --- Comment #1 from Benjamin Girault <benjamin.girault@gmail.com> --- > First, what do you mean by "with 150"? > > I've seen since behavior in the past and I didn't find any solution at the > time. > > At the moment, my best guess is that Hugin (the software behind this plugin) > reduces the resolution of the overall panorama such that it doesn't extropolate > (create new) pixels at both ends of the image. In fact, in these regions, the > image is far more stretched than in the center, especially for large panorama, > such that two pixels of the original photos becomes several pixels in the > panorama if the resolution is kept the same as in the originals for the center > of the panorama. > > If this is your case, my advice is to use Hugin and switch to a different > projection. This plugin is not meant for obtaining good results with any > scenario, but only in the simplest ones, for example with a row of 3 photos, or > to get a first impression of the stitching quality before processing the > panorama more thoroughly with Hugin. >
The DPI entry in the metadata does not have a direct relation to the image. You can change the DPI entry without affecting the image in any way. The only use of the DPI entry is to combine with actual pixel count to produce a size in inches. So please confirm if the pixel count of the images are consistent. ie stitch two images together then pixel width should be doubled minus an allowance for the overlap. If that is so then the change in DPI entry does not matter.
Andrew Goodbody comment on the resolution is more precise than what I wanted to say, so I will not comment further on this topic. As for Prof. Dersch tool, there is two reason for me not to use it. First of all, it is a replacement for the panotools which were created by him a while back. Both of them seem to be rather slow on the matter of development (latest release of PTSticherNG is from March 2010, and latest release of libpano is from May 2011) while Hugin is much more used and developped. The second reason is that the project file format are a bit different, and those tools from the Hugin suite are better (for example cpfind), hence the need to go from one file format to another. This is not a good idea. Getting the plugin to work with Hugin tools is hard enough (and it is still an ongoing process) not to complicated things with the support of different tools with which the results will not likely get better over time. As I said before, if you have very specific needs when building your panorama and you know exactly what you want, you should use Hugin (or PTSticherNG if you are satisfied with its results or any other panorama tool): setting parameters manually will always yield equal or better results than an automatic process.
I'm closing this bug entry because there is nothing to do to the panorama plugin. If you think otherwise feel free to reopen it.
Benjamin: Thank you for info: my impression from vision is still, that panoramas have much less resolution. On the other side, I feel uncapable to argue against your points: therefore I should be software/programming/specialist in this topic, I guess. Thanks again Axel Am 09.01.2013 11:59, schrieb Benjamin Girault: > https://bugs.kde.org/show_bug.cgi?id=309339 > > Benjamin Girault <benjamin.girault@gmail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|UNCONFIRMED |RESOLVED > Version Fixed In| |3.0.0 > Resolution|--- |INVALID > > --- Comment #5 from Benjamin Girault <benjamin.girault@gmail.com> --- > I'm closing this bug entry because there is nothing to do to the panorama > plugin. If you think otherwise feel free to reopen it. >
(In reply to comment #6) > Thank you for info: my impression from vision is still, that panoramas > have much less resolution. Try with Hugin a different projection, you may be able to get a smoother resolution. However this will be at the cost of distortions. In fact, there is no "best" projection to transform a sphere (the one centered in the point of view on which the photos lay) into a plane. Some will try to keep straight line straight (with the drawback of reducing the resolution), some will try to keep as much information of the photos (with the drawback of distorting the picture). This is a question of compromise (and how the result will be used, i.e. static photo or 3D viewer?)