[darktable-dev] Crop tool is awkward for my use case
I find the crop tool to be unwieldly for my common use case, namely processing a large number of photographs from shooting sports. I shoot a lot of basketball and (American) football games for my alma mater. My workflow is to import the typically ~2000 photos into KPhotoAlbum, review them and select the ones I want (typically 300 or so), and create a directory with symlinks to the selected files. These are essentially all JPEG; RAW would simply consume too much space and slow the camera (Canon 7DmkII) too much. The postprocessing I do is limited to cropping and rotating, if my camera was not level (typically it isn't perfectly level, as I'm shooting handheld bursts). I gave up on noise reduction last year; the 7DmkII is good enough even at ISO 6400, and additional NR really slows things down. The difficulty is that to crop the frame (always freehand) requires the following motions: 1) Position the mouse near one corner of the image (say, top left), which may be nowhere near where I want to crop. 2) Click and move the top and left edges (via the top left corner) to the desired spot. 3) Move the mouse to the bottom right of the image, which again might not be near where I want to crop. 4) Click and move the bottom and right edges to the desired spot. With RawTherapee I simply place the mouse at the desired top left spot, click and drag it to the bottom right, and I'm done. The extra motions with Darktable, especially since they have to start far from what may be my point of interest, are awkward and cost maybe 5 seconds per image. With 300 images, that's an extra 25 minutes; this past Wednesday I shot two games that totaled 700 images, so the extra time would have been an hour. I'd prefer to use Darktable for this purpose, since it's otherwise a lot faster. RawTherapee takes maybe 3 seconds or so to export an image; Darktable is more like 1 second, not to mention that the rotate function is easier in Darktable (right mouse drag). But the current behavior of the cropping tool is simply too awkward (I tried it for one set and it really did take a lot more time). I tried looking at the code (in src/iop/clipping.c), but it wasn't obvious to me what would need to change to do this. I understand that dragging inside the frame is used to move the crop box, but that's rarely something I need to do. I have at least two more games this season to shoot, and if we make it to the later rounds of the tournament, I'm going to have a lot more photos (less selective about what I keep). Perhaps what I really need is a very minimalist program that lets me set the crop and rotate and do nothing else, but I haven't found such (on Linux). Thoughts, anyone? -- Robert Krawitz *** MIT Engineers A Proud Tradition http://mitathletics.com *** Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: Fwd: [darktable-dev] Crop tool is awkward for my use case
On Mon, 18 Feb 2019 16:48:55 +1100, Bruce Williams wrote: > Why not leave the current situation as it is, but add a CTRL key modifier > to allow the alternate behaviour? That would work. I'd prefer an option to flip the behavior, but I think I could live with this. > -- Forwarded message - > From: Jason Polak > Date: Mon, Feb 18, 2019 at 4:42 PM > Subject: Re: [darktable-dev] Crop tool is awkward for my use case > To: > > > For some people that might be true, but the current system also has an > advantage: if the shot is already pretty good but just needs a slight > cropping, then only a little dragging in one corner may be required, > without much dragging. Then the click-in-square method for moving the > crop is actually useful. I would not want to have to drag a rectangle > for every little crop adjustment. > > On 17/2/19 10:54 pm, August Schwerdfeger wrote: >> How is this a JPEG vs. RAW issue? I have done a great deal of cropping >> in Darktable (on both JPEGs and RAWs) and I think that adding the >> proposed single-drag interaction would speed up cropping a great deal >> over the current process, no matter the format of the image being edited. >> >> -- >> August Schwerdfeger >> aug...@schwerdfeger.name >> >> >> On 2/17/19 8:01 PM, David Vincent-Jones wrote: >>> >>> Although darktable handles JPG images very well, I think that its >>> primary market was targeted towards users who shoot RAW with an >>> expectation of doing more complex processing on individual frames. >>> Maybe darktable is simply the wrong software for your high production >>> needs. >>> >>> On 2019-02-17 4:08 p.m., Robert Krawitz wrote: >>>> I find the crop tool to be unwieldly for my common use case, namely >>>> processing a large number of photographs from shooting sports. >>>> >>>> I shoot a lot of basketball and (American) football games for my alma >>>> mater. My workflow is to import the typically ~2000 photos into >>>> KPhotoAlbum, review them and select the ones I want (typically 300 or >>>> so), and create a directory with symlinks to the selected files. >>>> These are essentially all JPEG; RAW would simply consume too much >>>> space and slow the camera (Canon 7DmkII) too much. >>>> >>>> The postprocessing I do is limited to cropping and rotating, if my >>>> camera was not level (typically it isn't perfectly level, as I'm >>>> shooting handheld bursts). I gave up on noise reduction last year; >>>> the 7DmkII is good enough even at ISO 6400, and additional NR really >>>> slows things down. >>>> >>>> The difficulty is that to crop the frame (always freehand) requires >>>> the following motions: >>>> >>>> 1) Position the mouse near one corner of the image (say, top left), >>>>which may be nowhere near where I want to crop. >>>> >>>> 2) Click and move the top and left edges (via the top left corner) to >>>>the desired spot. >>>> >>>> 3) Move the mouse to the bottom right of the image, which again might >>>>not be near where I want to crop. >>>> >>>> 4) Click and move the bottom and right edges to the desired spot. >>>> >>>> With RawTherapee I simply place the mouse at the desired top left >>>> spot, click and drag it to the bottom right, and I'm done. The extra >>>> motions with Darktable, especially since they have to start far from >>>> what may be my point of interest, are awkward and cost maybe 5 seconds >>>> per image. With 300 images, that's an extra 25 minutes; this past >>>> Wednesday I shot two games that totaled 700 images, so the extra time >>>> would have been an hour. >>>> >>>> I'd prefer to use Darktable for this purpose, since it's otherwise a >>>> lot faster. RawTherapee takes maybe 3 seconds or so to export an >>>> image; Darktable is more like 1 second, not to mention that the rotate >>>> function is easier in Darktable (right mouse drag). But the current >>>> behavior of the cropping tool is simply too awkward (I tried it for >>>> one set and it really did take a lot more time). >>>> >>>> I tried looking at the code (in src/iop/clipping.c), but it wasn't >>>> obvious to me what would need to change to do this. I understand that >>>> dragging inside the frame is used to move
Re: [darktable-dev] Crop tool is awkward for my use case
On Mon, 18 Feb 2019 17:24:05 +0100, sturmflut wrote: > Hi, > > the comment holds some validity in this particular case since darktable > can't losslessly crop a JPEG file, but other tools can. If the original > poster ended up just cropping (and not rotating) most files, something > like cropgui[1] would actually yield better image quality. Well, that's interesting to know. Unfortunately, cropgui isn't quite right either; it doesn't do rotation. I'm looking at a command line solution whereby I use RawTherapee to do the crop and rotate, but don't actually export it, and just extract the rotation and crop data from the sidecar and apply it. Once I get the rotation math correct, at any rate. > (Obviously this is an extreme edge case and I fully support the solution > with the modifier key proposed in the other thread. I just added this > for future reference.) > > cheers, > Simon > > > > [1] https://github.com/jepler/cropgui > > > Am 18.02.19 um 14:49 schrieb Moritz Mœller: >> On February 17, 2019 23:01:58 David Vincent-Jones >> wrote: >>> >>> Although darktable handles JPG images very well, I think that its >>> primary market was targeted towards users who shoot RAW [...] >>> >> That's a typical developer answer. Amusing and sad at the same time. >> >> The user brings up an UX issue that is very real. For the record: I >> think the crop tool in DT could be improved a lot too. >> >> In return they get lectured about the input data the developer presumes >> DT should be fed with, a topic completely and utterly unrelated to the >> issue raised. >> >> Pardon my use of weasel words. >> >> Cheers, >> >> .mm -- Robert Krawitz *** MIT Engineers A Proud Tradition http://mitathletics.com *** Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Crop tool is awkward for my use case
On Mon, 18 Feb 2019 17:23:40 +0100, thokster wrote: > Did you try the crop tool in perspective correction. > There you can try also the automatic rotation function by Ctrl-clicking. Perspective correction is irrelevant to me in this case, as is automatic rotation. It's the UI mechanics of cropping that are a problem for me. > Am 18.02.19 um 01:08 schrieb Robert Krawitz: >> I find the crop tool to be unwieldly for my common use case, namely >> processing a large number of photographs from shooting sports. >> >> I shoot a lot of basketball and (American) football games for my alma >> mater. My workflow is to import the typically ~2000 photos into >> KPhotoAlbum, review them and select the ones I want (typically 300 or >> so), and create a directory with symlinks to the selected files. >> These are essentially all JPEG; RAW would simply consume too much >> space and slow the camera (Canon 7DmkII) too much. >> >> The postprocessing I do is limited to cropping and rotating, if my >> camera was not level (typically it isn't perfectly level, as I'm >> shooting handheld bursts). I gave up on noise reduction last year; >> the 7DmkII is good enough even at ISO 6400, and additional NR really >> slows things down. >> >> The difficulty is that to crop the frame (always freehand) requires >> the following motions: >> >> 1) Position the mouse near one corner of the image (say, top left), >> which may be nowhere near where I want to crop. >> >> 2) Click and move the top and left edges (via the top left corner) to >> the desired spot. >> >> 3) Move the mouse to the bottom right of the image, which again might >> not be near where I want to crop. >> >> 4) Click and move the bottom and right edges to the desired spot. >> >> With RawTherapee I simply place the mouse at the desired top left >> spot, click and drag it to the bottom right, and I'm done. The extra >> motions with Darktable, especially since they have to start far from >> what may be my point of interest, are awkward and cost maybe 5 seconds >> per image. With 300 images, that's an extra 25 minutes; this past >> Wednesday I shot two games that totaled 700 images, so the extra time >> would have been an hour. >> >> I'd prefer to use Darktable for this purpose, since it's otherwise a >> lot faster. RawTherapee takes maybe 3 seconds or so to export an >> image; Darktable is more like 1 second, not to mention that the rotate >> function is easier in Darktable (right mouse drag). But the current >> behavior of the cropping tool is simply too awkward (I tried it for >> one set and it really did take a lot more time). >> >> I tried looking at the code (in src/iop/clipping.c), but it wasn't >> obvious to me what would need to change to do this. I understand that >> dragging inside the frame is used to move the crop box, but that's >> rarely something I need to do. I have at least two more games this >> season to shoot, and if we make it to the later rounds of the >> tournament, I'm going to have a lot more photos (less selective about >> what I keep). >> >> Perhaps what I really need is a very minimalist program that lets me >> set the crop and rotate and do nothing else, but I haven't found such >> (on Linux). >> >> Thoughts, anyone? -- Robert Krawitz *** MIT Engineers A Proud Tradition http://mitathletics.com *** Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Crop tool is awkward for my use case
On Mon, 18 Feb 2019 10:34:11 -0800, David Vincent-Jones wrote: > I am not a developer but do feel that using tools appropriate for > the work is often more productive than trying to adapt and > complicate. Understood, but I haven't found useful tools other than Darktable and RawTherapee. CropGUI actually has the same problem, in addition to some others (no rotation, slow, and portrait format images go off the screen even on my 4K display). Another thing I prefer about both Darktable and RawTherapee is that they create sidecar files, so I can keep a record of exactly what I did. > On 2019-02-18 5:49 a.m., Moritz Mœller wrote: >> That's a typical developer answer. Amusing and sad at the same time. -- Robert Krawitz *** MIT Engineers A Proud Tradition http://mitathletics.com *** Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Crop tool is awkward for my use case
On Mon, 18 Feb 2019 21:50:08 +0100, Sturm Flut wrote: > Dear Robert, > > Am 18.02.19 um 17:54 schrieb Robert Krawitz: > >>> the comment holds some validity in this particular case since darktable >>> can't losslessly crop a JPEG file, but other tools can. If the original >>> poster ended up just cropping (and not rotating) most files, something >>> like cropgui[1] would actually yield better image quality. >> >> Well, that's interesting to know. Unfortunately, cropgui isn't quite >> right either; it doesn't do rotation. > > Yeah, lossless rotation is only possible in 90 degree steps with > JPEGs. jpegtran (the tool working in the background of cropgui) > exploits a special property of the JPEG compression scheme. This > property makes it possible to discard parts of the image data > without having to re-encode the rest. There are certain limitations > to this trick (you can't cut at every pixel coordinate, but only at > the bounds of slightly larger blocks). > > But if all you have is a JPEG, you only want to cut it, and image > quality is a concern, then jpegtran/cropgui would be a better option > than most generic image editing tools. Absolute image quality isn't my concern; I'm shooting basketball mostly at ISO 6400 (I do export them at a high quality setting). And I do rotate some photos if the camera's rolled badly, which is not uncommon. And cropgui has exactly the same UI problem as Darktable -- you have to crop from the edges rather than just drawing the bounding box in one motion. It's also slow, since it exports the photos on the fly, and doesn't leave a sidecar for me to record what crop I did. If I can reverse engineer RawTherapee's settings, I'll probably do the actual conversions via a shell/perl script using convert to do the fun stuff if it's fast enough. -- Robert Krawitz *** MIT Engineers A Proud Tradition http://mitathletics.com *** Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Crop tool is awkward for my use case
On Mon, 18 Feb 2019 22:37:06 +0100, thokster wrote: > Am 18.02.19 um 20:52 schrieb Robert Krawitz: >> On Mon, 18 Feb 2019 17:23:40 +0100, thokster wrote: >>> Did you try the crop tool in perspective correction. >>> There you can try also the automatic rotation function by Ctrl-clicking. >> Perspective correction is irrelevant to me in this case, as is >> automatic rotation. It's the UI mechanics of cropping that are a >> problem for me. > > Ok, but did you try the built in crop tool? The only crop tool I saw in perspective correction was autocrop, which is not what I want. > Maybe it's faster for your workflow. > > You can add a preset for e.g. your original aspect ratio and > configure a keyboard shortcut. The original aspect ratio is irrelevant. I crop each shot freehand to get the composition I want; there is no common pattern. See https://rlk.smugmug.com/Sports/Basketball/MIT-Clark-Mens-Basketball-Feb-13-2019 for an example of what I do. > Then you just have to press your shortcut an you can crop with one click. -- Robert Krawitz *** MIT Engineers A Proud Tradition http://mitathletics.com *** Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Crop tool is awkward for my use case
On Mon, 18 Feb 2019 23:32:07 +0100, thokster wrote: > Am 18.02.19 um 22:48 schrieb Robert Krawitz: >> On Mon, 18 Feb 2019 22:37:06 +0100, thokster wrote: >>> Maybe it's faster for your workflow. >>> >>> You can add a preset for e.g. your original aspect ratio and >>> configure a keyboard shortcut. >> The original aspect ratio is irrelevant. I crop each shot freehand to >> get the composition I want; there is no common pattern. See >> https://rlk.smugmug.com/Sports/Basketball/MIT-Clark-Mens-Basketball-Feb-13-2019 >> for an example of what I do. > Nice shots and really a lot of work. Thanks -- and you see why I harp on this; I need to squeeze everything I can out of the workflow. Over the past few years, I've put a lot of work into performance tuning KPhotoAlbum to squeeze time out of image loading and that, and anything that adds a few seconds per image is a real problem for me. -- Robert Krawitz *** MIT Engineers A Proud Tradition http://mitathletics.com *** Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Crop tool is awkward for my use case
On Mon, 18 Feb 2019 22:26:12 -0500, =?UTF-8?B?xaBhcsWrbmFz?= wrote: > On 2/18/19 8:19 PM, Robert Krawitz wrote: >> Thanks -- and you see why I harp on this; I need to squeeze everything >> I can out of the workflow. Over the past few years, I've put a lot of >> work into performance tuning KPhotoAlbum to squeeze time out of image >> loading and that, and anything that adds a few seconds per image is a >> real problem for me. > > Hmm... what's all the rush? :) So it looks like what I'm doing is using a script to parse the RawTherapee sidecar files and then use ImageMagick (convert) to process them. It's very fast (it did 400 files in about 80 seconds on my Xeon E3-1505Mv5) since it uses the full concurrency of my CPU. The script was a pain to get right; all of the different bounding boxes made for a lot of confusion, and ImageMagick's coordinate system is a bit quirky. I also have a watermark step that adds 66 seconds to the same set of photos; no doubt if/when I combine all of that into one it will be even faster (and need only one command). But there's still one thing I do like about Darktable's crop tool, namely that it's shared with the rotate tool so I don't need to type an extra keystroke to bring up the rotate tool. It sure would be nice to have all of that in one package, though :-) There are definitely times I put a lot more effort into individual images; it's just this isn't one of them. But even for shooting, say, fireworks (which does take a good bit of processing), the crop tool in Darktable is awkward. -- Robert Krawitz *** MIT Engineers A Proud Tradition http://mitathletics.com *** Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Automatically select the most focused photo in a burst of photos
On Sun, 6 Oct 2019 15:02:39 +0200, =?UTF-8?Q?Aur=c3=a9lien_Pierre?= wrote: > That can be easily done by computing the L2 norm of the laplacian of the > pictures, or the L2 norm of the first level of wavelets decomposition > (which is used in the focus preview), and taking the maximum. > > As usual, it will be more work to wire the UI to the functionality than > writing the core image processing. Consider the case where the AF locks onto the background. This will likely result in a very large fraction of the image being in focus, but this will be exactly the wrong photo to select. Perhaps center-weighting, luminosity-weighting (if an assumption is made that the desired subject is usually brighter than the background, but not extremely light), skin tone recognition (with all of the attendant problems of what constitutes "skin tone"), and face recognition would have to feed into it. > Le 06/10/2019 à 14:14, Germano Massullo a écrit : >> Il giorno dom 6 ott 2019 alle ore 13:32 Moritz Mœller >> ha scritto: >>> Define 'most focused'. >>> I give you an example to understand this request better. [...] >> >> Yes you are right. but in your case, the couple is the main thing that >> is moving in the picture. For my use case imagine I am taking photos >> to people that are giving a talk. Some photos of the burst may be >> blurred because I moved the camera while shooting, instead some other >> shoots of the same burst could have less blur effect beause my hands >> were not moving during its exposure time so the photo will have less >> blur effect. >> It would be great if an algoritm could detect the best shots -- Robert Krawitz *** MIT Engineers A Proud Tradition http://mitathletics.com *** Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Automatically select the most focused photo in a burst of photos
On Sun, 6 Oct 2019 16:40:37 +0200, =?UTF-8?Q?Aur=c3=a9lien_Pierre?= wrote: > argh. Tales of over-engineering… I don't really disagree with you, just want to point out that getting it anywhere near correct (i. e. without a huge number of false positives and false negatives) is a difficult problem. > Just overlay the euclidean norm of the 2D laplacian on top of the > pictures (some cameras call that focus-peaking), and let the > photographer eyeball them. That will do for subjects at large aperture, > when the subject is supposed to pop out of the background. For small > apertures, the L2 norm will do a fair job. And it's a Saturday afternoon > job, hence a very realistic project given our current resources. That's fair, I just think that this kind of algorithm will likely select a lot of photos that are badly out of focus (because the focus locked on a much more expansive background) and miss ones where it's the relatively small subject that's in focus. > What you ask for is AI, it's a big project for a specialist, and it's > almost sure we will never make it work reliably. The drawback of AIs, > even when they work, is they fail inconsistently and need to be > double-checked anyway. > > So, better give users meaningful scopes and let them take their > responsibility, rather than rely on witchcraft that works only in > Nvidia's papers on carefully curated samples. Or maybe just implement focus peaking, as you say, but with a UI similar to the camera's UI (flashing regions that are in best focus). Then it's up to the user to select the best photos based on their knowledge of the desired subject. > Le 06/10/2019 à 16:18, Robert Krawitz a écrit : >> On Sun, 6 Oct 2019 15:02:39 +0200, =?UTF-8?Q?Aur=c3=a9lien_Pierre?= wrote: >>> That can be easily done by computing the L2 norm of the laplacian of the >>> pictures, or the L2 norm of the first level of wavelets decomposition >>> (which is used in the focus preview), and taking the maximum. >>> >>> As usual, it will be more work to wire the UI to the functionality than >>> writing the core image processing. >> Consider the case where the AF locks onto the background. This will >> likely result in a very large fraction of the image being in focus, >> but this will be exactly the wrong photo to select. >> >> Perhaps center-weighting, luminosity-weighting (if an assumption is >> made that the desired subject is usually brighter than the background, >> but not extremely light), skin tone recognition (with all of the >> attendant problems of what constitutes "skin tone"), and face >> recognition would have to feed into it. -- Robert Krawitz *** MIT Engineers A Proud Tradition http://mitathletics.com *** Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
