flraw-devel Mailing List for flRaw
Status: Beta
Brought to you by:
jdla
You can subscribe to this list here.
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2009 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Jos De L. <Jos...@te...> - 2009-03-03 18:31:31
|
Floyd, I forwarded to my 'real' email adres (the other is mainly a spam catcher). Thanks for the feedback again and some answers between the lines. > > > <snip> > > > > > Well, that's primarily because I typo'd it! I got it > > right on the first shot, and then wrong on the next two. > > It is of course jpeglib.h. Ok. Thanks. I really started to be worried :) > > > > >I , for instance, do not have a libjpeg.h at all ! (and googling > around > > >I'm not unique in that respect). I do have however jpeglib.h and > that's > > >containing > > > > > >#ifdef __cplusplus > > >extern "C" { > > >#endif > > > > > >near the top. > > > > > >So I'm wondering what's going on ... Does one of us have a drastically > > >different jpeg library and if so, is it a version issue or is it just > > >another library ? > > > > You've been had by Ubuntu! The official jpeglib.h > > hasn't changed since 1998! And it does not contain > > those lines (granted it would be nicer if it did). But at least we are still speaking about the same libraries. That's a relief. (and do not blame specifically on ubuntu, my MinGW distribution seems to have the same 'corrected' jpeglib.h). > > > > Of course if you write software for everyone else, you > > need that in the source code because it isn't in the > > official header. > > > > I'm not sure how to deal with it being in both, but > > obviously that is what you'll have to do. Got it. That would be part of a configure probably. > > > > I've also run dlraw with gdb and tracked down the basic > > cause of the segfaults, but not the specifics. It has > > to do with lensfun. Nothing works with lensfun here, > > there is the list of cameras, but there is nothing there > > for lenses. None of the functionality works. Clicking > > on the buttons does nothing, except when it is enabled, > > and then segfaults happen. I think the problem looks worse than it is ... (but again I should handle more nice, thanks for the input again). I'm next to sure you 'forgot' to select a lense before doing anything else. It shouldn't segfault , but it can't do anything without the lensinfo. > > > > Here's the output from gdb, with a backtrace: > > > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 0xb6d5b6d0 (LWP 9084)] > > 0x0809070a in RunPipeFrom (Phase=<value optimized out>, SubPhase=1, > WithIdentify=1, FinalRun=1) > > at ../Sources/dlMain.cpp:560 > > 560 TheDcRaw->m_OutHeight); > > (gdb) bt > > #0 0x0809070a in RunPipeFrom (Phase=<value optimized out>, > SubPhase=1, WithIdentify=1, FinalRun=1) > > at ../Sources/dlMain.cpp:560 > > #1 0x08095774 in CB_MenuFileSaveOutput () at ../Sources/dlMain.cpp:2327 > > #2 0x0814717f in dlMainWindow::qt_metacall (this=0x881d1d0, > _c=QMetaObject::InvokeMetaMethod, > > _id=1, _a=0xbfe33a5c) at ../Objects/moc_dlMainWindow.cpp:440 > > #3 0xb7261fdc in QMetaObject::activate (sender=0x881f3a8, > from_signal_index=5, to_signal_index=6, > > argv=0xbfe33a5c) at kernel/qobject.cpp:3022 > > #4 0xb7262431 in QMetaObject::activate (sender=0x881f3a8, m=0xb7dfb6b8, > > from_local_signal_index=1, to_local_signal_index=2, argv=0xbfe33a5c) > at kernel/qobject.cpp:3112 > > #5 0xb765c41e in QAction::triggered (this=0x881f3a8, _t1=false) > > at .moc/release-shared/moc_qaction.cpp:216 > > #6 0xb765cde7 in QAction::activate (this=0x881f3a8, > event=QAction::Trigger) > > at kernel/qaction.cpp:1125 > > #7 0xb7a29024 in QMenuPrivate::activateAction (this=0x8972dd8, act > > > > It actually showed something like 15 stackframes back, so that's only > > about half of it. > > > > Another interesting one that I've only partially > > examined is what happens when I change the white > > balance! Sometimes it works just fine... but other > > times the image display is hosed. But I discovered that > > it's just the display, and saving it to a file produces > > a good file, and it also causes the display to be > > corrected. I have no idea what is going on, and need > > to tickle that a few times more to get a better idea of > > exactly what is happening. Many thanks ! If you find some logic in the sequence leading to such a behaviour, just let me know. > > > > Also the business I mentioned about Xinerama is probably > > not pointing in the right direction! I thought it was > > starting up with the display window well into the other > > monitor's screen, but it wasn't really. What is > > happening is it is opening up using the absolute full > > width of just one monitor (which is correct as far as > > Xinerama is concerned). But, it isn't taking into > > account that the window manager is adding a border > > around the window. Hence with a 10 pixel border, there > > are 20 pixels of it that overlap into the adjacent > > screen! > > > > I don't think there is any way to determine what a > > window manager is going to do with borders, so it is > > probably best to size it at some significant amount less > > that full screen. Perhaps 60 to 100 pixels less (maybe > > adjust that to more for large screens and fewer for > > small ones?). On the Gui Aspect still much will be changed. I'm going to a one window instead of multiple window approach. (at least as default) > > > > Anyway, I found it really distracting to have it open > > a window full width and at only about 1/3rd of the height, > > and displaying only part of the image. I would rather have > > it open with the window exactly matching the aspect ratio > > of the image, and sized so that the entire image is display > > by a window that takes up something just more than 1/2 of > > the longest edge length. Other people might not like that > > though... so it really has to be configurable. I want the > > control window in the upper left corner, using less than > > half of the screen, and the display window located to the > > right and taking up virtually all the space that is left... > > but never ever extending off screen into the space on the > > 2nd monitor. See above. I'll try and take your advice into account. > > > > Hey, one other thing! Don't change the way you have it > > setup with tabs (with text labels) to select different > > menus! Or, at least please keep that as an option! I'm > > one of those people who don't like icons. (I once tried > > to talk Udi Fuchs into text labels on ufraw, but he wouldn't > > hear of it! :-) I'm also not particular font of icons, so that makes a big chance to stay in :) > > > > Another thing that I really really liked was the menu of > > options for the algorithm used in resizing an image. Yes, that's missing in ufraw, and honestly I'm a bit surprised ufraw does nothing more than a simple bilinear interpolation. > > > > And, at least on first glance it looks like you are > > using the exact same USM that ImageMagick does, which > > would be very very useful! Not that I'd very often ever It is indeed exactly the same. (but apart from that, I like a bit more the refocus one). Could you spend also some words on the quality of raw-development ? I believe it is better in the highlights than ufraw is. (I never could find out in detail , but I believe ufraw does something weird in the highlight handling. It doesn't make distinction between pixels which are blown at the sensor level - a situation in which much info is lost - and the situation in which pixels are blown during processing (and that can be corrected better as you know the 'correct' info). Also the use of profiles derived from matrices seems to give marginally better results than the bare matrix approach in converting from Camera RGB to working space RGB. > > use USM or sharpening in a raw converter, but the > > ability to sit there and easily preview what happens > > when the parameters are changed is very nice. Hmmm... > > I may just have to take a close look and see if that is > > something I can rip out of there and put into the code > > for XV (John Bradley's wonderful image viewing program > > that is getting too crusty to use without major > > modifications). I've done lots of mods to XV for my own > > use, but due to the fact that it is not GPL's or in any > > way redistributable with a modification, it isn't > > possible to release mods as anything other than patches. > > > > > > >Thanks for all your feedback so far by the way ! > > > > Well, it's essential to have someone try it on > > several platforms. And its sort of fun! > > > > >Do you mind me following up in private mails ? > > > > Shucks, I was enjoying reading and posting to > > alt.photography! There are a number of film diehards > > there who hate the mention of anything digital relating > > to photography. Some of us enjoy poking them with a > > stick... :-) Lol :) > > > > Time for bed... > > > > Have fun, > > Floyd > > > > -- > > Floyd L. Davidson <http://www.apaflo.com/floyd_davidson> > > Ukpeagvik "Place where people hunt snowy owls" (Barrow, Alaska) > > > > ------------------------------------------------------------------------ > Aanwezig zijn op kantoor zonder er eigenlijk echt te zijn? Ja, dat wil > ik ook! <http://mobile.live.com> |
From: jdla <jd...@us...> - 2008-06-09 18:26:42
|
Just an opening message. |