How do I view image with corrections from LRC

Hi all.
I’m on Windows 10 with 32gb ram i7 7700 4.2ghz
Nvidia 1070

I go into detail here to explain exactly what’s happening for me though my question in brief is how do I send an adjusted photo from Lightroom to PL6 for further editing with the adjustments from LRC showing up in pl6?
I have saved the adjusted DNG from LRC onto my hard disk and opened it in pl6 and I’ve also used the plug-in from LRC and neither method is giving me a visual on the adjustments within PL6.

Okay so…
First, I’m getting excellent results so far as I trial photolab 6. I’m green to visual art/photo/video, with only 20 months experience. Though moving from LRC into this software is pretty thrilling. It seems to me to be a completely different perspective on processing a photo…
It’s refreshing and is accessing my growth.

That said,
I am clear, say least it seems MOST people start in LRC then use the plug in extras under file to send their initial RAW to PL6 for demosaicing and denoise etc.
I’ve had success with this method and photos move back to LRC without a hitch, displaying with all the adjustments made in PL6.

The reverse, however, is yet unsuccessful.

I was working on a set of photographs to be merged in a gigapixel panorama. In this case I brought the images directly in to PL6.
I was able to get beautiful, vibrant images from my color work and processing all in PL6 with the exception of a center photo shooting directly into the setting sun.
I just could not get an image that would balance with the rest of the panorama images out of PL6, so I transferred it into LRC after denoising and applying the DXO basic preset.

I was then able to successfully get the gradient of light and color out of the image by editing it in LRC.
I have now used 2 options to send the file back to be with the rest of its family in pl6 where all of the files will be toned and exported to Microsoft image composite Editor.
I have attempted the option of going to file and plug in extras, yeah the resulting file that opens in pl6 does not have any of the adjustments made in LRC.

First, however, I simply exported the DNG file with adjustments from LRC into the source folder and then opened it in the file explorer in pl6.

When the image loads in PL6, initially the colors and light show up with the adjustments as they were made in LRC, then it goes back to the initial raw file and just shows me the desaturated shadows from the beginning of the journey.

How do I transfer the raw file from LRC with adjustments over to PL6 where I continue editing it?
Have the engineers at DXO assumed their software isn’t good enough for being a later step in someone’s workflow? They don’t have it set up so that I can transfer with adjustments from another program to Pl6?

Hopefully I am just missing something. I have a small list of things I have to check on before I commit to the software long-term. If I cannot bring a raw file with adjustments into PL6, that seems rather absurd for a professional level editing program.

I must be missing something.

Help a guy out. :v::green_heart:

I believe you can’t use DNG at this point, as PhotoLab only works with linear DNG files.

You cannot transfer a raw file to PL and expect PL to pick up the Lr edits. Those edits have to be “baked in” so you have to send a tiff over.

1 Like

The problem is that there is no “universal” way for storing adjustments to an image. Each software publisher tends to use their own storage format in a sidecar file, because they regard the RAW file itself as immutable. Adobe tends to use XMP sidecars, which record adjustments according to their tools - PL uses DOP sidecars, with their own pseudo-JSON format.

For DxO to be compatible, it would have to keep track of every other software format out there and work out what the various adjustments mean - e.g. some software has a “clarity” slider, some don’t.

As Greg says, you need to transfer images from one app to another using the TIFF format, or do what many do and use only PhotoLab.

There are a few camera manufacturers who have released their own apps that write adjustments directly to the RAW file, but this metadata cannot be read by any other app.

It could be done if the various vendors could come together and agree on some new standard elements in EXIF. Sony for example has written their own elements to the EXIF in the ARW / RAW-files adds at least since NEX 10 some 10 years ago and the number of elements have increased in the newer camera models files.

Even in NEX 7 ARW I find Sony specific element for such common data as Image Hight (Sony Image Hight), ISO (Sony ISO) and Sony Tone Curve just to name a few. I think I saw 7-8 of them already way back in NEX 7.

The DNG-files though are one of the XMP-compatible formats and reading and writing XMP/IPTC-data has worked fine to my experience but it´s a difference when it comes to editing metadata that doesn´t seem all that standardized.

Since there is a lot of people using DNG professionally even world-wide, it´s very disappointing that the various software vendors seem to neglect the interoperability problems the users face today.

I have just tested to exchange DNG between Capture One and Photolab and that just doesn´t work today. It´s even worse than I remembered it was since I last tested it.

If I take a Sony ARW/RAW for example - a file from NEX 7 or A580 and develop it in the new Capture One 23 (16.01.20) it can´t even save the changes made to the RAW to DNG without reverting to the original file content. It seems like all the editing gets lost in the DNG-exporting process. On top of that Photolab 6.1.1 refuse to open it.

The only way to establish a working flow between C1 and Photolab 6 is to start with an export to DNG from Photolab, then open it in C1 and edit it and reexporting the file to DNG. Then Photolab will open it with the changes. That way I can establish a working exchange. Why can´t the danes and the french sort this out?

I know that I can use TIFF (and I do despite I really hate it) but that is not the point here. A lot of people will not ditch DNG but both Photolab and Capture One instead, because both these converters just doesn´t work in many serious work flows today. Why isn´t this working in the year of mercy 2022?? It would have been solved 10 years ago.

It’s not just knowing which adjustments, but also the specific algorithm used for each adjustment.

Many people here will tell you the Highlights slider in PhotoLab behaves very differently to the Highlights slider in Lightroom. I would be very surprised if “Dehaze” in Lightroom and “ClearView Plus” in PhotoLab are anything alike in their results at the detailed level. We’ve even seen examples of white balance being treated quite differently.

To achieve what is being asked, it’s not so much an issue of metadata, but would require a universal set of algorithms. If such a thing existed… there would be no competitive market.

really ? you can still imagine competition on implementations of algorithm, UI,DAM features, etc, etc …

various software vendors prefer to whine about camera manufacturers and their raw formats while being mum about their own closed parametric edits :slight_smile: … and it is worse… for raw formats we still have access due to work of few people (dcraw, libraw and several of their collaborators) - but for pro·pri·e·tar·y parametric edits we are totally F$$$Ked… you can take your work as raw files to many other raw converters, you CAN NOT take your work as parametric edits anywhere else… time to stop whining about proprietary raw files ( this problem is effectively addressed ) - time to call raw converter vendors ( that also includes camera manufacturers of course in that capacity ) as the main evil hiding in plain sight !

it is not about storing (format) it is about documenting what stored data does… just like w/ a raw file you can extract a tag ( value ) - but you have no idea what it means … now w/ raw files due to work of several people this is mostly solved = but w/ raw converters it is not - data is plain readable. but as noted for example what “clarity” = “5” means nobody knows it terms how “5” is actually applied

Sure… but then what’s the point of portability? We already see complaints in this forum that two different versions of PhotoLab are rendering the same adjustments differently.

OP seems to be looking to adjust one image in two different applications, while working from the same source RAW. That’s only practical if the two applications treat the adjustments the same.

1 Like

The TIFF format does not get a lot of love from anyone, I think mainly because the enormous size of the files gives the impression of the format being blowzy & swollen. My modest 20MB .ORF raw files are exported by several of the raw processors including DXO-PL as ~200MB .TIFF files after processing. Ugh! But I suggest there’s a way to learn – if not to love – at least to feel less allergic to the TIFF by compressing them.

TIFF is, in fact, a very complex bit-map format first standardized by ALDUS (if you’re old enough to remember them) in the early 1990s to handle multiple rasterized bit-streams (see: the Wikipedia entry on ‘TIFF’). It is doggedly-low-level so is able, still today, to handle all the subtleties that image processors confect in the 16-bit output of processed RAW files. It remains – thank goodness – a reliable inter-application transfer format without which we’d all be stuck in our DXO/C1/LR/Luminar etc silos.

Still, there is no getting around the problem of the sheer verbosity of the format. Or is there? I assume you try when you can to create TIFFs using the LZW compression format? Some processors, e.g. Photoshop – but not DXO – offer this in their export dialog for TIFFs. It’s a lossless compression format that has no impact on any of the data in the file. But it still struggles to compress most 16-bit (depth) TIFFs by even 50%. Also you have to do this compression in the file-system when apps such as DXO offer no compression option.

A bit of research recently however has led me to believe I can get results that are visibly indistinguishable from lossless TIFF compression using JPEG compression; which is lossy but at modest levels (75-90% compression) not apparently harmful. I have also discovered that not all compression routines are equal. The most common in the UN*X/Mac world is the command line utility ‘tiffcp’ which is part of the widespread ‘libtiff’ libraries (‘Homebrew’ is the recommended source). Tiffcp wlll quickly compress TIFF files in the terminal using a variety of methods (see ‘tiffcp -help’). But it’s a plain-vanilla formula.

The best TIFF compression I have found is ImageMagick’s “convert -compress:JPEG” (ImageMagick is also best installed with Homebrew). Here’s some research from the British Library on the use of ImageMagick vs Tiffcp (https://services.phaidra.univie.ac.at/api/object/o:503166/diss/Content/get) that offers the results of some extensive tests (although using LZW compression rather than JPEG compression). In my own recent experience, JPEG compression reduced a 225MB tiff file created from an HDR-fusion of 5 .ORF raw files to 18MB (!! smaller than one of the original .ORF files) in about 2 seconds on my Macbook Air (M1).

The resulting compressed TIFF is still perfectly editable in DXO-PL and shows (as far as I can see) no difference in colors, no banding, no artifacts.

Yes this is inconvenient! It’s a trivial matter to run the compression once from the command line on a folder containing (among other things) a bunch of TIFFs. But it still means either exiting to the file system and running a command-line script OR using a utility like HAZEL (a Mac app but there may be Windows analogs) to ‘watch’ my image folders and run the compression script in the background.

YMMV… Best, P

1 Like

@zkarj When it comes to RAW yes it´s not just about handling parameters, but not when talking about DNG because DNG ought to reflect the changes made to it before the export. It should be like exporting a JPEG and a developed JPEG in a size and quality that the photographer has decided to embed in the DNG when it´s exported together with the “RAW-data” that it´s reflecting. The RAW-converters of today can´t manage this but some DAM-processes in corporate DAM-systems can where DNG plays a significant role in some applications. Others can actually handle interchange of DNG without losing data like Capture One 23 and they are able to open the files unlike Photolab. So before we can get anywhere at all with DNG in Photolab it just has to be possible to open the files despite they might be converted to DNG with a file-format Photolab might not support yet. Capture One has to be able to export even the changes made to a Sony ARW-raw when exported to DNG.

Taking care of and interpreting these proprietary EXIF-data several camera vendors do already both in their cameras and in their proprietary converters - in Sony´s case Imaging Edge. This isn´t anything they don´t do already. This can´t be all that problematic to solve. The computer industry has solved far more challenging problems than these before. It´s just a matter of having the will or not.

@PeterGallagher
Thank´s Peter, I always save my JPEG-files in 100% or quality 12 which I believe is almost the same despite if it´s to print or if I store it in my standard JPEG-format of 4K. If I do a good job developing a RAW and saves it like that, I can always do a few tweaks despite it´s 8 bit and is I have the RAW I always can redo the job when there is even better noise and sharpening tools than we have today.

TIFF I will only use if I feel I have to use more competent local adjustment tools than the ones in Photolab 6 (then I go to Capture One 23 instead) but I think it had been a better solution to be able to use compressed DNG. Not all converters support that either.

well one thing that PhotoLab can learn from the likes of Adobe and (P1) Capture One that there is a parameter in UI referring to “process” version if they change something so that users can have previous rendering …

PS: whoever develops code for PhotoLab managed even screw how switching between “work spaces” affects colors with the same DCP camera profiles for colors well inside sRGB gamut … guinea pig time for users

Again, coming back to the OP’s issue… this is merely one of reading ‘generic’ DNG files. Nothing to do with parameters or algorithms at all. Using TIFF gets around this particular problem and, given the adjustments will require the original RAW to have been de-mosaicked, a TIFF and a (Linear) DNG are almost identical.

I still say that anything other than data cannot be portable in a competitive market.

Of course, it can and there are many examples of industries coming together solving all sorts of standardization issues still competing hard about a lot of other things. Without some basic interoperability the IT-world stops as we know it. All the way from wall sockets to operating systems for computers to all the various sorts of contacts and interfaces. For example, Windows and Mac OS are examples of a common system to handle drivers for monitors, printers, printer and monitor profiles etc. The software all are forced to adapt to the Windows interfaces. Even the XMP-schema standard is not just about the data itself but even about schemas and all sorts of rules in them the same goes for XML that early saw initiatives to standardize datainterchange in whole branches and there were cases where they even standardized some of the data interchange processes.

WIKI writes:
" The RosettaNet standard defines both e-commerce document and exchange protocols, as part of the Electronic data interchange (EDI).

The RosettaNet standard is based on XML and defines message guidelines, interfaces for business processes, and implementation frameworks for interactions between companies. Mostly addressed is the supply chain area, but also manufacturing, product and material data and service processes are in scope.

The standard is widely spread in the global semiconductor industry, but also in electronic components, consumer electronics, telecommunication and logistics. RosettaNet originated in the USA and is widely used there, but it is also well accepted and even supported by governments in Asia. Due to the widespread use of EDIFACT in Europe, RosettaNet is used less, but it is growing.[citation needed"

The Rosetta Net-integration initiative started more than 20 years ago and is still used in the global semiconductor industry, but also in electronic components, consumer electronics, telecommunication and logistics.

In earlier days when the software manufacturers on the Windows platform followed the software user interface standard better even the menus in the menu bar were standardized to quite some degree. That did not disturb the basic competition on that market. There is still a lot of things to compete for.

Even the camera and photo software industry can if they want - but they dont´t want.

Again… the OP wants to edit the same RAW file in multiple programs. Agreeing to leave out (for the sake of this argument) the possibility that PhotoLab will open any DNG file, that means parametric data to represent the adjustments. I will buy you the first two (commercial) programs that adhere to such a standard. I am quite confident my money is safe because it makes absolutely no sense (to me) that such a thing would ever exist regardless of any industry players being willing.

To be clear here, I am talking about a significant set of adjustments to light/colour in an arbitrary image that is interpreted, parametrically, by more than one competitive program, yielding the same results in both.

I don’t deny standardisations exist all over the IT industry, but this is one that makes no more sense than insisting that every microphone must produce the same sound in the same situation. The differentiators between “darkroom” applications are their selling point. Why would anyone build a new application that processes photos in exactly the same way as an existing one?

3 Likes

Thank you for the explanation Joanna.
Proprietary is, in many cases (and ought to, by my method) killing big businesses. For the reasons people go on to state here.

I see further down the chain that Stenis CAN send a DNG to LRCfrom PL6, then send it back as DNG with the adjustments.
That is maddening.
To go way over-gradient, I’ll suggest it is not a winning theory for the operation of spaceship earth at all.
Overspecialization is the first step to extinction … IN EVERY CASE.

Do you have any suggestions on where to learn more about a PL only workflow? That is my goal here.
(Also, in a short time I have already gotten much better with the DXO software so wouldn’t likely need LRC ever again for a, “trouble image.”)

So two distinctions I am served to make are:

  1. the FURTHER distinctions and limitations of the DNG format and incompatibilities (despite it’s invention to be universal).
  2. what in particular can no longer really be edited effectively after conversion to tiff etc.

On my journey in photography, often the biggest limitation to integrous, accurate learning has been mistakes and limitations coming from the creators of the software and hardware alleged to be caring about and supporting my journey.

I see what you are saying would be true in some cases, without the interpretive format being designed effectively.

My brain extrapolates and looks for analogous applications in diverse places. In this case, I can open a lossless session file mixed in Pro-Tools in Ableton Live, get everything exactly as the engineer and producer left it from their studio PLUS all the raw data before their production, then make my own edits on and on sending them back and forth.
This proposes no market disadvantage to Ableton, Avid (PT), Fruity loops, or the innumerable other programs for audio production.
Same with the Music Instrument Digital Interface.
Was meant with USB and other such connectors, but Mac F’d that up. It’ll bite them in the end though.

Ultimately, we’re just looking for data transfer. In this case, transfer of data corresponding to the initial information captured by the camera PLUS data corresponding to the information corresponding to the adjusted image. What is lacking, which I was unaware of, is a universal language to communicate the CHANGES in the DATA corresponding to the changes in the objectively measurable light and color info. Pardon the last sentence if it’s unclear, as I’m just now processing.

What I am very grateful for is you and your contribution to the conversation!

Stenis, thanks for understanding.

Taking this way philosophical and over-gradient again, there is no culture without shared meaning.
The implications here as we discuss standardizations and proprietizations, I thought worth pointing out for further pondering.

1 Like