This begs the obvious question, of course. And there-in lies an issue for me: I have found LaserSoft to be a distinctly difficult organisation to deal with over the past 15 years or more - that is in addition to my visceral reaction to their Corporate policy of requiring a separate licence for every different hardware base - even within a single manufacturer (which is why I don’t have a licence for my Coolscan V ED while at the same time having one for an LS 40 which I no longer own and which cannot be used on the V ED).
I suspect you are telling me to get over it and spend the money if I want better quality scans - yes ?
A further question/comment if I may: I have a concern about the attachment of the Easy35 to the few fine threads on the front of the Laowa 65 mm (which would be my chosen lens for my X-T30). It seems to me that the only way to avoid the Easy35 breaking those threads would be to have the combination of Easy35, lens and camera body in a vertical alignment - with the camera at the top obviously - requiring a reasonably strong ball head on a tripod What has been your experience?
I stand the camera on the Easy35, pointing down. This feels very stable and solid, no tripod required. Alternatively, you can lay the whole contraption on its side. I like to use my phone as a Bluetooth trigger.
The Easy35 is reasonably lightweight, and the thread is deep enough to have a solid connection. It’s some sort of lightweight metal construction. So long as you handle the Easy35 like you would a long lens (hold it by body and lens), it feels sturdy.
No, certainly not. What I strongly recommend is to download the demo version and try it yourself and then decide on a solid basis.
You could easily demonstrate, what VueScan is doing with scratch removal in Kodachrome slides by comparing numerically a scan without scratch removal and one with it activated. You should use a raw scan for this and create these 2 versions from the very same scan ,so you do not have alignment problems. If you subtract these two images from one another you expect to be left with zeros almost everywhere but the defects. See what you get …
Because defect removal is not the only issue, you should also compare the color management between VueScan and the SilverFast demo version. SF comes with a standard ICC-profile for Kodachrome (at least in the two more expensive versions, see the version comparison on the LSI website for details).
A most useful suggestion - thank you. I’ll need to consult the GIMP or Photoshop book assuming that I have to do something more advanced than using a ‘difference’ setting on one layer …
Thank you very much. I start vacation today, so it will take some time to have a look …
This is because it uses the most sophisticated, patch based, inpainting method g’mic has to offer. For most images, a faster method may be good enough, but this is not implemented.
Does this make a difference? The additional image will be a b/w one, so the actual data should not differ unless a different colour resolution is used.
Would you mind sharing what exactly you are doing with the IR data?
From your picture above, it looks like there is still a tonal difference between the actual dust and the ghost picture, which to me looks like this could probably be solved with an accurate threshold selection plus maybe some contrast spreading. But I may be wrong …
This looks impressive from the outline already! The comparison sounds interesting, but no need for the entire document as I do not use silverfast. But maybe there are some silverfast users around …
It would maybe make sense to remember this thread next time you stumble upon a scratched one . @Jossie also provided something which I have to investigate, audio there’s no urgency …
To have a definite answer, we need somebody with the same scanner to confirm. I am on much cheaper reflecta hardware which has very limited options in comparison.
As stated before, the vuescan scratch removal is not very good, but the infrared data I got so far is reasonable and I wonder if there is already a difference in the scanner handling with these softwares (I.e., is the silverfast ir data higher tonal resolution than vuescan’s?).
If it is only post processing what differs, we can probably find a reasonable algorithm here. The g’mic inpainting is excellent, and one could even utilize some of the f/loss machine learning based inpainting methods that are available. The crucial part is the mask generation, which to me, so far, looks manageable …
In principle there is no difference, except that i VueScan you can define the exposure level also for the IR channel.
In brief, I use a median filter of the IR channel and subtract that from the IR image to remove the “ghost” image. Then I set a threshold in grey level and finally smooth the result with a Gaussian to broaden the defects. The latter is to avoid any nasty haloes after correction. Then I replace the IR channel in the SilverFast scan and use iSRD to remove the defects.
I do not completely understand what you mean. In the Kodachrome’s IR-channel it is difficult to disentangle defects from the “ghost” image. Pure thresholding does not work here. This is what, to my impression, VueScan does. Here is the difference image with IR-cleaning minus without IR-cleaning in VueScan:
You can clearly see the defects in the sky, but within the rest of the image there is no chance. The result of VueScan’s correction is a reduced contrast.
I do not think this issue depends on the type of scanner. It is a property of the emulsion and the way the software works.
I guess this is true, except as mentioned above, the option to change the exposure level (lamp brightness / exposure time) for VueScan.
Absolutely correct, but I do not see a clear recipe out there.
Hm, as said, vuscan’s inpainting, and maybe even the mask generation, are not very good. I don’t question this. As we are here in an f/loss community, and I have been working on an algorithm for scratch removal, I am of course interested to make “my” algorithm to work with kodachrome as well. If the data acquisition of vuescan is good enough, then the scanning software does not matter anymore for the subsequent processing …
Maybe I understood the question wrong. My scanner does e.g. not have an option to change the illumination brightness, therefore it is a different process than with a higher end scanner.
Let’s see if we find one. I’ll have a look at your image once I’m back from vacation. If you are using both, vuescan and silverfast, it would also be great to have the infrared data of the same slide from both softwares to compare them, in case you find the time …
As far as I can see what VueScan does, is to set a threshold in grey scale level and just uses the IR-image as a transparency mask, but which the original is divided, to compensate the reduced transmission within the defect. This is my speculation, of course, based on what I deduced from the images. I did not ask EH what his algorithm does, as I do not expect to get an answer .
Which scanner do you have? I thought all reflecta scanner have the possibility to set the illumination level at least for RGB?
No problem. I uploaded the SF-version to the same filebin as above.
To my experience, this is the first company where I really got some useful support, but this is already a couple of years ago and I don’t remember the details anymore, besides that it was a really good experience.
CrystalScan 7200. It maybe has this possibility, but I was not able yet to contruct a case where I would have seen any difference. The problem with film scanners, as with a lot of modern technology, is, that it is very hard to get detailed information on the hardware capabilities and the software limitations. But I had very bad experience with Reflecta support anyway, such that this was my last product from them.
Great, thank you very much. I’ll have a look after vacation.
Frustratingly, I find myself unable to implement this valuable suggestion – the two files that are created are wildly different in size and resolution, in spite of my setting the same parameters for each. Here is my process:
I use Vuescan to do a first scan of a Kodachrome slide with the following parameters:
Input: Task: Scan to file; Source: LS-50; Media: Slide Film; Bits per pixel = 64 bit RGBI; Scan Resolution: Custom @ 2900 dpi
Filter: all options at ‘none’ or ‘off’
Color: Color Balance = Auto Levels; Slide Vendor: Kodak; Slide brand: KODACHROME; Slide type: K14; :all other parameters at default
Output: only Raw file selected; Raw file type: 64 bit RGBI; Raw output with – Scan; Raw save film: not selected; Raw Compression: off; Raw DNG format: not selected
I then attempted to produce an identical file, but with dust and scratch removal invoked, by using the following parameters:
Input: Task: Scan to file; Source: File; Media: Image; Bits per pixel = 64 bit RGBI; Scan Resolution: Custom @ 2900 dpi
Filter: Infrared clean: Medium; all other options at ‘none’ or ‘off’
Color: Color Balance = Auto Levels; all other parameters at default
Output: only TIFF file selected; TIFF file type: 64 bit RGBI; TIFF compression: off; no other selections
These settings result in a first file which Photoshop tells me is 5291 x 3553 pixrls, resolution of 4000 dpi; about 150 MB in size – which is consistent with a 64 bit image. Where did the 4000 dpi come from?
The Photoshop reports the second file as 3850 x 2560 pixels; resolution 659 dpi; about 58 MB – which is not consistent with a 64 bit image but is with a 48 bit image. Where did the 659 dpi come from?
Clearly these files are so wildly different that they cannot be ‘subtracted’ from each other using a layer mode of ‘difference’.
First, do not use the odd step size of 2900 ppi but the native one, specified for your scanner. I would assume it is 4000 ppi?
Color balance etc. are obsolete if you save as RAW.
All the rest for the RAW scan looks good to me, not a regular VS user, however.
My only guess is, that this is the next native scan step setting.
There is some mis-understanding on what follows. You only need one scan! The scan you mentioned with output in RAW is it, then you should use this with this file as input in a second step to produce a TIF without scratch removal (input source has to be “file”). Then in a third step use the very same RAW to produce a TIF with scratch removal. Of course, these two TIFs should come out with identical dimensions and file size. Then you could compare the two TIFs e.g. with PhotoShop.
I thought that is what I said I did; it is certainly what I did do. What I didn’t do is the third step, which I can now see should produce exactly the same size file as I produce in the second step. This removes the main source of my misunderstanding/error - so thank you. I note your comment about using the default hardware resolution.
The comparison is a surprise: at least 10% of the pixels in the image are non-black - enough in fact that the total scene captured in the image can be understood. I expected only the dust and scratches pixels to be non-black - they are but they form only a tiny fraction of all the other non-black pixels. So Vuescan changed different image pixels all over the place in these two rescans of the original image. Why does it do this?
. 
.
) IR-channel of the slide for your information.