OK well it is crazy what a shitshow so much software is. I can fix the vertical green emulsion lines now but it there are a lot of dumb elements in the programs that make it worse and slower and more space consuming than it should be. But I did figure out how to get one good method working and a way to maybe get away with a quicker but lesser method in some scenarios.
For whatever reason using Automate->Batch in Photoshop and using an action that opens the DNG in ACR refuses to make it apply the healing brush in ACF newly on each frame and just uses the same healing brush calculated on frame one for all frames which is no good at all obviously. But if you use Scripts->ImageProcessor… well same story but there is a way to get around it with ImageProcessor at least (and so I also found with the first way now too).
What you do is load Photoshop and then go to the directory and select all the images that have the green emulsion line in a certain position and batch load and then it loads them all into ACR as a sequence. Then you use select all and then you load in the saved ACR calibration/action file appropriate and then in this case it actually goes through and applies all of it individually to all files so it calculates out the proper healing brush for every single frame (they are all in the same spot on each frame so the healing action stored in the ACR calibration/action setting works for all frames so long as it gets reapplied and calculated for each DNG which in this case thankfully does happen). Then once it finished with that (and it can take a bit of time) you simply hit Done instead of Open (which would just try to uselessly open dozens or hundreds or thousands of images at once for now reason) and once you hit Done it writes out an .XMP for each DNG and also an .ACR for each image that has the healing brush data for each image.
Then well you still can’t use Automate->Batch in Photoshop since it… wait got an idea to maybe trick it… wait wow OK so I figured out how to make it work now at this point with Automate->Batch as well. What you do when you make the action is instead of recording an “open DNG RAW in ACR” step which ends up forcing to apply the healing brush for image 1 to ALL images, no good, you trick it by recording a step opening a NON-RAW file so it saves no extra info and raw calibration or healing data or anything but it does tell the program to open a file in the selected directory for the action to apply to. Thankfully it turns out that if the directory has DNG (or some other true or fake RAW) it still recognizes that it must use ACR to open them and then since the step above created an .XMP and .ACR file for each DNG it thankfully reads that for each image and applies the proper calibration, luminance edge masking to counter light bleed AND healing tool result used on the green emulsion line for each frame! Your action can also apply whatever other stuff you need done to the images and then directly write them out as PNGs. Now PNGs. That gets to another dopey issue, but will get to that later. So once you use the first step to write .XMP and healing brush .ACR for each image you can with this trick get it to batch and action properly for you in one step!
Before I got it doing that, and maybe there are times when you just want to use this other method for one reason or another, you could use Scripts->ImageProcessor and set your directory to where the batch of DNG are but make sure actually now to NOT ask it to open first image to set RAW settings since that ends up forcing the calculated healing brush results from frame 1 to be applied to all frames. Just leave that unchecked but since all the .XMP are already written out it has the calibration info so there is no need for you to load first image to set it, so just leave that unchecked and it is good to go.
Now it claims you can also run your other action steps with this too but it fails in various ways and I see lots of complaints of many versions of Photoshop totally bugging up actions in ImageProcessor so with many versions that seems to be broken, kind of ridiculous. Also you can only save out as jpg or psd or tiff not PNG. TIFF is soooooo much faster than PNG but there is a problem as well be discussed below. Anyway so you need to write out as TIFFs. But then you need to convert them all into PNGs to be able to use with color management in PremierePro (doesn’t matter if sticking with REC709 though in many versions although some assume sRGB, etc.).
So you have all these TIFFs as extras. Although if you are making both open matte and Academy versions you could just write out the full DNG scan data and then use those as much quicker to read than DNGs to action out each version where you crop out each ratio and rescale. Writing out full DNG size PNG is too slow even if allowed (at least with full size >4k scans).
Possibly it is faster to write out full size TIFFs and then batch out open matte cropped and UHD size rescaled and same for 1.85 academy versions rather than simply using the other method to directly read the DNGs twice and write out PNG for each version directly. Have to calculate it. Although needs a lot more intermediate storage space.
Anyway, back to about why PNGs are needed. The thing is Premiere Pro even though it has color management, full color management, they absurdly lock out the color management option tab, even the manual over ride for many image formats and ONLY for PNGs does it seem to fully work! The dumb thing FORCES TIFFs to be treated as REC709 (or sRGB in some versions) and won’t even let you manually inform it if it is in ProPhotoRGB or REC2020 or whatever! Even though the program does allow that for PNGs. All they have to do is not gray out the box for TIFFs and other stuff and it would automatically already work perfectly with no new code needed! In fact it takes wasted code for them to see what image file format is used and to then disable it for most of them. FOR NO REASON! Ridiculous.
Anyway so you have to use PNGs to get color management working. If you just use SDR and regular gamut it’s fine but as soon as you want to use wide gamut colors forced to use PNG image sequence in. Which would be fine if PNGs were not soooooo freakin’ slow to write out and read in. TIFFs and read in and out so insanely faster. So PNGs just bogs it all down so slow. It takes much longer to write out intermediate PNGs than TIFFS and bit longer to render out from PNGs than from TIFFs. I thought that maybe Resolve could read in the TIFFs properly but that seems to not want to color manage the TIFFs and assume REC709 for most formats going to ACES allows some degree of telling it what the format is but it’s hard to find something that Adobe writes out that matches the video specific formats it uses.
Anyway that is one way to get vertical green emulsion lines healed, so far at first glance at least, with very high quality. Have to verify, hopefully not jinxing it, but think it does it pretty damn seamlessly.
Now there is a faster way, load the DNG straight into After Effects and then use the simple wire removal tool with displace option (I think FADE option and the generative fill in would give much better results but that seems to take like beyond insanely long, I don’t know why making generative fill layers for thin little strips seems to take like minutes and minutes per frame?!?! obviously impossibly slow to use.). It can get a bit smeary and botchy but it seems if you don’t make a wire remover for all emulsion lines that appear for the entire reel, which in my cases is about 5, and stick to breaking it down into sections where frames only have one line to fix and just fix one it seems like maybe you can get away without it making too much of a blur mess, still not quite perfect but maybe not too noticeable. If you have a couple too close together to fix at once it gets messier looking results for some frames or if you just make a healer for all scratches and apply all at once to all frames not so great either. But most of my frames only have one bad vertical scratch at a time so maybe could be handled this way without it being too noticeable to the eye the fix? May give a short segment test render. On big screen TV might show up more. Anyway, there is at least the above method in ACR working to fix them. You then, if working with HDR and/or wide gamut need to write out an intermediate Quicktime ProRes4444 XQ in REC2100PQ mode to load into PremierePro where you can edit more and also write out release versions (AfterEfects built in renderer has poor options for release versions so can’t directly output from AE). You must create it in After Effects directly and NOT send to Media Encoder. Why? Because absurdly all interconnection across programs in Adobe forces automatic, secret, hidden downconversion to REC709 it seems so wide gamut colors are secretly clipped away! On a side note, even in PremierePro you must render out directly in PremierePro MediaEncoder built in output section if you use the option to externally send it to Media Encoder it also secretly clips away all wide gamut colors!
