Problem processing JPGs and TIFFs from Canon CR2 RAWs
I am trying to export JPGs and TIFFs from full size Canon 5D3 RAW files. When I process the JPGs (or TIFFs), about 1/3 of them are able to open properly in Photoshop and also viewable in Bridge CS6. The rest show a generic JPG/TIFF icon and when opened, Photoshop displays the following message:
JPGs:
TIFFs:
Here are my output settings:
Format: JPEG
Quality: 50
ICC: sRGB Color Space Profile
Resolution: 150 px/in
Scale: Long Edge 1000px
Open With: None
Format: TIFF
Compression: None
ICC: sRGB
Resolution: 150 px/in
Scale: Long Edge 1000px
Has anyone experienced this and can offer a solution? The CR2 files are viewable, zoomable, and can also be seen/processed in ACR without a problem. They are the full sized RAWs and not sRAWs. Oddly, I can process the files using the JPEG QuickProof preset, but then I need to resize them in Bridge because they end up 2560px on the longest end, too big for me to send as proofs to my client.
The images are in a session on my main/local rMBP SSD drive and I have over 586GB free space. I'm using C1 7.1 build 66271 and OSX 10.8.2.
JPGs:
Could not complete your request because a JPEG marker segment length is too short (the file may be truncated or incomplete).
TIFFs:
Could not complete your request because of a program error.
Here are my output settings:
Format: JPEG
Quality: 50
ICC: sRGB Color Space Profile
Resolution: 150 px/in
Scale: Long Edge 1000px
Open With: None
Format: TIFF
Compression: None
ICC: sRGB
Resolution: 150 px/in
Scale: Long Edge 1000px
Has anyone experienced this and can offer a solution? The CR2 files are viewable, zoomable, and can also be seen/processed in ACR without a problem. They are the full sized RAWs and not sRAWs. Oddly, I can process the files using the JPEG QuickProof preset, but then I need to resize them in Bridge because they end up 2560px on the longest end, too big for me to send as proofs to my client.
The images are in a session on my main/local rMBP SSD drive and I have over 586GB free space. I'm using C1 7.1 build 66271 and OSX 10.8.2.
0
-
First rescue attempt is to go to CO7 Preferences > General tab > Hardware Acc (OpenCL) and set Never for processing. Next, restart CO7 and process a few files again. 0 -
This same issue occures with in jpegs and tiffs which are processed/managed with e. g. iDimager DAM tool.
The issue is, that iDimager write "bullshit" into jpg/tiff metatage containers, which are causing a variety of errors,
The reasons are
- wrong content in wrong containers of dc, itpc, xml etc.
- wrong JFIF versions are used (1.1 vs 1.2) and different goupings of the metadata are used produced etc.
- wrong entities are enterd in wrong formats
---
As I mentioned in other posts, COne writes/attaches the same mixed-ups metadata after processing files, despite which the manufacturer is and, randomly, with the same camera body or even with the same camery body!
Again: COne has problems in handling ISO values: Since COne 7 in not ONE raw file the ISO value can be indcated in Viewer or is shown in the list view or inside the metadata tool.
---
If you google about IPTC/EXIF data errors, there a lot problems published on several websites.
There exists the JFIF standard, but it is not a mandatory or a standardising necessary - the JFIF specifacation os used as a guideline wiht a lot of freedom: Even the same manufacturer (here) Nikon uses different containers with different names in EACH camera . here is no consistency and every construction team uses different tags. Not one model of Niikons cameras uses the same set of tags.
---
If than a software manufacturer used the published JFIF/TIFF description, but the camera manufacturer does not follow these guidelines, some of bad tagged/filled containers are producing erratic errors.
---
If COne follows the JFIF/TIFF standard, but the manufacturer does not, COne assumes correct values, but processes rubbish in return to that discrepancy.
Adobe e. g. circumvents these problems by just skipping/ignoring(stripping metadata in order to be able to process these files anyway, but then without emptied metatag containers.
---
A WORKAROUND/PROOF to that behavior i the following - Mac Only:
1. Open the regarding files and some from other cameras or produced by other software using Apple's Preview and first inspect the metatags with +i and inspect the groupings - not one will be exactly the same!
2. Take that non-processesable file and store this file with Preview while changing e. g. ± 5% under a new name.
3. This new file can be opened with COne, because Preview strips those incompatible/wrong containers - this can be proved by opening both files and inspecting the file information of both with +i. Usually the non-openable file in COne does contain different JFIF versions the newly saved and openable in COne file: JFIF=1.2(or sometimes 1.02) is indicated for the one that cannot be opened with COne - JFIF 1.1 (1.01) for those, that can be opened with COne.
---
For further analysis use EXIFtool the extract/diplay the complete metadata of each file - take care that the necessary Perl libraries that EXIFtolls relies on is installed (usually Mac OS X does contain these Perl-libaries.
The easiest way to use EXIFtool with just drag and drop is to in install a Python GUI-program on top of EXIFtool called "List Exif Metadata". Here it is necessary to have Python installed as well in the correct version, which usually should as well be present on Mac OS X.
EXIFtool does indicate in the first two or three lines of the output the errors/warnings about the incorrect metadata containers. Be aware, that even only "Warnings" or even "Minor Warnings" cause some applications to reject the opening of those "bad files".
---
For further information feel free to PM, because this becomes a "too deep dive" into these issues.
I spent more than 3 days in total to figure out this misbehavin' inconvenience ...
saludos redondos -
tom0 -
[quote="Paul_Steunebrink" wrote:
First rescue attempt is to go to CO7 Preferences > General tab > Hardware Acc (OpenCL) and set Never for processing. Next, restart CO7 and process a few files again.
To disable Open GL and or restart COne will not resolve this problem! It relies upon something completely different - it is related to a misconception of the use of metadata by assuming that all manufacturers are using identical sets/subsets from the JFIF/TIFF specifications.
This problems occurs on Win XP/7/8 as well as on Mac OS.
---
OpenGL issues might? harm stability or performance and can? lead to at least kernel-panic - but that is OS and not file format. The use/neglection of OpenGL will not fix wrong assumptions/implementations regarding architecture or underlying software modeling.
---
Due to those facts, it is not necessarily bug with the CODING of COne, because some other applications produce these errors. The reported misbehavin' occurs with applications that never ever use OpenGL because we detected these errors at times, long before OpenGL could used and 64bit applications were far away from even being compiled.
saludos redondos -
tom0 -
@tom
Are you referring to OpenCL where you have stated OpenGL?0 -
[quote="SteveCase2" wrote:
@tom
Are you referring to OpenCL where you have stated OpenGL?
Yes you are right - sorry for that mix-up
saludos redondos -
tom0
投稿コメントは受け付けていません。
コメント
5件のコメント