DPP 4.8.x Feedback Thread

[shadowsports]

Have you recently upgraded to DPP 4.8.20 for Windows or MAC. 

Please include:

Version and build of your OS

Fresh install or Upgrade from previous version of DPP

Your experience or feedback

[47greyfox]

See my previous post that DPP 4.8.20 crashes on startup. I have determined that if the folder the programs opens to has any non-image files in it, the program crashes. I have been able to reliably replicate 100%.

[RobertTheFat]

---

@47greyfoxwrote:

See my previous post that DPP 4.8.20 crashes on startup. I have determined that if the folder the programs opens to has any non-image files in it, the program crashes. I have been able to reliably replicate 100%.

---

And I'm afraid I've just disproved it. Whatever your problem is, your statement of it must be too broad.

[wq9nsc]

I forgot and navigated to a troublesome folder today which does cause 4.8.2 to consistently crash (running on a HP workstation with Win 10 pro, all software up to date).  The troublesome folder has all jpg files in the root along with multiple sub-folders all containing nothing but jpg files.  All of these jpg files started as RAW files from my 1DM2 and were converted to jpg with an earlier version of DPP.   4.8.2 will consistently lock up while it is trying to load files in the main folder but is fine once navigated to any of the sub-folders and the lockup can be avoided by switching to a new folder before the lockup occurs.  It takes a few seconds of loading before the error occurs.

It isn't a huge issue because I can pull any files I need out of there and put them elsewhere to edit but I forgot about this issue this morning while trying to quickly create an avatar for a website profile and DPP reminded me of this crash problem I had run into earlier.  I suspect the problem is related to the large number of jpg files contained within the directory and subdirectory structure although the stadard directory structure I used for my older 1DM2 and current 1DXM2 consists of sub-directories by date with a further jpg subdirectory for that date when I create a large number of jpg files and DPP 4.8.2 has no problem with these very large and file rich directory structures.

Rodger  

[RobertTheFat]

---

@wq9nscwrote:

I forgot and navigated to a troublesome folder today which does cause 4.8.2 to consistently crash (running on a HP workstation with Win 10 pro, all software up to date).  The troublesome folder has all jpg files in the root along with multiple sub-folders all containing nothing but jpg files.  All of these jpg files started as RAW files from my 1DM2 and were converted to jpg with an earlier version of DPP.   4.8.2 will consistently lock up while it is trying to load files in the main folder but is fine once navigated to any of the sub-folders and the lockup can be avoided by switching to a new folder before the lockup occurs.  It takes a few seconds of loading before the error occurs.

It isn't a huge issue because I can pull any files I need out of there and put them elsewhere to edit but I forgot about this issue this morning while trying to quickly create an avatar for a website profile and DPP reminded me of this crash problem I had run into earlier.  I suspect the problem is related to the large number of jpg files contained within the directory and subdirectory structure although the stadard directory structure I used for my older 1DM2 and current 1DXM2 consists of sub-directories by date with a further jpg subdirectory for that date when I create a large number of jpg files and DPP 4.8.2 has no problem with these very large and file rich directory structures.

Rodger  

---

See my reply to the Grey Fox. I think your problem is related to the one he's having and to one that I've had in the past.

[47greyfox]

Bob of Boston...

Then there must be a particular kind of file that DPP 4.8.20 doesn’t like that populates a number of my folders. For example, the main “pictures” folder as it initially loads shows a number of items with “?” Instead of images. I don’t know if they are non-images files or folders. Within seconds, I get the dreaded pop-up saying that DPP has stopped working and the program crashes. The files with the question marks have a “j” in the corner indicating that they are jpegs. Many of the others have no marker. When I move all out of the folder into their own “trouble” folder. DPP loads fine. If I drag individual images back into the main pictures folder, eventually it crashes, BUT there doesn’t seem to be anything unusual about the images I move. DPP 3 has no similar problem. 

[RobertTheFat]

---

@47greyfoxwrote:

Bob of Boston...

Then there must be a particular kind of file that DPP 4.8.20 doesn’t like that populates a number of my folders. For example, the main “pictures” folder as it initially loads shows a number of items with “?” Instead of images. I don’t know if they are non-images files or folders. Within seconds, I get the dreaded pop-up saying that DPP has stopped working and the program crashes. The files with the question marks have a “j” in the corner indicating that they are jpegs. Many of the others have no marker. When I move all out of the folder into their own “trouble” folder. DPP loads fine. If I drag individual images back into the main pictures folder, eventually it crashes, BUT there doesn’t seem to be anything unusual about the images I move. DPP 3 has no similar problem. 

---

Windows Explorer should tell you (from the file type if not otherwise) whether the files with the question mark are RAW files, JPEGs, or not image files. I'm pretty sure that the problem you're having is that they are image files, not that they aren't. Many releases of DPP, going back at least as far as early releases of Version 3, have had random (and sometimes non-random) problems reading old JPEGs, especially (but not exclusively) JPRGs written by other editors. Sometimes the evidence is just the question mark, and sometimes DPP crashes (although crashes seem less frequent than they once were). Whether those files violate some aspect of the JPEG standard, I don't know. But even if they do, a) earlier versions of DPP could read them, and b) the program should simply say it can't read them, not crash.

I have complained about this problem before and reported it to Canon. On at least one occasion, I sent them a JPEG that DPP couldn't read. AFAIK, they never reported a conclusion, but the next release of DPP was able to read it.

[wq9nsc]

On edit:  Thanks Bob, I agree and we were typing at the same time 🙂

Original message follows:

In support of what Bob stated it is possible the specific problem I found is because some of the JPG files in this specific directory have been modified by Irfanview.  I have often used that program to quickly resize an image for forums that have strict pixel count and file size limits because it is "lightweight" program that allows you to easily down sample to a desired size and set a file size limit for output files. That program never gets used within the twin directory structures that contain my 1DM2 and 1DX M2 files so that could be why it crashes in that directory system but not the others.  DPP 4.8.2 doesn't seem to have a problem with any of the individual sub-directories when selected by themselves so I suspect the crash problem is a combination of a specific JPG file idiosyncrasy combined with a very large number of overall files.

Rodger

[47greyfox]

Thanks, Rodger. You're making a believer out of me. I moved all the images out of the main "pictures" folder into a standalone then started bringing in images one at a time. All (?) the troublesome seem to be bmp or jpegs that were created from other applications like PSE or captured off the net. However, there are other images of the same type that DPP 4.8.20 had no issue with. Other than the folders in the "pictues" folder itself, there were 58 other images. I've since moved them all into a folder entired "working DPP trouble" and will gradually move them to other related folders. Yes, I occasionally use Irfanview. DPP 3.14.40.0 will read the same folder just fine except it sees 51 images and not 58. I'm thinking it better handles problem children by ignoring them. 🙂

[RobertTheFat]

---

@47greyfoxwrote:

Thanks, Rodger. You're making a believer out of me. I moved all the images out of the main "pictures" folder into a standalone then started bringing in images one at a time. All (?) the troublesome seem to be bmp or jpegs that were created from other applications like PSE or captured off the net. However, there are other images of the same type that DPP 4.8.20 had no issue with. Other than the folders in the "pictues" folder itself, there were 58 other images. I've since moved them all into a folder entired "working DPP trouble" and will gradually move them to other related folders. Yes, I occasionally use Irfanview. DPP 3.14.40.0 will read the same folder just fine except it sees 51 images and not 58. I'm thinking it better handles problem children by ignoring them. 🙂

---

If I had to solve this problem (e.g., if I worked for Canon or their software contractor), I'd begin by taking note of the fact that DPP is unusual among photo editors in that it maintains reversible changes in both its RAW and JPEG files. That means that it has to be able to recognize such changes and deal with them any time it edits an image file. And that means, in turn, that there has to be an identifiable marker, probably associated with the Exif data, in a predictable position in the file. That shouldn't be a problem, as long as DPP was the most recent editor of any file it sees. But if that was some other editor, there's no obvious way to prevent that editor from inadvertently placing a marker in the file that fools DPP into looking for changes that aren't there. And that raises the possibility that DPP will find itself trying to process a file that is, from its point of view, seriously corrupted. And if that corruption is not recognized for what it is, the program may very well crash. So if DPP is to avoid being fooled, it needs a pretty sophisticated algorithm to differentiate valid changes from those that are bogus. If that algorithm is prone to mistakes, the program will occasionally find itself in trouble.

Obviously, what I've described is not the only possible source of the observed behavior. But my gut tells me that the probability is high enough that the expenditure of some effort to rule it out may be justified.

[Maru]

Version: MacOs High Sierra 10.13.4

Fresh install DPP 4.8.20

It doesn't run. It shows a message for a needed new version of dppm4.8.20-installer.dmg

😞