| 00:05.49 | *** join/#qi-hardware Nik05 (~Nik05@unaffiliated/nik05) |
| 00:52.26 | wpwrak | whitequark: hmm, with current master, i still get "OpenGL context creation failed" |
| 00:53.35 | wpwrak | ... in both GW and TW |
| 00:56.38 | whitequark | export GDK_DEBUG=OPENGL |
| 00:56.56 | whitequark | (and yeah, that is a completely different bug now) |
| 01:03.13 | wpwrak | https://0bin.net/paste/0ZKpMlPpspRK7RtI#yWCbfhlwInJjjBdMOl4pnjG3IoVbpDN3-+mynjntSiU |
| 01:03.41 | wpwrak | (the DISPLAY is to be able to see where it stops, without having to interact with it first) |
| 01:06.43 | whitequark | I haven't a slightest clue |
| 01:06.47 | whitequark | export GDK_DEBUG=ALL ? |
| 01:07.30 | *** join/#qi-hardware wildlander (~wildlande@unaffiliated/wildlander) |
| 01:08.23 | wpwrak | https://0bin.net/paste/UfjdPqDDCosWCuvw#AVaaY8j+X8Svk6Vst8cDLQIYT06n+TYjqk8424eddG7 |
| 01:09.59 | wpwrak | the only things that look fishy to me are those g_value_take_object: assertion 'G_IS_OBJECT (v_object)' failed |
| 01:10.38 | whitequark | hmmm, I have an idea |
| 01:11.45 | whitequark | wpwrak: lol |
| 01:11.47 | whitequark | this is a GTK bug |
| 01:11.55 | whitequark | fixed innnnn https://git.gnome.org/browse/gtkmm/commit/?id=d1ae01f3dc14dfbadb3e6288c6bdab5f4a1332b5 |
| 01:12.04 | wpwrak | all this debug output looks as if it should be useful to figuring out why my redirected TW disappears, too. and easier to use than an event handler override ;-) |
| 01:13.08 | wpwrak | now what version would that be ... guess > 3.20 :-( |
| 01:17.06 | whitequark | wpwrak: you can work around that |
| 01:17.23 | whitequark | well... |
| 01:18.00 | wpwrak | bump some refcount, i guess ? with something like #if GTKMM_VERSION_MINOR < 20 |
| 01:18.09 | wpwrak | err, < 21 or < 22 |
| 01:21.54 | whitequark | try this patch https://hastebin.com/hiqivovudu.cpp |
| 01:24.06 | whitequark | no, hm |
| 01:24.58 | wpwrak | that removes one of the two (solvespace:12851): GLib-GObject-CRITICAL **: g_value_take_object: assertion 'G_IS_OBJECT (v_object)' failed |
| 01:25.13 | wpwrak | opengl creation still fails (in both windows), though |
| 01:26.29 | whitequark | mh |
| 01:26.32 | whitequark | aggravating |
| 01:35.53 | whitequark | wpwrak: https://hastebin.com/voqacunuyo.cpp |
| 01:35.55 | whitequark | this one |
| 01:41.33 | wpwrak | makes opengl context creation work for GW, but with a quirk: the screen comes up with a white background, and only turns black when something happens |
| 01:41.40 | wpwrak | also, TW still fails |
| 01:41.48 | whitequark | yeah I didn't patch that |
| 01:42.10 | wpwrak | "happens" = e.g., hover over axis or icon |
| 01:47.07 | whitequark | wpwrak: this one? https://hastebin.com/afiqahekeb.cpp |
| 01:51.32 | wpwrak | applying on top of the previous one ... compiling ... |
| 01:52.03 | wpwrak | nope. still exactly like before. |
| 01:59.03 | whitequark | hrm |
| 02:35.48 | whitequark | wpwrak: https://hastebin.com/sumaxofogi.hs ? |
| 03:25.46 | *** join/#qi-hardware erichvk (~esh@ppp118-210-91-59.lns20.adl2.internode.on.net) |
| 03:52.56 | whitequark | wpwrak: wait what |
| 03:53.01 | whitequark | did you seriously write lilo?! |
| 04:07.25 | DocScrutinizer05 | didn't you know? |
| 04:07.33 | whitequark | nope, I only knew about pstree |
| 04:25.30 | DocScrutinizer05 | wiki Werner Almesberger ;-) |
| 04:26.05 | DocScrutinizer05 | https://en.wikipedia.org/wiki/Werner_Almesberger |
| 04:27.06 | whitequark | even initrd |
| 04:28.28 | DocScrutinizer05 | pstree |
| 04:28.43 | DocScrutinizer05 | aah you mentioned that |
| 04:34.34 | DocScrutinizer05 | msdos tools |
| 04:34.46 | DocScrutinizer05 | s/tools// |
| 04:34.47 | qi-bot | DocScrutinizer05 meant: "msdos " |
| 05:07.06 | *** join/#qi-hardware DocScrutinizer06 (~saturn@openmoko/engineers/joerg) |
| 05:27.59 | wpwrak | of those, initrd was probably the best. proper innovation, the stuff patents should be made of. |
| 05:28.26 | whitequark | lol |
| 05:30.11 | wpwrak | and it also solved a rather nasty situation that began to build up at that time: distributions needed more and more different boot floppies, to avoid driver X from irreparably (well, until reset) trashing registers hardware Y. the joy of ISA. we already had modules, but no way to control at boot time which to load. |
| 05:42.26 | wpwrak | whitequark: applied sumaxofogi on top of voqacunuyo and afiqahekeb |
| 05:43.42 | wpwrak | GW now comes up cleanly (i.e., black background). TW still fails to bring up opengl |
| 05:44.09 | wpwrak | lemme see if this goes away if i pick up the latest changes from git ... |
| 05:47.30 | wpwrak | btw, there are two build warnings (gcc 6.2.0): https://0bin.net/paste/35w4kJQqZ4S6zFHj#rKiSYlanF4IYFDLhpKBgo5F-g2Cf+9C5WWZS1w5vT1X |
| 05:48.04 | whitequark | yeah |
| 05:48.19 | wpwrak | seems that they added some python antidote ;-) |
| 05:52.05 | wpwrak | master @ 5c34b3f6ef86b94b9360023ddb5c6a35f935ade6 + sumaxofogi: GW and TW come up, background is black. however ... GW doesn't show the dashed lines until ther is some "action". also, slvs prints 2 x "glGetError() == 0x501" |
| 05:57.05 | whitequark | bleh |
| 05:57.14 | whitequark | what does MESA_DEBUG LIBGL_DEBUG bring out? |
| 05:57.30 | whitequark | wait nevermind I can reproduce that |
| 05:59.46 | whitequark | wpwrak: https://hastebin.com/nosuwoyona.php |
| 06:02.45 | wpwrak | whee ! :) |
| 06:03.42 | wpwrak | now all looks good: GW and TW come up, background color is right, update happens in time, no complaints on the console. |
| 06:04.06 | wpwrak | line drawing is still as glacially slow as before. but i guess that's unrelated. |
| 06:05.09 | whitequark | wait, really? |
| 06:05.21 | whitequark | that... makes no sense |
| 06:07.50 | wpwrak | did that ever stop computers from misbehaving ? :) |
| 06:10.49 | whitequark | wpwrak: pushed that to master |
| 06:11.14 | whitequark | wpwrak: can you do: cmake . -DOPENGL=1 and rebuild? |
| 06:11.46 | whitequark | wpwrak: nevermind, that's not actually possible to do on GTK3. |
| 06:11.51 | whitequark | stares |
| 06:12.22 | whitequark | wpwrak: are you *absolutely sure* your X server / graphics driver combo isn't totally fucked up? |
| 06:12.46 | wpwrak | built master ... works (just with the slowness) |
| 06:13.00 | whitequark | can you show me GDK_DEBUG=ALL output and drag something a bit |
| 06:14.16 | whitequark | on my machine, dragging a line in solvespace eats about 25% of a core plus 10% for xorg |
| 06:14.36 | whitequark | and it's incredibly snappy |
| 06:14.54 | wpwrak | x server is generally a bit sluggish, because if memory is always runnings low and there's a background load of junk in browser tabs, but nothing that would explain lines being so slow |
| 06:15.10 | whitequark | what does the fps counter say? |
| 06:15.20 | whitequark | again on my machine with intel graphics it takes 1ms to draw a frame |
| 06:15.41 | whitequark | even with DocScrutinizer05's 1200ppi mouse it would probably not have much difference coping with the load! |
| 06:16.38 | wpwrak | whoa ! GDK_DEBUG=ALL -> https://0bin.net/paste/tTlNPpLxPQ3UFTIf#En1+HvbdKYB1WoYK1yX6z0+A6U2TN18xVFxfXK5gAa6 |
| 06:17.10 | whitequark | amazing |
| 06:17.24 | whitequark | Gdk-Message: 0: layout_start=0.0 paint_start=18.7 frame_end=467.2 predicted=16.7 |
| 06:17.27 | whitequark | what the *hell* |
| 06:17.31 | whitequark | >paint_start=18.7 frame_end=467.2 |
| 06:18.56 | wpwrak | fps pretty consistently around 59 |
| 06:19.19 | whitequark | so it says "59 1/s" ? |
| 06:20.06 | wpwrak | yes |
| 06:20.15 | wpwrak | actually, the timing has changed |
| 06:20.35 | wpwrak | before, it was lagging. now, the line isn't updated at all until the mouse stops moving |
| 06:20.36 | whitequark | ohh |
| 06:20.45 | whitequark | *sob* |
| 06:21.12 | wpwrak | while, say, highlighting an axis, still happens, even while the line is "stalled" |
| 06:21.50 | whitequark | what about this https://hastebin.com/najelucosu.lua |
| 06:22.52 | wpwrak | trying ... |
| 06:23.36 | wpwrak | nope, still the same |
| 06:24.26 | whitequark | well, it's not actually *slow* |
| 06:24.33 | whitequark | what happens is it waits for vsync. |
| 06:24.34 | whitequark | somewhere. |
| 06:25.03 | whitequark | I have no idea why, to be honest |
| 06:25.22 | wpwrak | yeah, i think before it was genuinely slow/laggy. but now, it's some update prevention |
| 06:25.30 | whitequark | thatmight have been |
| 06:25.56 | wpwrak | what's interesting is that highlighting of axes does not move a "stalled" line. |
| 06:26.13 | whitequark | what do you mean? |
| 06:26.30 | wpwrak | time for a video :) |
| 06:29.20 | whitequark | ... hang on I think I know what miiiight be happening |
| 06:29.24 | whitequark | and it's rather disturbing |
| 06:30.33 | whitequark | can you do: ulimit -s 8192 then run solvespace until it (presumably) crashes? |
| 06:32.56 | wpwrak | wait .. having a system problem ... |
| 06:34.56 | wpwrak | soemthing is filling my disk :( |
| 06:43.30 | wpwrak | here we go: http://downloads.qi-hardware.com/people/werner/slvs/drag-noupdate.mp4 |
| 06:44.13 | whitequark | O_O |
| 06:44.31 | wpwrak | "special", isn't it ? :) |
| 06:44.42 | whitequark | also uhm |
| 06:44.45 | whitequark | look at the fps counter |
| 06:44.50 | whitequark | doesn't that say 1/2ms every time? |
| 06:45.37 | wpwrak | ah yes, that has gotten faster. could be because i killed the background activities. |
| 06:46.02 | whitequark | ok so it has nothing to do with vsync |
| 06:46.05 | whitequark | or glFlush |
| 06:46.35 | wpwrak | ulimit so far hasn't caused any trouble. been running it for a couple of minutes, moving the mouse around |
| 06:47.43 | wpwrak | what's also fun is that, when moving the mouse slowly over the horizontal/vertical position, the H/V appears and follows the mouse, while the line remains frozen |
| 06:50.20 | whitequark | that one I know of... |
| 07:02.42 | wpwrak | i'll go for a nap. no new bugs or nagging about features for a while ;) |
| 10:41.37 | *** join/#qi-hardware sandeepkr_ (~Sandeepkr@103.49.155.114) |
| 11:42.15 | *** join/#qi-hardware _whitelogger (~whitelogg@uruz.whitequark.org) |
| 11:42.15 | *** mode/#qi-hardware [+v _whitelogger] by ChanServ |
| 11:53.22 | *** join/#qi-hardware dandon (~dandon@185.16.53.207) |
| 12:48.04 | wpwrak | whitequark: joyful news: seems that the opengl fixes also solved the text window dying when opening issue. at least i couldn't reproduce it in a number of tests now. updated patch: http://downloads.qi-hardware.com/people/werner/slvs/display-textwnd.patch |
| 12:49.26 | wpwrak | one thing i noticed is that it seems that the window gets mapped before receiving its position, i.e., it / its frame very briefly appears at a different position, then the window is drawn at the final position. not sure who does what in that sequence. |
| 12:49.47 | whitequark | wpwrak: that's "normal" |
| 12:49.58 | wpwrak | perfect then ;-) |
| 12:50.00 | whitequark | it's slightly inelegant but really not worth fixing |
| 12:50.14 | whitequark | maybe once I rewrite all of the platform code to be sane |
| 12:51.17 | wpwrak | yeah, doesn't cause problems |
| 12:52.32 | whitequark | patch looks better now |
| 12:52.52 | whitequark | well, I'm not happy with how it's structured and formatted but at least the semantics makes sense |
| 12:53.12 | whitequark | will apply in a few hours |
| 12:55.09 | wpwrak | thanks ! |
| 13:31.19 | *** join/#qi-hardware sandeepkr__ (~Sandeepkr@103.49.155.114) |
| 13:32.06 | *** join/#qi-hardware sandeepkr_ (~Sandeepkr@103.49.155.114) |
| 14:27.27 | DocScrutinizer05 | ((very briefly appears at a different position)) dosn't cause problems as long as no stupid windows desktop re-arranges all icons on screen permanently, like it's done when you switch to a different display resolution |
| 14:27.41 | DocScrutinizer05 | ...on windoze |
| 14:30.34 | DocScrutinizer05 | same effect happens as well when windows reloads display driver, on NVidia updating the graca driver crap |
| 14:31.10 | DocScrutinizer05 | 0,3s black, then deskzop comes back re-arranged |
| 14:31.21 | DocScrutinizer05 | desktop* |
| 14:48.49 | *** join/#qi-hardware pcercuei (~pcercuei@92.177.36.45) |
| 14:55.19 | DocScrutinizer05 | rather boring video of "interesting snowflakes" http://maemo.cloud-7.de/share-service/DSCF2275.MOV - what's *really* highly interesting is the shake stabilizer of that Fuji camera, conider I took that video one_handed and the original shaking was X and Y just as bad as in Z-rotation, but the stabilizer totally removed it, except the latter |
| 16:20.38 | *** join/#qi-hardware pcercuei (~pcercuei@92.177.36.45) |
| 18:44.02 | strawberyargon | DocScrutinizer05, yea its good. i wonder what it would be like with even less compression :) example: http://blog.planet5d.com/2015/10/magic-lantern-shows-power-of-canon/ |
| 18:47.41 | strawberyargon | i feel "yea its good" didnt do it justice, its most acceptable to the point i dont think about shakyness. so my focus then went to the next thing, which was compression |
| 19:44.40 | DocScrutinizer05 | well, 5D mk-II (or III) yeah, I wish I could at least remote trigger this Fuji XQ1, but then it's a completely different class than Canon 5D and alas no magic lantern or _anything_ available |
| 19:46.12 | DocScrutinizer05 | a 5D would be overkill for my purposes |
| 19:48.00 | DocScrutinizer05 | but something with at least 100mm (better 150), focus distance <40cm, magnif >= 1.0 would be much appreciated |
| 19:49.34 | DocScrutinizer05 | and I actually started looking for cameras that allow hacked firmware and have a decent versatile hacked firmware |
| 19:50.55 | DocScrutinizer05 | a used 5D-Mk1 with primary 100mm macro might match all my criteria |
| 19:54.14 | DocScrutinizer05 | then OTOH a DL24-500 (with magn=4) is a nice telescope too ;-) I just wonder if the macro properties it has are any good, also if it ever might see hacked firmware |
| 19:55.17 | DocScrutinizer05 | http://www.europe-nikon.com/en_GB/product/digital-cameras/premium-compact/dl24-500-f-2-8-5-6#tech_specs |
| 19:55.47 | DocScrutinizer05 | >> Magnification Up to 4 x (angle of view equivalent to that of approx. 2000 mm lens in 35 mm [135] format)<< |
| 19:57.06 | DocScrutinizer05 | >>Focus range: Macro close-up mode: Approx. 1 cm (0.4 in.) to infinity (wide-angle position), or 70 cm (2 ft 4 in.) to infinity (telephoto position) << |
| 19:58.26 | DocScrutinizer05 | not quite sure if the latter really means I could do decent macro shots of areas 10*10mm, with lens min 30cm from object |
| 20:00.26 | DocScrutinizer05 | if "telephoto position" actually means "effective 2000mm lens" then I guess a distance of 70cm is quite good still, for effective magnification |
| 20:02.18 | DocScrutinizer05 | but too much guessing from my side in all that |
| 20:04.47 | wpwrak | canon powershot powershow sd880is aka ixus 870 is goes down to 20 mm and runs chdk. and you've already seen many pictures taken by it ;-) |
| 20:05.13 | DocScrutinizer05 | ooh, that 4 times magnification is digital, meh |
| 20:06.06 | DocScrutinizer05 | I don't want "to go down to..." - I need a certain minimum distance of 30cm from lens to object ;-) |
| 20:06.10 | wpwrak | at 20 mm, your main problem is to get light to the object, because the lens tends to shadow it pretty well, especially if you don't have a lot of ambient light. |
| 20:08.05 | wpwrak | that nikon has a nice exposure range. the sd880is only goes -3/+3 EV, which can sometimes be insufficient. |
| 20:08.11 | DocScrutinizer05 | with DL24-500 in tele mode, minimum distance is 70cm which is maybe a tiny bit clumsy since I need to stand up to reach the camera, but as long as it makes crisp pictures (actually video, via HDMI-out) of an area as 'large' as 10*10mm |
| 20:09.05 | wpwrak | naw, for getting close, you want macro mode. |
| 20:09.17 | wpwrak | tele may sound useful, but it isn't :) |
| 20:09.47 | DocScrutinizer05 | I have three requirements: format filling 10*10mm macros, video to large monitor, *minimum* 30cm distance object<->lens |
| 20:11.22 | DocScrutinizer05 | if the thing can serve "dual-use" as mice "telescope" too, I won't complain |
| 20:11.30 | DocScrutinizer05 | nice* |
| 20:12.00 | wpwrak | 30 cm or mm ? |
| 20:12.01 | DocScrutinizer05 | 2000mm effective lens sounds like the latter is granted |
| 20:12.12 | DocScrutinizer05 | CENTImeter |
| 20:12.16 | DocScrutinizer05 | 300mm |
| 20:12.36 | wpwrak | you want a 10x10 mm field from 30 cm ? |
| 20:12.40 | DocScrutinizer05 | yes |
| 20:13.02 | wpwrak | i hope you're good at grinding your own lenses ;-) |
| 20:13.15 | DocScrutinizer05 | why? |
| 20:13.29 | wpwrak | i doubt anything even remotely like this is commercially available |
| 20:13.37 | DocScrutinizer05 | err |
| 20:14.43 | DocScrutinizer05 | aiui a 150mm lens has object size == picture_on_sensor size when object has 150mm distance from sensor |
| 20:15.07 | DocScrutinizer05 | aka "magnicication = 1.0" |
| 20:15.29 | DocScrutinizer05 | if it could get focused to 15cm distance |
| 20:15.40 | wpwrak | yes, that's the problem |
| 20:16.01 | DocScrutinizer05 | macro lenses of 100mm or 150mm start at 30cm |
| 20:16.25 | DocScrutinizer05 | but I don't need a 25mm sensor |
| 20:16.29 | DocScrutinizer05 | 35* |
| 20:17.57 | DocScrutinizer05 | generally a macro lens is defined as "magnification >=1" which is just a question of lens focal length / min focus distance |
| 20:18.43 | DocScrutinizer05 | of course a 20mm lens can do magnification=1 in a focus distance of 20mm |
| 20:20.21 | DocScrutinizer05 | s/object has 150mm distance from sensor/object has 150mm distance from LENS/ |
| 20:20.45 | DocScrutinizer05 | focal length == focus distance |
| 20:21.07 | wpwrak | hmm, there do indeed semm to be lenses of the type you want: http://www.the-digital-picture.com/Reviews/Sigma-150mm-f-2.8-EX-DG-HSM-Macro-Lens-Review.aspx |
| 20:21.39 | DocScrutinizer05 | of course there are, I skimmed through them today :-) |
| 20:22.21 | wpwrak | http://www.imaging-resource.com/lenses/sigma/150mm-f2.8-ex-dg-hsm-apo-macro/review/ |
| 20:22.26 | wpwrak | ah :) |
| 20:23.20 | DocScrutinizer05 | http://cameradecision.com/lenses/compare/Tokina-AT-X-Pro-100mm-f2.8-Macro-Nikon-F-FX-vs-Carl-Zeiss-Makro-Planar-T2-100-Nikon-F-FX |
| 20:24.20 | DocScrutinizer05 | note that I'm massively guessing all that stuff, started to learn about it just 3h ago |
| 20:24.49 | wpwrak | heh, focal range = lens length :) |
| 20:25.11 | wpwrak | err, no, wrong parameter |
| 20:25.31 | wpwrak | focal distance is what you want. and that's 30-44 cm in the ones you picked |
| 20:26.43 | DocScrutinizer05 | http://wstaw.org/m/2017/01/14/plasma-desktopT17764.png |
| 20:28.20 | DocScrutinizer05 | the Tokina looks actually reasonably well spec'ed and priced for the purpose |
| 20:30.21 | DocScrutinizer05 | but then I stumbled over http://cameradecision.com/review/Nikon-DL24-500 |
| 20:30.56 | DocScrutinizer05 | then (about same time) I started considering firmware hacks |
| 20:35.26 | wpwrak | (dl24) that 10 mm focus range is probably at 24 mm. at tele, the ratio may not be so good. but i guess you'd have to try it. that's the sort of stuff you don't find in specs, and even reviewers don't do much testing of macro. |
| 20:35.51 | wpwrak | for firmware hacks, i think canon (with chdk) still rules |
| 20:35.53 | DocScrutinizer05 | >>Focus range: Macro close-up mode: Approx. 1 cm (0.4 in.) to infinity (wide-angle position), or 70 cm (2 ft 4 in.) to infinity (telephoto position) << |
| 20:36.39 | wpwrak | well, not too bad |
| 20:36.46 | DocScrutinizer05 | so yes, "wide angle position" is ,ost likely "24mm zoom" |
| 20:37.09 | DocScrutinizer05 | I'm however more interested in the other "option" |
| 20:37.57 | DocScrutinizer05 | [2017-01-14 Sat 21:00:25] <DocScrutinizer05> if "telephoto position" actually means "effective 2000mm lens" then I guess a distance of 70cm is quite good still, for effective magnification |
| 20:39.36 | DocScrutinizer05 | aiui "effective 2000mm lens" means a 35/4mm object would fill the sensor's diagonal? |
| 20:40.19 | DocScrutinizer05 | well, nope wait |
| 20:40.47 | DocScrutinizer05 | meh, that math |
| 20:42.07 | DocScrutinizer05 | let's start with 500mm lens, which means a single lens 500mm from sensor focuses parallel ("infinity") light to the sensor |
| 20:43.18 | DocScrutinizer05 | so if you can focus this lens to an object 500mm away, you get a magnification of 1.0, right? IOW an object size of the sensor will fill the picture |
| 20:44.30 | DocScrutinizer05 | now we're roughtly with my flawed math above: the cam does 4 times digital zoom, making the sensor smaller. and the focus distance isn't 500mm but 700mm |
| 20:48.03 | DocScrutinizer05 | sensor size 1" (I assume that's diagonal?), so when magnification is "area" (is it?) we have an effective 1/2" sensor with digital 4x zoom, so a 0.5" object should fill the sensor diagonal, which is just within my requirement specs |
| 20:49.20 | DocScrutinizer05 | but then lens length is usually standardized to 35mm 'sensor', not 1" |
| 20:49.44 | DocScrutinizer05 | puzzling shit, makes me dizzy |
| 20:51.39 | DocScrutinizer05 | on the bright side, it seems the DL24-500 is waiting to suffer some thorough tests in next Saturn market |
| 20:51.50 | wpwrak | well, they usually specify the equivalent |
| 20:52.08 | DocScrutinizer05 | yep, that's what I meant |
| 20:52.50 | DocScrutinizer05 | so when I use a 'fake' 500mm lens length value, I'd also need to use a 'fake' 35mm sensor, right? |
| 20:53.01 | DocScrutinizer05 | not 1" |
| 20:55.26 | DocScrutinizer05 | so an object of 35mm size would fill the sensor diagonal of DL24-500 when placed 700mm from lens surface in tele macro mode |
| 20:55.48 | DocScrutinizer05 | unless we apply digital 4x zoom |
| 20:56.27 | DocScrutinizer05 | well, actually 700/500 * 35mm |
| 20:56.52 | wpwrak | isn't it 700 from "film" (sensor) surface ? |
| 20:57.10 | DocScrutinizer05 | nope, I think that's from lens surface |
| 20:57.41 | DocScrutinizer05 | the focus distance |
| 20:59.23 | DocScrutinizer05 | http://www.europe-nikon.com/en_GB/product/digital-cameras/premium-compact/dl24-500-f-2-8-5-6#tech_specs >>[W]: Approx. 30 cm (1 ft) to infinity, [T]: Approx. 2.0 m (6 ft 7 in.) to infinity, Macro close-up mode: Approx. 1 cm (0.4 in.) to infinity (wide-angle position), or 70 cm (2 ft 4 in.) to infinity (telephoto position) (All distances measured from center of front surface of lens)<< |
| 21:02.19 | DocScrutinizer05 | so I guess it's possibly correct to assume an object of 35mm *7/5 size would fill the diagonale of the 20.8 million px DL24 sensor, when placed a 700mm in front of lens surface in tele macro mode |
| 21:06.15 | DocScrutinizer05 | zooming in digitally might still yield somewhat useful video (for work) at 10 times that, so a 3 to 4mm would fill the monitor diagonal |
| 21:07.00 | DocScrutinizer05 | et a ~600*400 resolution |
| 21:20.14 | DocScrutinizer05 | and 70cm is more than enough headroom for all tooling like soldering irons etc ;-) |
| 21:32.18 | DocScrutinizer05 | WOW, Saturn makes that DL24 a sent from Starship Enterprise: viewfinder 2359 Megapixel |
| 21:33.01 | DocScrutinizer05 | should suffice for proper holograms |
| 21:53.56 | DocScrutinizer05 | wtf? http://cameradecision.com/review/Canon-PowerShot-G1-X-Mark-II >>Pro: Electronic (Optional) Optional Viewfinder // Con: Electronic (Optional) No External Viewfinder Option << what now? |
| 22:00.29 | DocScrutinizer05 | a pity but canon seems doesn't cut it |
| 22:17.06 | *** join/#qi-hardware planasb (~planasb@78-61-86-243.static.zebra.lt) |
| 22:17.06 | *** join/#qi-hardware planasb (~planasb@unaffiliated/planasb) |
| 22:59.54 | *** join/#qi-hardware paul_boddie (~paul_bodd@host-37-191-212-251.lynet.no) |
| 23:01.15 | paul_boddie | I didn't think that any of the Nikon DL models were actually available yet. |
