Timeline for Auto Detection of Rotation Angle on Arbitrary Image with Orthogonal Features
Current License: CC BY-SA 4.0
33 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| S May 25, 2019 at 12:08 | history | bounty ended | Marcus Müller | ||
| S May 25, 2019 at 12:08 | history | notice removed | Marcus Müller | ||
| May 23, 2019 at 11:37 | history | edited | Royi | CC BY-SA 4.0 |
edited title
|
| May 22, 2019 at 13:49 | history | edited | Peter K.♦ | CC BY-SA 4.0 |
MInor edits, inlined links
|
| S May 21, 2019 at 11:39 | history | bounty started | Marcus Müller | ||
| S May 21, 2019 at 11:39 | history | notice added | Marcus Müller | Reward existing answer | |
| May 21, 2019 at 9:36 | answer | added | Olli Niemitalo | timeline score: 5 | |
| May 21, 2019 at 0:46 | vote | accept | BarsMonster | ||
| S May 20, 2019 at 8:00 | history | bounty ended | CommunityBot | ||
| S May 20, 2019 at 8:00 | history | notice removed | CommunityBot | ||
| May 13, 2019 at 8:28 | comment | added | Olli Niemitalo | That should be sum(pow(img(x+1, y)-img(x-1, y), 2) + pow(img(x, y+1)-img(x, y-1), 2)), right? | |
| May 12, 2019 at 20:59 | answer | added | Olli Niemitalo | timeline score: 14 | |
| S May 12, 2019 at 6:54 | history | bounty started | BarsMonster | ||
| S May 12, 2019 at 6:54 | history | notice added | BarsMonster | Draw attention | |
| May 11, 2019 at 15:32 | comment | added | BarsMonster | Well, hopefully we'll have a better solution in some 2 weeks. Thanks for the hint, updated. | |
| May 11, 2019 at 15:31 | history | edited | BarsMonster | CC BY-SA 4.0 |
added 9 characters in body
|
| May 11, 2019 at 15:14 | comment | added | Cedron Dawg | What's your time frame? I've got another slick trick to try, but it will take some time which I don't have right now. BTW, you should put (56M) next to the link so those of us with data caps can be more judicious. | |
| May 11, 2019 at 15:07 | comment | added | BarsMonster | @MarcusMüller I uploaded one of sample images at s.14.by/sample.tif . Image size is reduced slightly during chromatic aberration correction (green channel is not resampled). | |
| May 11, 2019 at 15:04 | history | edited | BarsMonster | CC BY-SA 4.0 |
added 200 characters in body
|
| May 11, 2019 at 8:47 | comment | added | Marcus Müller | @BarsMonster heh, you triggered my (and probably other's, considering the answers here) curiosity. If you have one of these 5440x3648 images uploaded somerwhere, sharing a link would be very helpful | |
| May 10, 2019 at 23:55 | comment | added | Cedron Dawg | It's going to take some serious computation due to your very tight tolerance. Suppose you have a horizontal line that is 500 pixels long. If you are off vertically by one pixel, that's about 0.11 degrees. You want one tenth of that. It's going to be difficult to trace the lines in your pic to that degree of precision, or find one that is that long. Therefore the solution is going to have to be a statistical average of some kind on all the lines you can find. If I get a chance, I'll take another shot at it. Very interesting problem. | |
| May 10, 2019 at 23:46 | comment | added | BarsMonster | @MarcusMüller Original 50Mb tiff image is 5440x3648, and large number of such photos could be stitched into large 0.1-1 gigapixel panoramas. This way 0.01° would definitely lead to multiple pixels of error, although at this size it hard to spot. | |
| May 10, 2019 at 23:43 | comment | added | BarsMonster | @CedronDawg Definitely no real-time requirements, I can tolerate some 10-60 seconds of computation on some 8-12 cores. | |
| May 10, 2019 at 20:42 | comment | added | Marcus Müller | by the way, even when running with a 0.04° resolution, I'm pretty sure the rotation is exactly 32°, not 32.19° – what are the resolutions of your original photography? Because at 800 px width, an uncorrected rotation of 0.01° is but 0.14 px height difference, and that would even under sinc interpolation be barely noticeable. | |
| May 10, 2019 at 19:11 | comment | added | Cedron Dawg | How important is efficiency? | |
| May 10, 2019 at 16:47 | comment | added | Marcus Müller | I'm super happy to tell you that it's totally wrong to be sad; DSP.SE is the absolute right place to ask this! (not so much stackoverflow. It's not a programming question. You know your programming. You don't know how to process this image.) Images are signals, and DSP.SE concerns itself very much with image processing! Also, a great deal of general DSP tricks (even as known for e.g. communication signals) are very applicable to your problem :) | |
| May 10, 2019 at 16:36 | answer | added | Marcus Müller | timeline score: 4 | |
| May 10, 2019 at 12:01 | history | tweeted | twitter.com/StackSignals/status/1126819426303717376 | ||
| May 10, 2019 at 11:36 | answer | added | Cedron Dawg | timeline score: 5 | |
| May 10, 2019 at 11:13 | answer | added | Rob Audenaerde | timeline score: 5 | |
| May 10, 2019 at 8:50 | comment | added | BarsMonster | It is very sad that it was transitioned from stackoverflow to dsp. I do not see a DSP-like solution here, and chances are now much reduced. 99.9% of DSP algorithms and tricks are useless for this task. It seems like custom algorithm or approach is needed here, not an FFT. | |
| May 10, 2019 at 7:22 | history | migrated | from stackoverflow.com (revisions) | ||
| May 10, 2019 at 3:51 | history | asked | BarsMonster | CC BY-SA 4.0 |