64 bit HDRi RAW file renaming
PostPosted: Tue Jan 05, 2016 7:48 am
Problem: With HDRi RAW files, HDR sets the output filename from the NAME found in the metadata (and ignores the actual filename). If there is no metadata, then HDR has no problem reusing the input filename (since there is nothing else to use, of course).
My planned process flow is
- bulk scan 20k slides in SF 8.8 on computer #1, sending the files to a network drive
- correct the filenames using computer #2. Use the operating system, Windows 7 to change the filenames to agree with the label on the front of each slide
- at this point, all the filenames agree with the slide labels, which are different than the "arbitrary" names assigned in SF 8.
- bulk process the HDRi RAW files using computer #2 with HDR so that the output files are created with the slide labels (new filenames) and NOT the ones originally created in SF 8.8
- for the rare case where I am not happy with the bulk settings, redo the image by hand in HDR
- where the slide was mis-scanned (auto frame did not work properly), go all the way back to SF8.8 and rescan, then re-HDR.
Since HDR will not use the new filenames I have provided, I could of course, manually update the names in the HDR job manager and then run a pass through HDR just to get the right filenames, but that seems like a big waste of time AND would result in having to update all the HUGE raw files, and since these are ARCHIVES, I really do not want to be editting them in any way. I could also drop the files into job manager, save the job, and have a small script I write, hunt down the XML file in SilverFast 8 HDR\Pref\Jobs and patch the correct name for each of the files, but that seems like a complicated way to go as well (and of course, would only help me and not all the other SF users).
I have spoken with Darren in the USA office and he has duplicated the "problem".
Problem Setup
- scan an image in SF 8.8 for output as 64 bit HDRi RAW with the name "sf8source" and as a TIF (resolution and size are unimportant)
- rename the file in the operating system (Windows 7) from "sf8source.tif" to "sf8target.tif"
- open HDR and drop the file "sf8target.tif" in
- the hope is that the "name" will be prefilled with "sf8target", but that is not the case, it is stuck on "sf8source"
To prove my point, you can verify this by hacking the 2 metadata NAME fields in the TIF file (one for the image and one for the infrared), to something else (however, do NOT insert of delete characters, just replace them). For our example, open "sf8target.tif" using HxD. Find both occurences of "sf8source" and replace it with "sf8target". Save the file. Now drop this file into HDR and presto, the name field now has "sf8target". Nice.
Request: Where is the option to tell HDR to use the input filename as the output filename. From a customer perspective, all that is needed is a single checkbox in preferences somewhere, that says, always use the filename and ignore the name in metadata.
I am using SilverFast 8.8, Version 8.8.0r1, Build number 16004
Reflectra MS Scanner and HDR Studio, respectively.
I have read similar posts by others, but the responses have always seemed to imply a fundamental lack of problem understanding.
I hope this post helps clarify the problem so we all benefit from the solution.
My planned process flow is
- bulk scan 20k slides in SF 8.8 on computer #1, sending the files to a network drive
- correct the filenames using computer #2. Use the operating system, Windows 7 to change the filenames to agree with the label on the front of each slide
- at this point, all the filenames agree with the slide labels, which are different than the "arbitrary" names assigned in SF 8.
- bulk process the HDRi RAW files using computer #2 with HDR so that the output files are created with the slide labels (new filenames) and NOT the ones originally created in SF 8.8
- for the rare case where I am not happy with the bulk settings, redo the image by hand in HDR
- where the slide was mis-scanned (auto frame did not work properly), go all the way back to SF8.8 and rescan, then re-HDR.
Since HDR will not use the new filenames I have provided, I could of course, manually update the names in the HDR job manager and then run a pass through HDR just to get the right filenames, but that seems like a big waste of time AND would result in having to update all the HUGE raw files, and since these are ARCHIVES, I really do not want to be editting them in any way. I could also drop the files into job manager, save the job, and have a small script I write, hunt down the XML file in SilverFast 8 HDR\Pref\Jobs and patch the correct name for each of the files, but that seems like a complicated way to go as well (and of course, would only help me and not all the other SF users).
I have spoken with Darren in the USA office and he has duplicated the "problem".
Problem Setup
- scan an image in SF 8.8 for output as 64 bit HDRi RAW with the name "sf8source" and as a TIF (resolution and size are unimportant)
- rename the file in the operating system (Windows 7) from "sf8source.tif" to "sf8target.tif"
- open HDR and drop the file "sf8target.tif" in
- the hope is that the "name" will be prefilled with "sf8target", but that is not the case, it is stuck on "sf8source"
To prove my point, you can verify this by hacking the 2 metadata NAME fields in the TIF file (one for the image and one for the infrared), to something else (however, do NOT insert of delete characters, just replace them). For our example, open "sf8target.tif" using HxD. Find both occurences of "sf8source" and replace it with "sf8target". Save the file. Now drop this file into HDR and presto, the name field now has "sf8target". Nice.
Request: Where is the option to tell HDR to use the input filename as the output filename. From a customer perspective, all that is needed is a single checkbox in preferences somewhere, that says, always use the filename and ignore the name in metadata.
I am using SilverFast 8.8, Version 8.8.0r1, Build number 16004
Reflectra MS Scanner and HDR Studio, respectively.
I have read similar posts by others, but the responses have always seemed to imply a fundamental lack of problem understanding.
I hope this post helps clarify the problem so we all benefit from the solution.