[manufocus]

Hi Terry,

try:

Code:

$ python3
>>> import skimage

If skimage is installed correctly, it won't return anything, otherwise you might get an error about a missing module. If the module is not found, try pip to install skimage.

[tduell]

Hi Terry,

try:

Code:

$ python3
>>> import skimage

If skimage is installed correctly, it won't return anything, otherwise you might get an error about a missing module. If the module is not found, try pip to install skimage.

Not familiar with pip, I try to stick to using the Fedora package manager.
It is installed correctly, it seems that the python path was not declared. That's now fixed, but now have a new problem...

ImportError:
Importing the multiarray numpy extension module failed. Most
likely you are trying to import a failed build of numpy.
If you're working with a numpy git repo, try `git clean -xdf` (removes all
files not under version control). Otherwise reinstall numpy.

This does seem a bit odd, as numpy is part of the Fedora distro, so if a failed build it would be causing havoc with Fedora users everywhere.
I'll have a look at trying to reinstall numpy to be sure.

Cheers,
Terry

[manufocus]

For reference, I'm using the following versions:

Pillow==5.3.0
numpy==1.15.3
scikit-image==0.14.1

[tduell]

I think I'll have to give up on this as it has caused a lot grief.
A pity as I was hoping to make some comparisons between superresolution, and pixelshift.
My thoughts about reinstalling numpy coincided with the release of Fedora 29, so that upgrade has now been done and same problems occur.
Fiddling about with the PATH environmental variable in the hope that skimage could be found has caused no end of chaos.
Thus far, after much searching for solutions I find none that work here.

Cheers,
Terry

[manufocus]

My thoughts about reinstalling numpy coincided with the release of Fedora 29, so that upgrade has now been done and same problems occur.
Fiddling about with the PATH environmental variable in the hope that skimage could be found has caused no end of chaos.

I'm sorry to hear this, however in the latest version only pyvips is needed. Give pip3 a try, you can install the packages for your user only and so far it has worked very well for me.

-----------

New Version!

The latest iteration of the superresolution script does no longer need Pillow, Skimage or Numpy. It is now solely based pypis (& libvips) and a lot faster, at least the python part. Hugin will still take its time.

An improvement from using pyvips is that tiling is no longer necessary. Memory requirements have also gone down drastically. 24MP images can now be safely handled <=4GB RAM, also images can be provided in 8bit or 16bit with the same treatment considering the upscaling algorithm.

New version is up on Github now, please read the new readme on how to install libvips & pyvips.

[manufocus]

Newest results.

[tduell]

I'm sorry to hear this, however in the latest version only pyvips is needed. Give pip3 a try, you can install the packages for your user only and so far it has worked very well for me.

I'm not having much luck...thus far no sign of pyvips being available for Fedora 29.
I'm avoiding using pip as advice suggests its use can seriously interfere with dnf (Fedora package manager), but will do a bit more research before I give up.

Cheers,
Terry

[manufocus]

Ah ok, well stay tuned, next I want to try the python packaging management that should allow to create a package that includes all libraries it depends on without the need to install anything further. So if you get hugin and libvips through fedoras package manager (or build them from git) chances are good you'll get it working as well.
So far I'm really pleased with the results myself!

[K1N8]

I'm avoiding using pip as advice suggests its use can seriously interfere with dnf (Fedora package manager), but will do a bit more research before I give up.

use `pip install --user` or execute pip inside a python virtualenv, that will not collide with any system installs and doesn't need sudo

[manufocus]

Git repo now has a new file called Superresoltuion.bin this should be standalone executable.

[jbinpg]

Latest code failed on Ubuntu 18.10. Libvips installed via pip3. Here is the traceback on a 10-image stack:

...
Average (rms) distance between Controlpoints
after 14 iteration(s): 4.6864852567635e-12 units
Strategy 2
Average (rms) distance between Controlpoints
after 15 iteration(s): 4.65799511209618e-12 units
Strategy 2
Average (rms) distance between Controlpoints
after 16 iteration(s): 4.32668147155674e-12 units
Strategy 2
Average (rms) distance between Controlpoints
after 17 iteration(s): 4.32668147155674e-12 units

Run called
^C^CTerminated
----- Averaging Images -----
Traceback (most recent call last):
File "./Superresolution.py", line 137, in <module>
main()
File "./Superresolution.py", line 17, in main
average()
File "./Superresolution.py", line 76, in average
avgs = pyvips.Image.new_from_file(tilelist[0], access='sequential')
IndexError: list index out of range

Hugin did its thing and then it hung on the align_image_stack in pyvips. I let it run for 10 hours before killing it Could it be something as simple as the images not being fed sequentially to pyvips?

Jack

[manufocus]

Hmmm curious. Under no circumstances should it take this long. If there isn't an update within a few minutes something went wrong. As hugin already worked for you before and I haven't changed anything in the hugin code this is curious indeed.


This seems to be a hugin error, after "Run called" it should within a few seconds starting with the remapping. The python error is in this case a false positive. Since hugin never generated the aligned images, python can't find them and consequently says that first item in the filelist is out of range as the list of files is empty.

Did you use the same image-stack as before?

---------- Post added 11-04-18 at 12:50 PM ----------

P.s. I tried 8 & 16bit K1-sized images without problems.

[jbinpg]

Tried again with latest code and all good on both 8 and 16 bit tiffs. Not sure what went wrong with the last attempt. Thanks for putting this out there.

Jack

[tduell]

I've had a similar problem with the process hanging after "Run called", and killed it after about 10 minutes.
The resized images were generated, but they don't look right to me. I was using the .bin file.
For the record, my tiff files were generated by dcrawps from RAW DNG files.

Cheers,
Terry

[manufocus]

That does look like vips is encountering an error. Do you get any error message or can you reproduce the same error?

Random thoughts: Enough HDD, enough RAM, files aren't removed/renamed/deleted.