Feature request: Raw+Jpeg enhancement?

I have my image importer configured to place files as follows:
1) year-mon-day/file[x-z]
2) jpegs by default go into above folder (if they exist)
3) Raws go in a separate sub-folder under the above year-mon-day folder  ie year-mon-day/Raws
I have FRV configured to handle Raw+jpeg as a pair for culling. However, I guess the file pairs are assumed to be in the same folder (which makes sense, by default).
However, what could (?) be a very nice enhancment (for the above pref) is this:
if ( ../myfile.jpg exists)  # ie if jpeg in the parent dir of current dir with same basename 
  do-action also on ../myfile.jpg;
That way I could cull in the "Raws" dir with FRV, but still move/action the jpeg of the pair.
Would that be a rather easy/low-impact code change?  Any problems with this?  (Of course, this would be tied in with the jpeg+Raw preference check-box.)
Any thoughts as to if this is feasible?

Dear Sir:

Yes, it is assumed that RAW+JPG pair files are located in same folder. Changing this assumption is, unfortunately, not 'low impact'. To that, it is not obvious what 'action' (e.g. copy or move) should be performed with files paired from different folders (should it preserve folder structure, or not?).

Because of these factors, we will have to wait until a substantial amount of users ask for such a feature and specify how they would like this structured, because at the moment implementing this may do more harm than good.

JLGF1's picture

Ok.  What if this only applied to the Delete logic and not necessarily Move?  ie if the corresponding jpeg exists in the parent dir, delete it.  If not, do nothing (null).

There is no Delete logic in FastRawViewer, it is always Copy or Move (Move to _Rejected is based on 'Move' logic)

JLGF1's picture

In other words, I assume in the pairing logic there is somewhere (psuedo code):
if (file.Raw exists)
  rm "./file.Raw"
  rm "./file.jp*"
# I would presume adding this would be low-impact
rm "../file.jp*"  if ParentJpegFlag is True  # prefs

File handling code in FastRawViewer is much more complex (destination resolving to ask user 'overwrite-skip-create other filename',  undo lists, file checksum comparison after copy, etc,etc,etc).

Also, there are some non-trivial things, if we consider not your specific case, but generally the implementation of this function. For example: files in same folders are always at same 'mount point' (or volume), so internal FRV code does not need to check 'is this move cross-volume or not' for each file, when several files are moved, it is the same for all moved files. That is not true if source files are placed in different folders. Adding such check for each file will result in either slow down of all moves (if such check is performed for all files moved, not only for 1st one), or in additional program complexity (if one wants to cache cross-volume check results  per-folder).

Thus, the proposed change is definitely not low impact, it requires a lot of testing, corner case creation, etc, etc.


JLGF1's picture

I see; got it, thanks.

Add new comment