Seventh Heaven

Why not, let’s hope!

I’m really with you on that point - I do understand the concept of using the best tool for the job though carrying an enormous bag full does get tiring

I think it is a fantasy. To stitch a panorama you need to know where the images overlap. RAW data though is not an image, it has to be processed first. Thus for PL to stitch a panorama from RAW data it would have to be able to open all the overlapping source files, demosaic etc. them then find the overlap points and stitch during export. I dread to think how much memory and how high power a CPU you’d need to be able to do the initial in memory RAW conversion. Let alone what sort of graphic card GPU you’d need to be able to export the panorama to a TIFF / JPEG etc.

1 Like

You’ve hit the nail on the head. Panorama stitching is done with developed images. Exposure (shoot in manual) and development has to be done exactly equal.

To see if the panorama will work, one can export approximate renders. Merge them in Affinity Photo (seems to do as well as the dedicated apps I used to use). If the panorama works, then go and carefully create exact renders, merge those in Affinity Photo. Touch up the inevitable small flaws in your bitmap editor (Affinity Photo). Finished panorama.

RAW software doing the merge doesn’t really move one much further ahead. Good panoramas are time consuming. Done right panoramas can be very impressive.

29860 pixels wide of crowd. You can recognise everyone, watch the groups talk. This is shot on a D780 in landscape mode on a telephoto lens at 200mm. First processed in DxO PhotoLab 5 and then merged in Affinity Photo.

Sorry about the limitations of the forum upload software. You can only see a 1920px version. Here’s the full size image.

4 Likes

Agreed, panorama stitching requires a developed image. Nevertheless, Lightroom Classic stitches panoramas in a way that does not require me to create extra files and use extra applications.

As for “RAW data is not an image”: If this is accepted as true, then DNG, TIF and JPG data aren’t images either. No matter the format, we always need a piece of software to produce an image from whatever binary salad is contained in those files.

1 Like

A print is an image, everything before that happens is data? At least that’s my definition of “end result”, if an image no longer can be altered by digital tricks.

…how about picture vs. image, Bild und Abbild etc.?

If we need electricity to see it, it’s either night or not an image.

1 Like

Most of the edits in PL or other converters are done on the demosaiced image. Just a few are based on the raw data. But it’s the question if such specific edits are to be placed in a raw converter.

George

Yes, it makes life so much easier if we have multiple more apps, one for RAW-conversion, one for straightening, one for exposure changes, one for colour adjustments… we need much more apps with much less buttons, right? :roll_eyes:

Here’s the moment I’d wish to be a native speaker. When I learnt English, everything in 2D was a picture, be it sketches, paintings, photographs, drawings, things with lots of nails and woolen strings, mosaïcs, wood marquetry, reproductions… not even in German there’s a very clear definition, in which situation generalizing and in which using a specific word. So, being an English native speaker wouldn’t help, I can stop wishing :grin: And I would use Abbild more in terms of computers, like Speicherabbild (Memory image)

I am not sure if working on a raw image really has that much overhead, it might actually be less overhead, as the raw image has only one dimension, while the debayered image has 3 color channels. The debayered image is just an interpolation of the raw data, so basing any matching and alignment on the raw data might be more exact and efficient at the same time.

About the discussion of image (print) vs raw and picture vs image, are these not all technicalities? In the end, the image is decoded again by the cones of the human eye and encoded once more by the human brain. I guess if the resolution of the sensor was high enough, a raw image would look the same to our eyes as a debayered image (if you adjust the black point, white balance, tone curve etc). (Or you could just look at the raw image from very far away, in which case you could interprete the debayering as some form of sophisticated blurring).

100% agree as long as this includes proper DNG support not the partial support it has now. So not a new feature just a proper implimentaiton of one it sort of cliams to have now.

2 Likes

Anybody who is such a lightweight about panoramas that s/he is not prepared to prep the images for merging is not serious at all about panoramas. This is just clamouring for a feature for the sake of making noise.

Making good panoramas is work. That a perfect panorama builder is available for €50 (with a whole Photoshop equivalent app built-in, apart the high quality RAW converter which we don’t need as we have PhotoLab) makes this even more senseless noise.

The workflow is easy.

  1. Move your panorama images into a special folder. I usually shoot some duplicates along the way if I think there’s been some camera movement or not enough overlap.
  2. Open that folder in PhotoLab. Mark as Picks (green traffic light) the images you want to include in the panorama (no duplicates as that will confuse most panorama builders).
  3. Choose the most important image among those Picks (central, main subject). Do all your RAW development on that image apart from Local Adjustments.
  4. Copy those Global settings.
  5. Apply those Global settings to all the Pick images.
  6. Do whatever Local Adjustments you’d like to all the images. Be careful not to conflict or override the general look created in Global Adjustments or the frames won’t match well.
  7. Export the Picks as 100% jpg or TIFF (depending on quality requirement and space available). I’d choose sRGB but I’m very conservative about compatibility and colour management after wasting two or three years chasing Scott Kelby’s emperor’s new clothes stupidity about Adobe RGB fifteen years ago.

How having the same panorama function in PhotoLab would improve workflow is a mystery to me. There would be no less work. The images still have to prepped.

Oh, you want panoramas with live RAW development. Well that would be exciting waiting for PhotoLab to adjust up to 30 images simultaneously to be able to create a preview. Will that preview be with or without DeepPrime? Sarcasm intended.

This sounds like a worthwhile feature request in 10 years when computers have undergone another large upgrade in terms of both memory and GPU capability.

1 Like

Plus that adding edits like panorama, stitching infrared etc. needs a team. I don’t think DxO can miss the money for that. And are the clients,we, willing to pay the higher costs.
By the way, I use Microsoft Ice, Image Compose Editor, free and with a better result as the paid versions I tried out.

George

1 Like

There’re some faults in it. Make the same pano with ICE and see the differences.

George

They won’t even provide side by side image comparisons.
I wouldn’t expect panoramas to be high on the list.

And even when you can compare 2 images, there must be an easy way to tell what image is this and what image is that. PL lacks essential info in its screen: hard to find what program you use, hard to find what image you see, hard to find the path of that image(s).

George

Thanks for the suggestion. I’m a Mac user so don’t think Microsoft Ice will run on my hardware.

As others have pointed out, the paradigm of PhotoLab is intense work and intense corrections on a single image. Even image comparison is a reach in terms of performance. Simple image comparison should be manageable by turning off edit functions during image comparison.

It’s a long way from simple image comparison to a dynamic RAW panorama builder. Which is a makework project when other developers have excellent panorama builders already on the market, most of which need a RAW developer like PhotoLab powering the image preparation.


Just tested downloading and viewing my panorama 30000 pixel panorama on some image viewing applications.

  • mainstay LilyView hiccups and won’t go full screen with this image loaded.
  • Apple Preview beachballs and shows pixelated preview when I zoom to 100% for up to 30 seconds before showing detailed preview. Each sideways scroll results in very slow image drawing. I’m on an M1 chip so Intel performance is probably better.
  • Acorn 7 manages to show preview in real time with easy scrolling.
  • Brave browser is not too bad if one just drops the jpeg directly on a browser tab. One gets a plus/minus button and smooth scrolling.

Given that two dedicated image viewers including Apple’s own Preview cannot handle real time display of a 30000px wide image, I can’t imagine the processor havoc running that many pixels and images through PhotoLab’s RAW converter would create.

I’ve totally no problem viewing your image with IrfanView.
I did look for a pano I made in Spain, 33 images in 3 rows, 28.158x4.445=125.162.310 pixels.
I can’t upload it. If you’re interested tell me.

George

1 Like

IrfanView is amazing software. It’s a dedicated platform specific viewer, working from bitmap images. You make a good point: 33 x 3 images (28.158x4.445) would create an impossible load in PhotoLab processing RAW images.

I’d enjoy seeing your panorama.

33 images in 3 rows, 3 rows of each 11 images.
Tell me how to post it. I don’t know.

George