Bug with cinemaDNG importer

Hello. Premiere Pro CS 5.02 hang on import a AAF file (export from Avid Mediacomposer with DV edit) if cinemaDNG plugin is installed. I deleted the importer and Premiere works fine.
Best Regards

Was this on Mac or Windows? Which version of the importer did this happen with?
Would you be able to post the AAF file for me to test with, or e-mail me the file? How large is the file?
Thank you.
Ken Kameda

Similar Messages

Error: "File couldn't be opened for writing" with CinemaDNG sequence

Using a Premiere Pro > After Effects workflow with my colorist.
I created a project in Premiere CS6 and used MOV transcodes because Premiere CS6 does not read CinemaDNG sequences. I do not have CC installed on my computer. My colorist, on his computer (we are both using Mavericks), imported the .prproj into AE CS6. We tried to replace MOV files with CinemaDNG sequences, and AE returned this error:
After Effects error: File couldn't be opened for writing: "[file path]". ( 3 :: 0 )
Normally when you replace footage with a CinemaDNG sequence in AE, Adobe Camera Raw pops open so you can make changes before the file is important. I have never seen this error before.
My colorist has CC installed as well as CS6, so we tried that instead.
Colorist opened the Premiere CS6 project in Premiere CC, creating a new Premiere CC project. Replaced MOV files with CinemaDNG sequences within Premiere CC with no error, project plays fine in Premiere CC. Finally! So we imported the new Premiere CC project in AE CC, and all linked CinemaDNG sequences appear as color bars (unlinked footage). When testing to import a CinemaDNG sequence, AE CC returned the same error as AE CS6.
So we tried opening the same CinemaDNG files in Photoshop CS6 and Photoshop CC to see if there was an error with Camera Raw. Both versions of Photoshop open the CinemaDNG files correctly in Camera Raw (version 8.3). So now we have CinemaDNG files functioning properly in Premiere Pro, Photoshop, but... not AE?
Tried replicating this on a second, Mountain Lion computer with both versions of AE, and returned the same issue.
CinemaDNG files from a different source DID open in AE CC and AE CS6 on both computers, which leads me to believe there is some kind of permissions/metadata issue in this particular set of CinemaDNG files I'm using that's causing problems for AE, but NOT Premiere Pro or Photoshop. Anyone experience anything like this?

try the "oddball problems" fix:
http://www.bulletsandbones.com/GB/GBFAQ.html#oddballprobs
(Let the page FULLY load. The link to your answer is at the top of your screen)

Performance and usability problems with Illustrator imports

I am usually an enthusiast advocate for Adobe Software. As a UI/Interaction designer I regularly showcase your products as a shining example.
That's why I am somewhat frustrated about the Flash Catalyst Beta. I trust you guys to come out with SOMETHING GREAT eventually, but I have just spend an entire day with Catalyst and it was not particularly a joy. Couldn't you have released it a bit later to save me the frustration?
Situation:
- Medium size Adobe Illustrator CS4 import (10 screens/stages with 20-100 Illustrator objects per screen)
- Target : 800x600 embedded UI for medical product
- Illustrator file chosen as starting point
Performance / reliability problems include
- Crashing (Vista Core2Duo with 2gig of Ram)
- Super poor performance (wait 8 seconds to hide/show a layer)
- No show of thumbnail images anywhere
- No matching of document size (exact 800x600 from Illustrator became 800x599)
- Playing the file did not work
Usability issues
- Poor test display
- Poor match with Illustrator file (things seem to be rendered differently!)
- Window selecting does not work well
- No hand tool
- No ability to lock layers
- Cluttered interface (Not enough space for the "stage"or what you call it)
- No way to resize Illustrator elements from one of 9 edge/center points
- etc. etc.
Building a wireframe version from the ground up (with Illustrator import) seemed to work fine
I played around with the MS Blend beta for a while, and while the basic concept of your product is much more clear, the execution of the MS product in the beta phase was lightyears ahead in terms of stability and usability
I'm sure you can do better!
Koen

Koen,
Thank you for the detailed feedback about the performance problems you have experienced and your thoughts about features you would like. Let me respond to each of your points
Performance: We are aware that Catalyst doesn't perform well with large complex files. We have made many performance improvements since the current plublic beta, so you should find Catalyst more responsive with larger projects when the next beta is posted.
Here are a few things you can do to work around the performance issues you are seeing with the current beta:
- Consider rasterizing complex elements that don't need to scaled in Catalyst
- In Catalst turn complex artwork into optimized graphics using the "Convert to optimized graphics" in the float HUD (heads up display panel)
We have also found that particularly on Windows that Catalyst can run out of memory with large files. This area is also being worked on so stay tuned for the next beta.
Features:
- Poor test display [tv] Do you mean the design display doesn't match the appearance of the published project?
- Poor match with Illustrator file (things seem to be rendered differently!) [tv] we have fixed a lot of bugs here. Expect this to improve a lot in the next beta
- No hand tool - [tv] coming soon :-)
- No ability to lock layers [tv] coming soon :-)
- Cluttered interface (Not enough space for the "stage"or what you call it) [tv] Yes, Catalyst currently cannot dock/undock panels
- No way to resize Illustrator elements from one of 9 edge/center points [tv] This is also a known limitation. I agree it is useful
I hope the next beta comes closer to meeting your expectations. A lot of performance work and new features has been done since the last public posting, so look forward to beta II.
- Ty

Lightroom bugs with Windows Vista

I'm having difficulties with one of the file navigation controls in LR running under Windows Vista. The control that pops up with the import (choose files) function works fine, but the control that pops up with the add folder or create new library function misbehaves and causes LR to hang.
I've logged a ticket with Adobe, tried all the standard workarounds (run as administrator, re-create preferences etc.), but to no avail. I think it is a bug.
Has anyone experienced this? Any solutions out there?

What I've seen is that if you try to import from a card reader using the LR downloader, you get a list of files on the card and a message saying that they could not be imported. This also apparently damages the LR database because you cannot import even from a folder on the computer until you delete the database and create a new one. It happens in XP compatibility mode for me too. Otherwise, I have had no troubles using LR on my Vista machine. I can import from a card using another program's downloader and then import the folder into LR for editing.

Has anyone seen this BUG with Time Warp and Dissolve?

I'm doing some real basic slow-mo clips, transitioning with various dissolve wipes. I've come across a problem that is extreemly frustrating! I'm wondering if anyone has insight on a fix or if Adobe does service packs or fixes that I might be able to install.
If you put two clips adjacent to each other on a timeline, apply time warp, set percentage to say 30% of realtime, then apply a dissolve between the clips, clip B, the outclip will play in reverse for a period equal to about 1/3 of the duration of the clip.
This is true scrubbing through the timeline and even rendering.
VERY ANNOYING!
I'm going to call support tomorrow, but that's not going to help me get my project finished any sooner since this is a critical element in this composition. I've tried the time remapping method, but the frame-blend is no match for the pixel motion of time warp.

Steve,
I think your post #11 was being sarcastic, but you left a little wiggle room for it not to be. With the sarcastic interpretation, I must add my thoughts:
Here is the link to the Adobe bug report form
. It is important that users who discover bugs with reproducible steps file them - otherwise they don't stand a chance of ever getting fixed. Steven Gotz's advice was sound in this regard.
As to the discussion of workarounds - since this is a User-to-User forum, the best that we as a community can do is help each other out with workarounds, since none of us here have the power to actually fix anything.
The important thing to glean from SG's post is the definite need to file a bug report.

Optimization bug with C++ inlining

Hi,
While evaluating Sun Studio 11 I have identified an optimization bug with C++ inlining.
The bug can easily be reproduced with the small program below. The program produces
wrong results with -xO2, because an inline access function always returns the value 0.0
instead of the value given on the commandline:
djerba{ru}16 : CC -o polybug polybug.cc
djerba{ru}17 : ./polybug 1.0
coeff(0): 1.000000
djerba{ru}18 : CC -o polybug -xO2 polybug.cc
djerba{ru}19 : ./polybug 1.0
coeff(0): 0.000000            <<<<<<<<<< wrong, should be 1.000000This occurs only with optimization level O2; levels below or above O2 don't
exhibit the bug.
Compiler version is
Sun C++ 5.8 Patch 121017-01 2005/12/11
on Solaris 8 / Sparc.
I include a preliminary analysis at the end.
Best Regards
Dieter R.
-------------------- polybug.cc -------------------------
// note: this may look strange, but this is a heavily stripped down
// version of actual working application code...
#include <stdio.h>
#include <stdlib.h>
class Poly {
public:
    // constructor initializes number of valid coefficients to zero:
    Poly() { numvalid = 0; };
    ~Poly() {};
    // returns coefficient with index j, if valid. Otherwise returns 0.0:
    double coeff(int j) {
     if (j < numvalid) {
         return coefficients[j];
     } else {
         return 0.0;
   // copies contents of this Object to other Poly:
    void getPoly(Poly& q) { q = *this; };
    // data members:
    // valid coefficients: 0 ... (numvalid - 1)
    double coefficients[6];
    int numvalid;
void troublefunc(Poly* pC) {
    // copies Poly-Object to local Poly, extracts coefficient
    // with index 0 and prints it. Should be the value given
    // on commandline.
    // Poly constructor, getPoly and coeff are all inline!
    if (pC) {
     Poly pol;
     pC->getPoly(pol);
     printf("coeff(0): %f\n",pol.coeff(0));
int main(int argc,char* argv[]) {
    double d = atof(argv[1]);
    // creates Poly object and fills coefficient with index
    // 0 with the value given on commandline
    Poly* pC = new Poly;
    pC->coefficients[0] = d;
    pC->numvalid = 1;
    troublefunc(pC);
    return 0;
The disassembly fragment below shows that the access function coeff(0), instead
of retrieving coefficient[0] simply returns the fixed value 0.0 (presumably because the
optimizer "thinks" numvalid holds still the value 0 from the constructor and that therefore
the comparison "if (i < numvalid)" can be omitted).
Note: disassembly created from code compiled with -features=no%except for simplicity!
00010e68 <___const_seg_900000102>:
        ...     holds the value 0.0
00010e80 <__1cLtroublefunc6FpnEPoly__v_>:
   10e80:       90 90 00 08     orcc %g0, %o0, %o0      if (pC) {
   10e84:       02 40 00 14     be,pn   %icc, 10ed4
   10e88:       9c 03 bf 50     add %sp, -176, %sp
                                                   local Poly object at %sp + 120
                                                         numvalid at %sp + 0xa8 (168)
   10e8c:       c0 23 a0 a8     clr [ %sp + 0xa8 ]      Poly() { numvalid = 0; };
                                                         pC->getPoly(pol):
                                                         loop copies *pC to local Poly object
   10e90:       9a 03 a0 80     add %sp, 0x80, %o5
   10e94:       96 10 20 30     mov 0x30, %o3
   10e98:       d8 5a 00 0b     ldx [ %o0 + %o3 ], %o4
   10e9c:       96 a2 e0 08     subcc %o3, 8, %o3
   10ea0:       16 4f ff fe     bge %icc, 10e98
   10ea4:       d8 73 40 0b     stx %o4, [ %o5 + %o3 ]
                                                         pol.coeff(0):
                                                         load double value 0.0 at
                                                         ___const_seg_900000102 in %f0
                                                         (and address of format string in %o0)
   10ea8:       1b 00 00 43     sethi %hi(0x10c00), %o5
   10eac:       15 00 00 44     sethi %hi(0x11000), %o2
   10eb0:       c1 1b 62 68     ldd [ %o5 + 0x268 ], %f0
   10eb4:       90 02 a0 ac     add %o2, 0xac, %o0
   10eb8:       82 10 00 0f     mov %o7, %g1
                                                         store 0.0 in %f0 to stack and load it
                                                         from there to %o1/%o2
   10ebc:       c1 3b a0 60     std %f0, [ %sp + 0x60 ]
   10ec0:       d2 03 a0 60     ld [ %sp + 0x60 ], %o1
   10ec4:       d4 03 a0 64     ld [ %sp + 0x64 ], %o2
   10ec8:       9c 03 a0 b0     add %sp, 0xb0, %sp
                                                         call printf
   10ecc:       40 00 40 92     call 21114 <_PROCEDURE_LINKAGE_TABLE_+0x54>
   10ed0:       9e 10 00 01     mov %g1, %o7
   10ed4:       81 c3 e0 08     retl
   10ed8:       9c 03 a0 b0     add %sp, 0xb0, %sp
Hmmm... This seems to stress this formatting tags thing to its limits...

Thanks for confirming this.
No, this happens neither in an Open Source package nor in an important product. This is an internal product, which is continuously developed with Sun Tools since 1992 (with incidents like this one being very rare).
I am a bit concerned with this bug though, because it might indicate a weakness in the area of C++ inlining (after all, the compiler fails to correctly aggregate a sequence of three fairly simple inline functions, something which is quite common in our application). If, on the other hand, this is a singular failure caused by unique circumstances which we have hit by sheer (un)luck, it is always possible to work around this: explicitly defining a assignment operator instead of relying on the compiler-generated one is sufficient to make the bug go away.

Problems with VLM Import Utility

Hello!
We I are using NI Volume License Manager 3.0 together with NI Volume License Manager Import Utility for importing users data.
The problem is that we can't import .xml data into VLM when the user types his name into Full Name field and his name contains characters like ČŠĆŽĐ čšćžđ. These characters are not correctly written into .xml file with VLM Import Utility and we have to manually replace them with Microsoft Expression Web before we can load .xml file into VLM server.
Do you have better solution? Is there some new version of NI Volume License Manager Import Utility that correctly handles non English characters?
Thank you
Bojan Gergič
Solved!
Go to Solution.

Hi
Sorry for not having a god news. This issue is a known bug (You can refere to it by a number CAR - Corrective Action Request - #320545). Unfortunatelly, I have no knowledge about a workaround for this.
Regards
Barbara

Photo sync bug with Aperture albums?

Hi, I think I have found a bug with how iTunes syncs photos across to my new (and until my number ports across, useless) iPhone.
If you set it up that only selected Aperture albums are synced, like this;
[ ] album1
[tick] album2
[ ] album3
[tick] album4
then albums 2 and 4 are optimized and copied across.
However, if in Aperture you create a new album (by importing new photos, say) that appears in the list, e.g., between album2 and album3, then the ticks retain their spacial position, not their position relative to the album they are meant to sync;
[ ] album1
[tick] album2
[ ] album_new
[tick] album3
[ ] album4
So now, when you sync, album4 is deleted and album3 is placed on the phone - not what you would expect.
Has anyone else noticed this?
Tristan

Tweekme wrote:
It is fixed now though. If you upgrade to iTunes 7.5, and iPhone software Update 1.1.2
Hi Scott,
Thanks for the reply.
That's strange... I am using leopard, with iTunes 7.5 and a brand new UK iPhone (so it has 1.1.2 already on it). It was essentially in 'virgin' state too; I had to return my 1st phone due to a tiny but annoying problem with it. I noticed the this after only a couple of syncs - when the sync was taking a while due to the photo optimizing step.
I will take another look tonight.
Thanks,
Tristan

When trying to edit a photo, it disappears (black screen) or screen is full of lines. Is this a bug with the latest software update?

After updating with the latest software, when trying to edit a photo, it disappears (black screen) or screen is full of lines. If I blindly crop or edit the photo, when I exit edit mode, those changes have been made, but obviously this is unacceptable. Is this a bug with the latest software update?

There are several possible causes for the Black Screen issue
1. Permissions in the Library: Back Up and try rebuild the library: hold down the command and option (or alt) keys while launching iPhoto. Use the resulting dialogue to rebuild. Include the option to check and repair permissions.
2. Minor Database corruption: Back Up and try rebuild the library: hold down the command and option (or alt) keys while launching iPhoto. Use the resulting dialogue to rebuild.
3. A Damaged Photo: Select one of the affected photos in the iPhoto Window and right click on it. From the resulting menu select 'Show File (or 'Show Original File' if that's available). (On iPhoto 11 this option is under the File -> Reveal in Finder.) Will the file open in Preview? If not then the file is damaged. Time to restore from your back up.
4. A corrupted iPhoto Cache: Trash the com.apple.iPhoto folder from HD/Users/Your Name/ Library/ Caches...
5. A corrupted preference file: Trash the com.apple.iPhoto.plist file from the HD/Users/ Your Name / library / preferences folder. (Remember you'll need to reset your User options afterwards. These include minor settings like the window colour and so on. Note: If you've moved your library you'll need to point iPhoto at it again.)
If none of these help: As a Test:
Hold down the option (or alt) key key and launch iPhoto. From the resulting menu select 'Create Library'
Import a few pics into this new, blank library. Is the Problem repeated there?

Bug in organize imports

Hi,
There seem to be a couple of past bugs on organize imports- I'm not sure if this problem falls into the previous issues or not (or if they have been corrected.. ..as I side note, how does one access the list of open bugs? I can only find past fix lists)... ...any way, the issue:
* I had to import some legacy code which cotains a) unused imports and b) imports to vendor-specific classes (e.g. com.ibm.websphere.ldap.serializer.ModificationItem, rather then java.naming.directory.ModificationItem )
* if I choose to ogranize imports it generates malformed code, specifically:
--the class level javadoc is repeated (occurrs each time)
--often an empty import statement is put before the class-level javadoc
--"public class LDAPHelper" becomes
"public class LDAPHelper class LDAPHelper" (this problem occurrs each time)
Seeing how this code with its vendor specific implementations can't compile any way, it's not as annoying as it normally would be, but still a little surprising. Take care.

Sean,
does this happen with JDeveloper 10.1.3 ? Open bugs can be looked up in metalink.oracle.com if you have a support contract
Frank

Mac OS 10.6 not supported by the CinemaDNG importer

Just a heads-up to anyone downloading the CinemaDNG Importer - at this time, the importer will not work with Premiere Pro CS4 on Mac OS 10.6 (Snow Leopard). We hope to have a solution soon.
Thanks!
Elba
Sr. Program Manager
Adobe Systems, Inc.

I am happy to report that the CinemaDNG importer problems we were seeing with Mac OS 10.6 are resolved with Mac OS 10.6.1. If you are still having problems running the CinemaDNG importer in PremierePro CS4 after updating to Mac OS 10.6.1, please contact me.
Thanks,
Elba

CS5: Bug with Photoshop documents?

I frequently use layered Photoshop docs in Premiere, without much incident. I'll use them both flattened and as individual layers; if I need to make a change, I use Ctrl+E to open the image in PS, edit it, save, and it updates in the Premiere timeline. At least, that's how it worked in CS4, though I'd ocassionally and inexplicably have to Alt+Tab back and forth between PS and PPro once or twice in order to make the update "take."
Well, with CS5, it seems to be worse. After updating a PSD and returning to PPro, there is no visible change to the image in the Program Monitor. However, if I scrub or playback the sequence, the changes suddenly appear. Once I stop either activity, the original, non-edited version reappears. No amount of Alt+Tabbing seems to make the changes stick. I've found that if I sometimes open a different sequence, the image finally updates in "pause mode" but it's sort of hit-or-miss, too.
I seem to be noticing this more with PSD imported as individual layers, but I don't think it's specific to that particular import method. Anyone witnessing the same?
I am running a GTX 480 with the hack in place, and (apparently) the not-so-good current version of the nVidia drivers. Might this be a cause? I'll test out on my non-MPE workstation to see if there's a difference.

I had imported as merged.
I've tried again with the 8-layer image taking the following steps based on
your workflow:
1. Import PSD into PPro project as sequence.
2. Open sequence timeline and view output in Program Monitor.
3. Open PSD in PhotoShop.
4. Turn off 4 layers to give obvious visual effect.
5. Save from PS.
5. See no change at all on Premiere timeline.
This is exactly as I would expect because there is no link between PPro and
PS when edits are done externally like this. The footage would need to be
re-imported or the project re-opened to register the changes.
I also tried:
1. Select one layer in clip window.
2. Invoke Edit Original.
3. Turn on/off some layers to give obvious visual effect on image.
4. Save from PS.
5. No effect back in PPro even after re-rendering.
6. Deleting render files still did not force an update.
This is not what I was expecting and is, I think, worth reporting as a
potential bug.
NOT A GOOD ANSWER !
Because I don't often use import as sequence, I failed to realise that all layers are selected on by default in PPro, so turning off layers in PhotoShop doesn't give a useful test of this possible bug. Please ignore the above results, which I've only left up because some read this via newsgroups.
Out of time now. I'll do a better test on Thursday.
Message was edited by: akribie

30EA3: German language bug with user defined reports still not fixed

In 30EA2: Limited folder functionality with German language
I wrote about a bug in 30EA2. Was this message noticed by the developers?
The bug still exists in 30EA3.
In new folders for user definded reports only the options "Kopieren" and "Exportieren" (copy and export) are available, when SQL-Deverloper runs in German language mode.
A workaround is to force language to English with the line
AddVMOption -Duser.language=en
in sqldeveloper.conf

I made a new thread for the same bug in 3.1EA2:
3.1EA2 Old bug with German language settings still exists
I have some hope, that my problem finally got noticed by the developers.

3.1EA2 Old bug with German language settings still exists

In the past I wrote several times about a bug in SQL Developer when running in German language mode. This bug is still not fixed in 3.1 EA2:
In new folders for user definded reports only the options "Kopieren" and "Speichern unter ..." ('Copy' and 'Cave as') are available, when SQL-Deverloper runs in German language mode. Other options like "Bearbeiten, Neuer Ordner, Neuer Bericht, Ausschneiden, Einfügen, Löschen" (Edit, New Folder, New Report, Cut, Paste, Delete) are missing. A workaround is to force language to English with the line
AddVMOption -Duser.language=en
in sqldeveloper.conf
I mentioned it first in Re: Folders with limited functionality about version 2.1.1.64 and then in 30EA2: Limited folder functionality with German language 3.0 EA2 and German language bug with user defined reports still not fixed Beta Release 3.0 EA3
Edited by: user1775992 on 22.11.2011 03:30

I have raised a bug on this issue and I am actively looking into it.

Okay, i have 2 bugs with maverick. First, when I delete a file within a window, the files deletes but the preview doesn't delete until I close the window and reopen it. Second, I work on a network of computers and the search feature is now buggy...

Okay, i have 2 bugs with maverick. First, when I delete a file within a window, the files deletes but the preview doesn't delete until I close the window and reopen it. Second, I work on a network of computers and the search feature is now buggy... When I search for a file, A) it asks me if it's a name, or it wont produce anything, and B), its slower than in prior OS versions and in some instances I have to toggle to a different directory and go back to my original directory in the search: menu bar or the search wont produce anything... Very buggy.

It appears to me that network file access is buggy in Maverick.
In my case I have a USB Drive attached to airport extreme (new model) and when I open folders on that drive they all appear empty. If I right click and I select get info after a few minutes! I get a list of the content.
It makes impossible navigate a directory tree.
File access has been trashed in Maverick.
They have improved (read broken) Finder. I need to manage a way to downgrade to Lion again.

Bug with cinemaDNG importer

Similar Messages

Maybe you are looking for