Closed Beep6581 closed 9 years ago
I suppose we will need to add image width and height to the auto matching logic. Could
you please share some raw files, as I don't have access to the multi-aspect ratio raws
from a single camera/lens model.
Reported by michaelezra000
on 2012-01-31 12:21:40
This file here raws_with_different_aspect_ratio.zip<http://www.fileserve.com/file/2bewm98/raws_with_different_aspect_ratio.zip>contains
four raw images, from the same Lumix GF1 with the same lens
attached. Each raw was shot in a different aspect ratio. 1:1, 3:2, 4:3 and
16:9.
Good luck with the coding.
Thanks very much. This will be a godsend for me and hopefully others as
well.
Reported by kye.wood
on 2012-02-01 08:41:57
ok, I will take a look, thanks.
I suppose that exact matching by width and height is sufficient in this case and no
need to account for orientation.
Fabio & Emil, please let me know if you think otherwise.
Reported by michaelezra000
on 2012-02-01 14:59:51
I am basically done with ff matching changes, except not sure how to properly read the
image width and height.
Lumix GF1 has a nice pair of exif tags Sensor Width and Sensor Height, but I don't
see those in other cameras. Image dimensions are correctly reflected in the UI in Crop/W
and H, any hint on how these are populated, I can't seem to trace it.
Should ImageWidth or PixelXDimension be used?
This portion of getting the dimensions would need to be re-coded in the xmp branch.
Reported by michaelezra000
on 2012-02-03 04:47:12
Here is the patch that should be able to do additional FF matching by image size.
All is in place except the method of reading the image size itself:)
So at this point it reads width=0 and height=0 on image to be corrected and all flat
fields, therefore works as before not yet providing any new functionality (very useful,
I know:))
When this is solved the same should probably be done for the dark frame auto selection.
Reported by michaelezra000
on 2012-02-03 18:10:46
I guess someone should compile a Windows build for kye.wood to test.
As for Linux users (or just me?) it fails to compile:
[ 0%] Creating the about file
-- hg command found: /usr/bin/hg
[ 0%] Built target AboutFile
[ 5%] Built target rtexif
[ 6%] Building CXX object rtengine/CMakeFiles/rtengine.dir/dfmanager.cc.o
/home/drslony/rawtherapee/rtengine/dfmanager.cc: In member function ‘rtengine::dfInfo*
rtengine::DFManager::addFileInfo(const Glib::ustring&, bool)’:
/home/drslony/rawtherapee/rtengine/dfmanager.cc:274:29: error: cannot declare variable
‘idata’ to be of abstract type ‘rtengine::ImageData’
/home/drslony/rawtherapee/rtengine/imagedata.h:33:40: note: because the following
virtual functions are pure within ‘rtengine::ImageData’:
/home/drslony/rawtherapee/rtengine/../rtgui/../rtengine/rtengine.h:84:25: note:
virtual int rtengine::ImageMetaData::getWidth() const
/home/drslony/rawtherapee/rtengine/../rtgui/../rtengine/rtengine.h:86:25: note:
virtual int rtengine::ImageMetaData::getHeight() const
make[2]: *** [rtengine/CMakeFiles/rtengine.dir/dfmanager.cc.o] Error 1
make[1]: *** [rtengine/CMakeFiles/rtengine.dir/all] Error 2
make: *** [all] Error 2
Reported by entertheyoni
on 2012-02-10 17:24:48
PatchSubmitted
DrSlony, the patch I attached is a skeleton, it does NOT yet do what is requested as
I cannot get the image dimensions data.
Reported by michaelezra000
on 2012-02-10 17:49:19
I try to clean out bug-tracker a bit: What's the status here?
Is it 'WontFix' or is somebody willing to implement this? I'll close it 'WontFix' in
a week if nobody complains.
Reported by rinni@gmx.net
on 2013-01-28 22:21:59
Reported by rinni@gmx.net
on 2013-02-04 20:42:19
WontFix
Originally reported on Google Code with ID 1229
Reported by
kye.wood
on 2012-01-31 05:11:33