DPP Software Suggestion

[Dave410]

This is a long shot, but I hope Canon will at least consider it.

A Canon rep told me to make my suggestion on this forum.

As you know, a lot of the data in the RAW file is proprietary.  DPP can read it, but Adobe and other companies must strip it out and create their own camera matching profiles, which aren't as good as Canon's profiles.  In general, you can usually get a better image by processing in DPP than in Adobe Lightroom or other products.  (If you disagree, please do your own testing and do some research online.)

As you also know, DPP is slow and clunky.  Lightroom and other products are much easier to use and provide more features.  Nikon Studio is also slow and clunky.

I suggest Canon give Adobe and other companies access to the proprietary data. 

Canon is a camera company, not a software company.  They don't make any money from DPP; they give it away for free.

Canon must provide some kind of software with the camera to make it work so DPP must continue, but why should they care if photographers get great results with other software?  In fact, they should want every photographer to get the best possible images no matter what processing software they are using. 

There are undoubtedly aspects I don't understand, but Canon does not compete with Adobe, etc., so why not help them make Canon products even more versatile? 

At least think about it.  Many photographers (like me) would be very happy.  

[rs-eos]

For feature or other requests, you'll need to visit the main Canon USA Web Page and near the upper right (or at the bottom next to the copyright notice), click on "[+] Feedback"

Having said that, it's doubtful that Canon would disclose any proprietary information.  It's their intellectual property (IP) and is thus closely guarded.  Canon probably also holds existing patents related to this IP.

[Dave410]

Thanks, Ricky.

[Peter]

Canon could just do the same as GoPro did https://github.com/gopro/gpr

Why make it hard for developers to decode the raw files, including the Makernotes with its lens correction?

RawTherapee, ART, darktable, DigiKam, Topaz Studio, Photomatix, ON1, ACDSee, easyHDR, SILKYPIX, AfterShot Pro and Affinity Photo are all relying on user created lens profiles.

Capture One creates its own lens profiles. It has one lens profile for EF-M mount.

[shadowsports]

Greetings,

I use DPP and DxO.  DxO doesn't have any problem reading a great deal of proprietary data from.cr2 and.cr3 image files.  It's lens profiles work great too. It doesn't matter for me too much anymore since I only use Canon glass.  The only reason I stopped using DPP originally is because I had a bunch of third party lenses, but not anymore.  I don't think that there's consistency across the industry. Canon does it one way Fuji does it another Panasonic and Nikon have their own formats as well.  Lately I use DPP when I'm on the road, and DXO at home.  I don't have to import with camera raw or convert anything. They go in as.cr2 or .cr3 and come out in whatever format i want, usually JPEG.  I encourage people to use whatever is best for their workflow, whatever they feel comfortable with and gives them the results they're looking for.

Please use Ricky's suggestion to submit feedback. This is the best way to get suggestions and feature requests to Canon.

[johnrmoyer]

I disagree. It has been many years since I have used any Adobe software.

Part of the reason why DPP seems slow is that the algorithms that get the best results are often not the fastest. For the same sort of processing, rawtherapee takes about the same time. I built rawtherapee from the "dev" branch of source code on my Linux computer and use it occasionally, but I mostly use Canon DPP.

[Peter]

---

@johnrmoyer wrote:

Part of the reason why DPP seems slow is that the algorithms that get the best results are often not the fastest. For the same sort of processing, rawtherapee takes about the same time.

---

RawTherapee uses only CPU. There is a benefit of using GPU instead when using the demosaicing method RCD+VNG4 that RawTherapee also has. GPU vs CPU in darktable for RCD+VNG4 and R5 gives 0.314 sec for GPU or 3.355 sec for CPU. I hope RawTherapee someday gets GPU support.

[johnrmoyer]

Disclaimer: It has been several years since I have written code for a GPU and two decades since I have written much assembly language.

CPU vs. GPU depends upon the particular memory architecture, whether the GPU can do double precision floating point arithmetic, the number of CPU cores, and whether the algorithm can be parallelized. It is difficult to write portable code for GPUs. I have 3 different GPU architectures on my computers, AMD, Intel, and Nvidia. All code would need to be written 3 times and the results would vary depending upon which GPU was use. The main CPU will do IEEE 754 standard arithmetic, but a GPU usually will not. Standard arithmetic gives a predictable result.

There is a big difference between GPU on CPU chip and sharing memory with CPU vs. GPU on separate chip with own memory. If GPU on CPU chip, then they contend for memory access. If GPU and CPU have separate memory, then bandwidth of memory copy between the two can be a bottleneck.

All of my computer CPUs are Intel which also has parallel operations built into the CPU chips, but Arm in my cell phone. The vector arithmetic in Intel CPU registers is very fast.

I prefer rawtherapee to darktable, but usually use DPP.

If you want faster in DPP, then you have a choice between speed and quality: https://cam.start.canon/en/S002/manual/html/UG-04_EditImage_0040.html#EditImage_0130_4

[Peter]

I will try that setting. I am using DPP in Virtual box so I don't have all threads available and of course, no GPU either.

[johnrmoyer]

I hope some of this might be helpful.

Before I got an iMac, I ran DPP in a Windows virtual machine on Debian Linux. I used qemu. It is possible with qemu to give a GPU to a virtual machine. My Debian machine has 56 GB RAM, so can cache the entire Windows virtual hard drive. I gave the virtual machine only 8 GB RAM because the only Windows program I ran was DPP and my camera at the time was an EOS 80D and caching the virtual hard drive in RAM gave a greater speed up than more RAM for the virtual machine. The CPU on the Debian machine is a Xeon which also helps. Most of my storage is attached to the Debian machine and is shared via SMB. I used dd to create the virtual drive image from a Windows machine where I had a windows license not tied to particular hardware.

My qemu command line:

qemu-system-x86_64 --enable-kvm -cpu host -smp cores=2,threads=4 -vga std  -m 8G -boot once=d -rtc base=localtime -drive file=/home/jrm/warehouse_dd/warehouse_2012dec30_win7-10.bin,format=raw  -name old_warehouse -enable-kvm -net user -net nic -cdrom /dev/cdrom

DPP ran reasonably well with 2 virtual CPU cores and 4 threads. I used psftp to transfer files between Linux file system and virtual Windows because I find Windows file sharing difficult to secure and the Windows virtual machine needed network connection to verify license and get updates.

Since I have retired and have no employer to require Windows, I bought an iMac and no longer do Windows.

The biggest speed up for DPP is to have a lot of RAM. I expanded my iMac to 96 GB RAM.