[Mark D Segal Silver Member Posts: 936]

bug?

on: February 7, 2024 at 12:05 pm

Quote Jeremy: ”

Mark, there’s no doubt that if I bake the LR edits into a new TIFF and edit that in PS, the result will be fine.

The problem, though, is that I will lose the flexibility to alter or undo those edits.”

The first line is true, the second isn’t necessarily. As you know, if you wish to preserve non-destructive editing of Photoshop images, you need to make all the edits on layers or adjustment layers and save the layers when you save the photo. If the photo had been sent from LR, those edits will reflect back into the same TIFF you re-open in LR. If you need to change anything you’ve edited in Photoshop, provided it’s on a layer, you can do so, re-save it, and those changes will be reflected back in the same TIFF accessed through LR. Think of it as the same TIFF file on your hard drive being accessed either through LR and PS. In LR, changes you make are kept in the “on-line” history track. Photoshop, as you know, doesn’t preserve history, but it preserves layers if you choose to do so, and you can edit those, and those changes get baked into the file on the hard-drive and will show-up when you re-open the same photo in LR.

Now, if after saving a Photoshop edited TIFF, you open that TIFF in LR and make more changes in LR, and you want to go back to PS with it again, you need to again select “Edit In>A copy with LR adjustments>. It will then open in PS where you can proceed to do your work, and when you resave that, it will re-open in LR as “filename, Edit,Edit”, indicating it has had two round trips. This is really the only sure way (I know) of making sure that all edits from both apps are reflected in the final rendition you want.

[Andrew Rodney Participant Posts: 392]

Re: bug?

Reply #1 on: February 7, 2024 at 1:30 pm

This (rotation) behavior is not a bug. Rotation of this TIFF is a metadata edit** applied, just like applying a keyword in the TIFF and then doing a save to the original. It isn’t considered a parametric edit like the masking, cloning, color edits, etc. If you apply a rotation via metadata and save, or if you add a new keyword and save, the original TIFF is updated (just check the file date modified); in the Mac Finder, click once and type the spacebar to see the preview: rotated. Open in Photoshop and examine the File Info (new keyword). This behavior is nothing new. And it is a ‘special’ edit and edit attribute from all other actual edits from within LR/ACR (clone, move a slider, etc, etc).

Take the rotated image from LR, open in Preview and rotate, go back to LR, the rotation is honored. Because these applications read the rotation metadata to show you the image.

**https://www.awaresystems.be/imaging/tiff/tifftags/orientation.html

The app has to support this tag. See: https://www.dpreview.com/forums/thread/4628804

I chose a few tiff pictures chose “rotate left” and then “Save metadata to file”.

The rotation is then seen by Photoshop and windows 10 “photos” viewer but not thel old “Windows photo viewer”.

Author “Color Management for Photographers" & "Photoshop CC Color Management" (pluralsight.com)”

[Jeremy Roussak Gold Member Posts: 1005]

Re: bug?

Reply #2 on: February 7, 2024 at 2:19 pm

Mark, you describe a perfectly viable approach. It creates several TIFFs, though, which I prefer to avoid; that is, after all, one of the benefits of the parametric approach adopted by LR.

I wasn’t suggesting the rotation behaviour was a bug, merely that it perhaps explains the obviously buggy behaviour I described in my first few posts. I fail to see how it can be suggested that any sequence of actions, all perfectly valid, which produce the result I set out in my first batch of screenshots can fail to be regarded as a bug.

Jeremy

[Andrew Rodney]

Re: bug?

Reply #3 on: February 7, 2024 at 4:48 pm

Since you are entirely sure this is a bug (“obviously buggy behaviour “), tell Adobe!

Photoshop/ACR: https://community.adobe.com/t5/photoshop-ecosystem-bugs/how-do-i-write-a-bug-report/idi-p/12373403

Lightroom: https://community.adobe.com/t5/lightroom-classic-bugs/how-do-i-write-a-bug-report/idi-p/12386373

Author “Color Management for Photographers" & "Photoshop CC Color Management" (pluralsight.com)”

• This reply was modified 2 months, 3 weeks ago by Andrew Rodney.

[Nicholas Carchidi]

Re: bug?

Reply #4 on: February 17, 2024 at 2:45 pm

Mark D Segal wrote:

Quote Jeremy: ”

Mark, there’s no doubt that if I bake the LR edits into a new TIFF and edit that in PS, the result will be fine.

The problem, though, is that I will lose the flexibility to alter or undo those edits.”

The first line is true, the second isn’t necessarily. As you know, if you wish to preserve non-destructive editing of Photoshop images, you need to make all the edits on layers or adjustment layers and save the layers when you save the photo. If the photo had been sent from LR, those edits will reflect back into the same TIFF you re-open in LR. If you need to change anything you’ve edited in Photoshop, provided it’s on a layer, you can do so, re-save it, and those changes will be reflected back in the same TIFF accessed through LR. Think of it as the same TIFF file on your hard drive being accessed either through LR and PS. In LR, changes you make are kept in the “on-line” history track. Photoshop, as you know, doesn’t preserve history, but it preserves layers if you choose to do so, and you can edit those, and those changes get baked into the file on the hard-drive and will show-up when you re-open the same photo in LR.

Now, if after saving a Photoshop edited TIFF, you open that TIFF in LR and make more changes in LR, and you want to go back to PS with it again, you need to again select “Edit In>A copy with LR adjustments>. It will then open in PS where you can proceed to do your work, and when you resave that, it will re-open in LR as “filename, Edit,Edit”, indicating it has had two round trips. This is really the only sure way (I know) of making sure that all edits from both apps are reflected in the final rendition you want.

Hey Mark (Segal)  – apologies in advance for the out-of-context reply. I had sent you a PM through the Luminous Landscape forums and only just realized that, according to the forums there, you haven’t been active there in over a month.

I sent you a detailed message regarding LSI’ SilverFast and their Auto IT8 calibration procedure.

If you could please check your DMs on the LL forum, that would be much appreciated, as I could not find any other means with which to contact you by.

Thank you,

Nick aka Archivist_Goals

• This reply was modified 2 months, 2 weeks ago by Nicholas Carchidi.

[Mark D Segal Silver Member Posts: 936]

Re: bug?

Reply #5 on: February 17, 2024 at 4:57 pm

Hi Nick,

Thanks for reaching out here. I do not visit LULA any longer unless someone has a reason to direct me there, as you did. So I went there and read your message.

OK, just a few observations on all this. Firstly, I do not have, nor will I ever get, Silverfast 9. I hardly ever use SilverFast anymore because I hardly use scanners any more. 99% of my scanning is with transparencies and negatives. For that I use a camera (and for the negatives – Negative Lab Pro) – better results, faster, more editing options, less hassle. I use the V850 for any reflective scanning I need to do and for that work the Epson profile for that scanner performs well enough.

It shouldn’t make much, if any, difference whether the profile is calculated at 24 or 48 bit. This only refers to the depth of the calculation – finer bits as the number goes up – but a scanner profile, like all profiles is only there to characterize the scanner and it is doing that by scanning a bunch of patches, each one of which is totally uniform, so one doesn’t need all that much bit depth to capture the patch value as well as the scanner can capture it. Likewise, the resolution at which it scans shouldn’t matter much either, within certain limits, so whether it uses anything from 240 to 480 isn’t anything that I’d worry about. I had tested the LSI advanced targets and wrote them up in an article – I forget whether on LULA or PhotoPXL, but you can find it somewhere. I found them to be better than the their regular target, insofar as they produced more accurate profiles.

A scanner profile does one thing and one thing only: it characterizes or describes/defines how the scanner reads those color patches. It has nothing to do with whether you produce raw or processed images. It’s about giving your colour management system the device performance information it needs to correctly re-interpret colour from source colour to destination colour.

You have basically four approaches to profiling this scanner:

(1) Use the Epson canned profile.

(2) Use the SilverFast canned profile

(3) Use a custom profile made with LSI’s Advanced reflective target and Auto IT8 procedure

(4) The gold-standard: Buy a Hutchcolor target and a license for basICColor Input, and use these for generating custom profiles. Note: it’s an expensive option.

Before doing (4) I recommend trying the first three in the order given, test or examine the output from each and see which works best, and if one of them is satisfactory you’re done. If none of the three are good enough, you need the gold standard.

Hope that helps.

Oh – and one more thing – as you work through my book, if you notice major disconnects between what I wrote for SF8 and what you see in SF9, I’d be curious to know. I know already they have made some advances in raw file options that didn’t exist when I wrote, so there is that, and they also improved batch scanning later on, so those would not be in my book either.

Best regards,

Mark

[Nicholas Carchidi Participant Posts: 10]

Re: bug?

Reply #6 on: February 18, 2024 at 12:59 pm

Mark,

Thanks for the insight and taking the time to respond. I should have prefaced my messaged by saying that I am only scanning reflective material, no transparencies.

Yes – if I was going to start over from scratch, I would switch to DSLR camera scanning and take on the learning curve (and expenses involved) with that method over a flatbed any day – even for reflective.

Your explanation of 24 or 48-Bit depth is the most succinct and understandable I’ve read to-date. So, thank you for that.

Yes – before I messaged, I was re-reading your review of LSI’s Advanced Targets. Those test reports you documented are on LULA, by the way. I can’t speak to the analysis you did, namely because I don’t have the (very costly) color analysis software tools such as ColorThink Pro from Chromix, et al., nor do I have the higher-level knowledge for interpreting the results. But I can say with some certainty that based on your conclusions, input from Wolf Faust, and reading posts from others on both LULA, DPReview, ScangDig and ColorForums indicated that LSI’s Advanced Targets are OK if you are willing to spend the extra money, with the idea to keep in mind that the results are very marginal at best over the regular standard (IS0 12641-1). Indeed, ScanDig/FilmScanner.info’s German page analysis concluded that,

 

“The expanded IT-8 targets according to ISO 12641 Part 2 now have 864 color fields, so much less interpolation is required. The new IT-8 targets also have additional measuring fields in the area of ​​dark colors and pastel colors. It is obvious that with more than three times as many measuring fields, a more precise measurement and therefore a more precise color calibration is possible.

In practice, however, this more precise measurement accuracy cannot be proven. We calibrated several scanners with the old Part 1 targets as well as the new Part 2 targets and then compared the resulting scans. In fact, we didn’t see any improvement in image quality. Differences or improvements can probably only be recognized through the use of highly precise measuring instruments.”

 

https://www.filmscanner.info/FragenSilverFast.html#AdvancedTargetsVorteil

 

And this also backs up Wolf Faust’s input,

“Well, ISO 12641-2 is a rather bad standard. I started working on them but than I found that many colors in the standard are impossible to produce. I am currently redisigning the standard by adding faults (but still maintain the standard tolerances). But it is hard to say when things are ready for slay. Hopefully within the next months.”

 

In your LULA review, you mentioned yourself that LSI does not explain how the internal test (Auto IT8 Calibration) is implemented, nor do they offer a technical breakdown on how it is that their Advanced Profiles all more/less conclude with a similar dE value (e.g., this thread from 2018 comments on just this https://forum.luminous-landscape.com/index.php?topic=126327.0)

This is all a non-starter though, given that you’ve pointed out the gold standard:

Yes, if resources weren’t limited and I hadn’t already invested in – and learning of – SF’s Archive Suite w/advanced targets; the several month’s of time spent getting to the bottom of just how they process RAW images, understanding LSI’s terminology in their software; and the lingering Auto IT8 procedure questions, I’d go with option #4.

Speaking of gold standard, Image Science Associates with their solutions, GoldenThread, is FADGI compliant. I believe the latest version of basICColor is, too. They’re both very costly, with GT coming in at $3,300 USD per license. Their FADGI compliant targets are not far behind that range either. Color reproduction, as I have learned, is a very niche, very expensive exercise.

I’ll give your suggestions a try and see which option works best.

After looking at reviews for both SF8 and SF9, I can state with some certainty that there is not much difference between the two releases, with some minor improvements which you already stated.

One final thought: Should I pursue getting a Hutch target, the only issue I would be concerned about is regarding that of aligning with a standard. In digital preservation and archiving, aligning with a standard is of paramount importance. Unless I am mistaken – and please correct me if I am wrong – I do not see any reference to HCT / Hutch targets being apart of any standard, whether that be ISO, ANSI, NIST, or have any certification or conformance testing done by an independent and trusted organization body. I see the comparisons listed between HCT and the IT8.7/1 & 2. But HCT seems to be ‘its own standard’.

Continuing that point, HCT appears to be a custom, “proprietary” solution which is only supported in higher-end software such as basICColor. That might be an indicator that it follows “a standard’ given that basICColor is FADGI compliant. But my point remains. Also, LSI’s Advanced Target has a total of 864 patches, while I’m to understand HCT’s has a total of 500. But that the quality of HCT is superior to that of LSI’s Advanced Targets.

Kind Regards,

Nick Carchidi

[Mark D Segal Silver Member Posts: 936]

Re: bug?

Reply #7 on: February 18, 2024 at 1:48 pm

Hi Nick,

If you want to buy a Hutchcolor target you want to make sure the profile-making software you would be using accommodates it. I know basICColor Input does. Chromix sells Input 6 for USD 625. Hutch targets are either batch or hand-measured, the former considerably less expensive than the latter. Chromix also sells Hutch reflective targets for USD 415. So this combination is well less expensive than Golden Thread materials and will make really good profiles. Based on what I read and hear (haven’t tried their stuff myself) Golden Thread is likely the 24k gold of the gold standard but mainly aimed at high-end institutional users with budgets. 🙂 People buy according to what they think they need.

You raise an interesting question about whether Hutch targets are compliant with a known standard. Don Hutcheson, the designer of these targets, is one of the most highly respected and influential experts in the colour management field. And he’s also a very approachable guy. I don’t know the answer to the question you raise, so before investing in this, if the question of a standard is as important to you as you say, I would recommend that you get in touch with him and ask.

Anyhow, my basic recommendation is still to work through the options from cheapest to most expensive and select what you think works best. What matters of course is only the quality of the end-use results you get. My experience is that clients know when your colour management is working well without knowing a thing about what went into it.

[Andrew Rodney Participant Posts: 392]

Re: bug?

Reply #8 on: February 18, 2024 at 5:24 pm

I’ve never heard (nor seen) a 24 vs. 48-bit option for a profile (table). It isn’t in i1Profiler but instead 8-bit or 16-bit, again granularity for the profile table. Nor is it mentioned differently in the ICC spec: https://www.color.org/icc32.pdf

So what exactly is being asked, specified here in terms of profile bit depth?

Author “Color Management for Photographers" & "Photoshop CC Color Management" (pluralsight.com)”

[Mark D Segal Silver Member Posts: 936]

Re: bug?

Reply #9 on: February 18, 2024 at 6:40 pm

Andrew, I no longer have Nick’s original post on hand, but if I remember correctly where he talks of 24 versus 48 it refers to how scanning bit depth is specified in SilverFast,  – 24 actually means 8-bits per channel for 3 channels (R,G,B) and 48 is 16-bits per channel for 3 channels.  SilverFast provides options to scan in “24 bit” or “48 bit” – or if working in monochrome it’s one channel, so 8 or 16; then there is also 64 bit if a 4th channel is added for the infra-red assisted dust and scratch removal function in supported scanners.

[Andrew Rodney Participant Posts: 392]

Re: bug?

Reply #10 on: February 18, 2024 at 7:55 pm

Thanks, I was a bit confused by:

It shouldn’t make much, if any, difference whether the profile is calculated at 24 or 48 bit. 

Author “Color Management for Photographers" & "Photoshop CC Color Management" (pluralsight.com)”

[Mark D Segal Silver Member Posts: 936]

Re: bug?

Reply #11 on: February 18, 2024 at 8:00 pm

Ah – OK, I probably should have worded it a little better – such as “It shouldn’t make much, if any, difference whether the profile calculation is based on a 24 or 48 bit scan of the target.”

[Author]

Posts