10.0.1 vignette bug

10.0.1 seems incredibly unstable and buggy, I thought it was meant to resolve these issues?
One big problem I'm having is that I've applied a vignette effect to a clip on the secondary timeline. Now any time I go near this clip, FCPX crashes. This has obviously rendered the project entirely unusable, which is a big problem, particularly if 10.0.2 doesn't come along for a few more months.
I tried opening an old project which shouldn't have the new file in it and therefore shouldn't be a problem but despite being a day older and therefore unable to have this new file, the old project is identical when you open it up in FCP, so potentially something going on there as well?
I'm running a brand new macbook pro i7 in lion, so the issue won't be a lack of graphics support.

Sorry, still learning here and a little confused. I'd love to delete the vignette entirely, but the only method I know is to drag it out of the effects in the inspector, or click reset in the vignette settings(inspector) but the inspector absolutely does not want anything to do with this clip. I also right clicked the clip, but I don't see anything there about the clips effects. Is there another method I am missing?
The video is 1080p 30
The project originated in 10.0.1
Haven't tried creating a new project and adding media yet. I will try deleting the clip from the sequence and replacing it with the raw clip.....
Thanks....
PS: Same issue with projects originating in FCPX 10.0.1 and several that are imported iMovie projects.....

Similar Messages

Bug? Vignetting & Adjustment Brush

Hello.
This if my first post, so please don't be too harsh if I make any mistakes. I encountered a bug (well, at least I think it is one) while using LR3 on Win7.
While editing my images I added a post-crop vignetting. After finishing the colour & contrast stuff, I went on to retouching. After "inserting" the first adjustment brush, the vignetting changes, which, I think, shouldn't happen, because I dind't even touch any area near the vignetting. See the screenshots for details. (Sorry for the black areas, I didn't want to show the person I photographed.)
The difference is not very well visible if the screenshots are placed next to each other. However you can open both images in different tabs and switch between them, then you should definitely see it. Has anyone noticed that behavior before? Or does anybody have a clue what's happening here? I would be even happy for workarounds because I use both tools very often.
Thank you!
Luc y Lou

I'm experiencing this bug as well. In addition to the extra strength post-crop vignette that happens, I'm also getting blotchy tiles where the post-crop vignette is supposed to be when I apply an exposure brush, as seen in the attached screen grab. Takes some fiddling around to make it go away. Usually turning off the "Effects" tab then turning it back on clears it up.
I'm on LR 3.2 using an iMac i7 quad 2.8ghz, 12gb RAM, ATI 4850 card 512mb V-RAM, plenty of disc space, working on Canon 5DMk2 raw files. Cache has been cleared and catalog optimized.

BUG REPORT - Lens Vignette slider

The Lens Vignette slider only goes from 0-100, but if you float over the slider and use the arrow keys, it carries on going into minus figures, and also records that as part of the history. Other sliders don't show the same behaviour, and the effect of going into minus figures looks like the default setting of 50.
Victoria
(MacBook Pro 2.16ghz, 2gb RAM, OS 10.4.8)

thanks for info. Sorry I didn't post this earlier but the slider has corrected itself. Also the is probably being used by the os

"Invert" button in vignette doesn't work

When trying to apply a vignette fx in the Color FX tab the "Invert" button doesn't do the trick. Any suggestyions what can be happening ? Cheers

It's a bug. Use the invert node.

IPhoto 7.1 has fixed the iPhoto 6 "revert to original" bug

Over a year ago I posted on an iPhoto bug, possibly related to use of importing Libraries.
http://discussions.apple.com/thread.jspa?messageID=3031479 was the original thread, but it's long been archived.
Basically, iPhoto would show the 'revert to original' command even on images that had never been modified. This had odd side-effects with some software. A contributor to one of my blogs found that "file Library6.iPhoto and concluded that the conversion of a field "idED" went wrong. I was able to repair the file using a HEX editor."
The good news is that when I converted a test Library that had an image showing this behavior, iPhoto 7.1 converted correctly. The incorrect 'revert to original' status was gone.
Nice to find something fixed!

EStav:
Welcome to the Apple Discussions. What's happening with the V7 vignette is that a vignette mask is created and applied to the photo. If you crop the photo the same mask is applied to the cropped area just enlarging the visible part in the vignette.
To do what you want you now have to export the file and reimport as a new photo and crop that one. A bummer, I know. Otherwise get a 3rd party editor that you can do all of that in one step and then save.
TIP: For insurance against the iPhoto database corruption that many users have experienced I recommend making a backup copy of the Library6.iPhoto (iPhoto.Library for iPhoto 5 and earlier) database file and keep it current. If problems crop up where iPhoto suddenly can't see any photos or thinks there are no photos in the library, replacing the working Library6.iPhoto file with the backup will often get the library back. By keeping it current I mean backup after each import and/or any serious editing or work on books, slideshows, calendars, cards, etc. That insures that if a problem pops up and you do need to replace the database file, you'll retain all those efforts. It doesn't take long to make the backup and it's good insurance.
I've created an Automator workflow application (requires Tiger), iPhoto dB File Backup, that will copy the selected Library6.iPhoto file from your iPhoto Library folder to the Pictures folder, replacing any previous version of it. It's compatible with iPhoto 6 and 7 libraries and Tiger and Leopard. iPhoto does not have to be closed to run the application, just idle. You can download it at Toad's Cellar. Be sure to read the Read Me pdf file.

LR5 - serious bug?

I've found this bug with several photos; it's completely reproducible.
Start with a photo edited in a previous version of LR. In develop module, there's a list of commands in the history on the left.
If I click anywhere in the history, all edits above where I have clicked disappear and are replaced with "Post-Crop Vignette Style: Paint Overlay". I have no vignette applied.
"Undo" doesn't then work: the edits are irretrievably lost and the "vignette style" command can't be removed.
If I have edited the photo in LR5, I can go back to any of the LR5 edits without difficulty: it's only if I go to edits previously applied in LR4 that the problem arises.
I've checked the integrity of the catalogue: it's fine.
Has anyone else seen this? Any suggestions?
Jeremy

Known bug, to be fixed not even god knows when.
In the mean time, I think you can work-around simply by applying a dummy preset to all your photos, but you'll have to edit it after creation to assure it doesn't really do anything.
It should look like this after you edit it with a text editor:
s = {
     id = "F36E8CB3-B52B-41AC-8FA9-1989FAFD5224",
     internalName = "No Edit",
     title = "No Edit",
     type = "Develop",
     value = {
          settings = {
               NoEdit = true,
          uuid = "44402820-B470-4D5B-9369-0502F2176B70",
     version = 0,
The only part you need to edit is the part between
settings = {
and the
that closes the settings.
Rob

Lightroom 5.3 bug with export images

Hi,
I can't export single images in Lightroom anymore. When I choose an image including the watermark the system exports all the latest imported images, but not a single one. Can anyone help me with that?
-jo

in your lr5.2, click help>updates...
bug fixes:
Issues when upgrading catalog from previous versions of Lightroom.
Incorrect photos are displayed after switching away from a Publish Collection.
Catalog optimization did not finish, and was not optimizing the catalog
Feather of clone spots is set to 0 after upgrading catalog to Lightroom 5.
Auto White Balance settings are not saved to Snapshots.
Sony 18-55mm lens is detected as the Hasselblad 18-55mm lens for lens correction.
Increased Update Spot Removal history steps when in Before and After view.
Slideshows start playing automatically even when the Manual Slideshow option is enabled.
Video playback stops when dragging on the scrubber.
Errors when publishing photos to Flickr through the Publish Service.
Option + drag on Edit Pin behavior is functioning incorrectly.
Black border appears around the exported slideshow video.
Catalog containing images processed with PV2003 were adding a post-crop vignette when catalog upgraded to Lightroom 5.
Pressing the “Reset” button while holding down the Shift key caused Lightroom to exit abruptly.
Output Sharpening and Noise Reduction were not applied to exported images that were resized to less than 1/3 of the original image size.
The Esc key did not exit the slideshow after right clicking screen with mouse during slideshow playing.
Import dialog remained blank for folders that contain PNG files with XMP sidecars.
Metadata panel displayed incorrect information after modifying published photo. Please note that this only occurred when metadata was changed after the photo was published.

When I make changes to 'Outside' of vignette, it affects the entire image

Hi everyone,
I seem to be running into a problem in the secondaries tab of Color. When I create a circle-shape vignette and set the Control to 'Outside', I make changes and it works like how it should, it ONLY affects the areas outside of the circle. However, I created a tracker in the geometry room in order to track a face in the scene. As soon as I set the 'Use Tracker' to track the vignette, the outside settings suddenly affect the whole picture. The weird thing is, the settings for 'Inside' work fine with the tracked vignette. I don't understand how it would work fine for one and not the other.
Am I doing something wrong? Is this a bug? I'm running Color 1.0.4. The reason I'm doing this is because the shot is of a character sitting on a couch in front of a green wall. The character is leaning forward ashing a cigarette, then leaning back onto the couch. I'm trying adjust only the green color on the wall but a square or custom vignette won't work since the character face enters the area of the wall (and the light reflecting off of the wall adds a slight green color on the side of his face so it affects that).
Any advice would be appreciated. Thanks!

JP Owens wrote:
I don't know why people have this need to do things by the most complicated, error-prone, labour intensive means possible.
Because people don't know and where does one go to get knowledge anymore? I suppose one could also post a query on the Cow but anymore, everyone answering a question is trying to hawk their instructional book/dvd/website/package of pre-built "looks."
That reminds me, when is your book coming out, Joe? I'll preorder it right now.
How many users of Color even know about the limiter in FCP's 3Way Color Corrector? How many people even know what an HSL key is and how to use those qualifiers? Color is cheap so it must be easy, or so Apple says. Only going to get worse before it gets better.

Lightroom 5.3 bug fixes.

Lightroom 5.3 is a 800MB download. Where can I get a sensible size file just for the bug fixes?
Also where is there a list of the fixes? The readme file gives nothing usefull.

in your lr5.2, click help>updates...
bug fixes:
Issues when upgrading catalog from previous versions of Lightroom.
Incorrect photos are displayed after switching away from a Publish Collection.
Catalog optimization did not finish, and was not optimizing the catalog
Feather of clone spots is set to 0 after upgrading catalog to Lightroom 5.
Auto White Balance settings are not saved to Snapshots.
Sony 18-55mm lens is detected as the Hasselblad 18-55mm lens for lens correction.
Increased Update Spot Removal history steps when in Before and After view.
Slideshows start playing automatically even when the Manual Slideshow option is enabled.
Video playback stops when dragging on the scrubber.
Errors when publishing photos to Flickr through the Publish Service.
Option + drag on Edit Pin behavior is functioning incorrectly.
Black border appears around the exported slideshow video.
Catalog containing images processed with PV2003 were adding a post-crop vignette when catalog upgraded to Lightroom 5.
Pressing the “Reset” button while holding down the Shift key caused Lightroom to exit abruptly.
Output Sharpening and Noise Reduction were not applied to exported images that were resized to less than 1/3 of the original image size.
The Esc key did not exit the slideshow after right clicking screen with mouse during slideshow playing.
Import dialog remained blank for folders that contain PNG files with XMP sidecars.
Metadata panel displayed incorrect information after modifying published photo. Please note that this only occurred when metadata was changed after the photo was published.

MacBook Pro Exposé turns into a sort of vignette

Hi I'm using Snow Leopard and this Expose problem has been bugging me. It hasn't been like that all the time.
After using it for a while, sometimes Expose will result in this (see picture) when I four-finger-swipe downwards. It's like.. just a vignette forming but it doesn't show all the windows, which is what it's meant to do. I tried giving the same command by using the expose key and mouse, and the same thing happens so it's not a track pad problem. If I four-finger-swipe upwards it will disperse this shadow and resume to normal. And if i do that again it will show desktop like it should.
So the only thing that's not happening is showing all the windows. Everything will be okay if I restart my com but the same problem will randomly happen again. I have no clue what triggers this error cos I can be doing nothing and it just suddenly goes wrong.
Any help will be appreciated! Thanks!

Yes, there is. You'll need an Airport Express:
http://support.apple.com/kb/HT4325

Color BUGS with new ATI 2600 HD

People with the new MAC PROs with the ATI 2600HD cards - list your Color bugs here. And solutions if you have them!
Here is what I am seeing:
1. In the Color FX room, if you try to make a VIGNETTE and set the Type to anything other than "0" or "1" you get a graphics bug - basically the vignette goes crazy and creates black lines all over the screen. Both zero and one only give you a circle vignette, and 2 is supposed to give you a square vignette.
2. Also in the Color FX room, trying to get your vignette to track along the path of a tracker seems to fail, and have the vignette move in the opposite direction.
Anyone else seeing this please pipe in - and if you have the same video card please give these a tes on your machine and report if you can reproduce this bug!

Stuart,
http://www.barefeats.com/harper8.html reports that the X1900 will work in the new Mac Pro towers, with one caveat: you must flash the card with the new firmware upgrade in an older, 1st gen Mac Pro.
Zeb

Adobe Photoshop CS2 posterization problem on vignette

I am having a problem with posterization in my image. When I try to vignette my photo (with black) it starts to block up in areas, mostly in the darkest part of the gradient. It ends up not making a smooth transitional gradient and leaves a line where it blocks up. It shows up on the screen as well as on the print. I have a calibrated LaCie CRT 19" monitor, G5 and I am working from digital raw files from a Fuji S2 that are AdobeRGB and also film scans that have done the same thing. What can I do to prevent this? Is it something to do with my G5 or is it the software in Photoshop? If there is any info that left out to help solve the problem please let me know!
G5 Mac OS X (10.4.5)

If it shows up on screen and in print, then issue is with the software.
Adobe has forums. Might try there.
best wishes
David
Remember to mark an response helpful or solved.
It protects the integrity of the board.

Index with "or" clause (BUG still exists?)

The change log for 2.3.10 mentions "Fixed a bug that caused incorrect query plans to be generated for predicates that used the "or" operator in conjunction with indexes [#15328]."
But looks like the Bug still exists.
I am listing the steps to-repro. Let me know if i have missed something (or if the bug needs to be fixed)
DATA
dbxml> openContainer test.dbxml
dbxml> getDocuments
2 documents found
dbxml> print
<node><value>a</value></node>
<node><value>b</value></node>
INDEX (just one string equality index on node "value")
dbxml> listIndexes
Index: unique-node-metadata-equality-string for node {http://www.sleepycat.com/2002/dbxml}:name
Index: node-element-equality-string for node {}:value
2 indexes found.
QUERY
setVerbose 2 2
preload test.dbxml
query 'let $temp := fn:compare("test", "test") = 0
let $results := for $i in collection("test.dbxml")
where ($temp or $i/node[value = ("a")])
return $i
return <out>{$temp}{$results}</out>'
When $temp is true i expected the result set to contain both the records, but that was not the case with the index. It works well when there is no index!
Result WITH INDEX
dbxml> print
<out>true<node><value>a</value></node></out>
Result WITHOUT INDEX
dbxml> print
<out>true<node><value>a</value></node><node><value>b</value></node></out>

Hi Vijay,
This is a completely different bug, relating to predicate expressions that do not examine nodes. Please try the following patch, to see if it fixes this bug for you:
--- dbxml-2.3.10-original/dbxml/src/dbxml/optimizer/QueryPlanGenerator.cpp     2007-04-18 10:05:24.000000000 +0100
+++ dbxml-2.3.10/dbxml/src/dbxml/optimizer/QueryPlanGenerator.cpp     2007-08-08 11:32:10.000000000 +0100
@@ -1566,11 +1572,12 @@
     else if(name == Or::name) {
          UnionQP *unionOp = new (&memMgr_) UnionQP(&memMgr_);
+          result.operation = unionOp;
          for(VectorOfASTNodes::iterator i = args.begin(); i != args.end(); ++i) {
               PathResult ret = generate(*i, ids);
               unionOp->addArg(ret.operation);
+               if(ret.operation == 0) result.operation = 0;
-          result.operation = unionOp;
     // These operators use the presence of the node arguments, not their valueJohn

Bug report follow-up

is there a way to follow-up on a bug report that i submitted? i have the bug number, but would like to see if the report was understood, filled out properly and determine the status of the bug report.
thanks,
doug

They comment on bugs if actions were taken. Otherwise - don't expect any feedback.

Solaris8 and 9 (possibly 7) /dev/poll driver bug report.

Hello,
I'd like to report a bug in the solaris 8 and 9 /dev/poll driver (poll(7d)).
As i do not have a support account with sun or anything like that, there
seems to be no other way to do that here (which is of course a very sad
thing).
Bug details:
The /dev/poll device provides an ioctl-request (DP_ISPOLLED) for checking
if a particular filedescriptor is currently in the set of monitored
filedescriptors for that particular /dev/poll fd set (open /dev/poll fd).
A quote from the documentation of the poll(7d) manual page taken from
Solaris9:
"DP_ISPOLLED ioctl allows you to query if a file descriptor is already in
the monitored set represented by fd. The fd field of the pollfd structure
indicates the file descriptor of interest. The DP_ISPOLLED ioctl returns 1
if the file descriptor is in the set. The events field contains the
currently polled events. The revents field contains 0. The ioctl returns 0
if the file descriptor is not in the set. The pollfd structure pointed by
pfd is not modified. The ioctl returns a -1 if the call fails."
It says that when you query for an filedescriptor which is currently being
monitored in the set, that it would return 1, and change the events field of
the pollfd structure to the events it's currently monitoring that fd for.
The revents field would be set to zero.
However the only thing which actually happens here, is that FD_ISPOLLED
returns 1 when the fd is in the set and 0 if not. When the fd is in the
set, when FD_ISPOLLED returns 1, the events field remains unmodified, but
the revents field gets changed.
A small sample code to illustrate:
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/devpoll.h>
main() {
struct pollfd a;
int dp_fd = open("/dev/poll", O_WRONLY);
a.fd = 0; /* stdin */
a.events = POLLIN; /* we monitor for readability, POLLIN=1 */
a.revents = 0;
write(dp_fd, &a, sizeof(a));
a.fd = 0;
a.events = 34; /* filled in with bogus number to show malfunctioning */
a.revents = 0;
printf("DP_ISPOLLED returns: %d\n", ioctl(dp_fd, DP_ISPOLLED, &a));
printf("a.fd=%d, a.events=%hd, a.revents=%hd\n", a.fd, a.events,
a.revents);
According to the documentation of /dev/poll and namely DP_ISPOLLED this
program is supposed to print the following:
DP_ISPOLLED returns: 1
a.fd=0, a.events=1, a.revents=0
However it prints the following:
DP_ISPOLLED returns: 1
a.fd=0, a.events=34, a.revents=1
You can take any number instead of '34' and it will simply remain untouched
after the DP_ISPOLLED ioctl-request.
I hope it's clear now that the solaris8 and solaris9 (and probably solaris7
with /dev/poll patch too) DP_ISPOLLED implementation is broken.
This bug is also easily illustrated by looking at the solaris8 kernel sourcecode:
<snippet osnet_volume/usr/src/uts/common/io/devpoll.c:dpioctl()>
case DP_ISPOLLED:
pollfd_t pollfd;
polldat_t *pdp;
if (pollfd.fd < 0) {
mutex_exit(&pcp->pc_lock);
break;
pdp = pcache_lookup_fd(pcp, pollfd.fd);
if ((pdp != NULL) && (pdp->pd_fd == pollfd.fd) &&
(pdp->pd_fp != NULL)) {
pollfd.revents = pdp->pd_events;
if (copyout(&pollfd, (caddr_t)arg,
sizeof(pollfd_t))) {
mutex_exit(&pcp->pc_lock);
DP_REFRELE(dpep);
return (set_errno(EFAULT));
*rvalp = 1;
</snippet>
its' clearly visible that the code writes the current monitored events to
the revents field:
'pollfd.revents = pdp->pd_events;'
and that it doesnt set revents to zero.
It's funny to see that this has been like this since Solaris8 (possibly 7). That means nobody ever used DP_ISPOLLED that way or people were simply to lazy to file a bug report.
Another funny thing related to this. is that Hewlett-Packard did seem to know about this. Since HP-UX11i version 1.6 they also support /dev/poll. From their manual page i ll quote some sentences from their WARNING session:
"The ioctl(DP_ISPOLLED) system call also returns its result in the revents member of the pollfd structure, in order to be compatible with the implementation of the /dev/poll driver by some other vendors."
Hopefully this will get fixed.
I also like to reexpress my very negative feelings towards the fact that you're not able to file bug reports when you do not have a support contract. Ridiculous.
Thanks,
bighawk

Have I mentioned how much i love my playbook now Great job on os 2.0

10.0.1 vignette bug

Similar Messages

Maybe you are looking for