Artefacts in JPEGS.

I see ALOT of artifacts in jpegs, if shot in jpeg I see them even inside lightroom, if shot I raw I see the artifacts them I export to jpeg. I gives a strange "shadow" or extra line around every straight line in the picture. Is looks ugly. http://uu.pean.org/junk/jpegmek.png This is a screenshot of lightroom zoomed in on a jpeg 1:1. The exact same thing shows up on exported (to jpeg) raw-files.
I cant use pictures from lightroom in print because if this.

Two causes for this.
I. too much highlight recovery or too much shadow fill. You would see this on the screen already in the RAW file zoomed 1:1. The solution is simply too back off on those a little.
II. There is a bad scaling algorithm used in Lightroom. It can lead to ghost lines on high contrast edges. See these links:
http://lagemaat.blogspot.com/2008/08/resize-artefacts.html
http://lagemaat.blogspot.com/2008/08/lightroom-artefacts-even-show-up-when.html

Similar Messages

Hello! Why are there staircase-shaped artefacts with jpegs in Lightroom (invisible in other programmes)?

Hello! Why are there ugly staircase-shaped artefacts with jpegs in Lightroom? They're mostly on edges of red subjects and I can't find them in other programmes or software...

If you have the photos on your camera cards, then obviously you can simply copy them to the appropriate locations.
There are Lightroom plug-ins that can retrieve the preview that Lightroom uses, but these will be smaller and lower in quality than the original. Maybe one of our plug-in experts can suggest the proper plug-in.
If the hard disk is really going bad, as I speculated, you would definitely want to get it replaced. If that is the case, you don't want to keep using it. You might want to run some disk diagnostics on it.

Exported JPEGs Distorted in Shadow Areas

I own a Nikon D7000 and I shoot 14bit RAW.
In Lightroom 3.3 the preview images were distorted, only in development mode the images were fine. I reported to Adobe on this and they seem to have fixed this issue.
In Lightroom 3.3 -- and still in 3.4 -- the exported JPEGs are distorted when the exported image is resized:
A lighter version of the same crop (for illustrative reasons):
As you can see, the gradient has serious artefacts, especially when going from green to black. It is a 90% JPEG quality exported of 1050px width. I have seen this for different image qualities (80-100%), though. This does not occur when the image is exported full size.
Can anybody confirm this?
It seems that this only happens for dark shadows.
I had a Canon G9 that I used with Lightroom and I have never seen a behaviour like this. Right now the export is useless to me.

I've had some discussions about this with Adobe folks during the LR 3 beta phase, but that is all behind a wall now. I think they did put in the dithering into Lightroom now. I still think it is your monitor profile. Also realize that the displays in laptops including the MacBook Pros are not actually full 8-bit displays and you will always see some banding in them. See for example this page: http://www.lagom.nl/lcd-test/gradient.php My guess is that that will show banding on your machine in the shadow areas. Also another issue is that you have to look at these displays at precisely the right angle because you will get raised shadows by quite a bit if you look at them just a few degrees off. One thing to do is to use a test image ( I use monitor_test_txt22.png from this page: http://www.normankoren.com/makingfineprints1A.html ). When you squint the image should be uniform. If not slant the display until it looks uniform.

Help, i am trying to print my JPEG file that i created in photoshop at a photo lab but it is coming out like an X-ray. I have printed these files before so i have no idea what i am doing wrong.

Help, i am trying to print my JPEG file that i created in photoshop at a photo lab but it is coming out like an X-ray. I have printed these files before so i have no idea what i am doing wrong.
Could it be something i have done in my settings?
or when i am saving the file to JPEG?

Basically you're approaching this the wrong way around. What you need is the extreme sections to be quieter, not louder. The problem with moving the lower end of the audio is that you'll move the noise floor too, and get what's generally referred to as a 'pumping' effect. So what you do is to use a compressor to tame the peaks, and leave the lower level sound alone. When you've done that, you amplify (or normalize to a level you can determine) the whole signal. So the noise floor will be higher, but constant and not pumping. 'Match Volume' is a completely different tool for setting the overall levels of different tracks so that they sound approximately the same - it doesn't even begin to do what you want.
If it's music you are treating, then I'd almost certainly use the multiband compressor, because you get less artefacts with this. You need to experiment with the threshold levels, and almost certainly not use a massive compression ratio - 3:1 or 4:1 should be sufficient (although it's hard to tell without actually hearing the audio). You can tell what it's doing at any given point because the downward meter indicates how hard it's working. In theory you can apply make-up gain with it as well, but personally I leave that until everything's treated and use the 'Normalize' tool to set an absolute max level.

Edit "JPEG" then "Save As" is destructive ????

Having searched around I can't find an answer to a simple question. If I open a jpeg and edit it "with or without" layers, then flatten (In the case of layers) the image and select the "Save As" command and rename the file or select "As A Copy", will my original jpeg suffer from and adverse effects if I don't save the original file ???. I keep hearing about destructive editing and layers etc. I have tried editing the same photo three times without saving the original and the file size is the same, suggesting that its non destructive, but would like a definitive answer. Thanks in advance

Noel Carboni wrote:
Generally speaking, saving as a JPEG causes a lossy compression of the data. So as a rule, any save of a JPEG file results in degradation.
If you talk about Photoshop only, then yes. But "generally speaking": no, this is not universally true.
There are a number of modifications that CAN be done losslessly on a JPEG file (i.e. without decompressing and recompressing the data, thereby preventing a reduction of image quality due to generation loss):
rotating (lossless)
flipping (lossless)
cropping (lossless)
canvas enlarging, i.e. adding a frame (lossless)
grayscaling (lossless except for the [intended] loss of chroma information, i.e. the operation does not add jpeg compression artefacts and thus is equal to converting a color image to a grayscale image in lossless format, such as png)
editing (lossless re-saving of entire jpg image except modified MCU blocks. This comes in handy e.g. for red-eye reduction!)
MCU block rotating, flipping and moving (lossless)
Many programs are capable of lossless rotating and flipping of jpeg files, whereas the other lossless operations are less frequently found.
Photoshop is NOT capable of any of the above lossless operations.
modifications which do not change image pixels:
optimizing the Huffman tables of a JPEG file to increase compression (lossless)
converting between progressive and non-progressive JPEG format (lossless)
Note: Lossless rotating and flipping requires the image size to be a multiple of 1 MCU block (i.e. 8x8 for a jpeg image without chroma subsampling, 16×8 for 4:2:2 subsampling and 16×16 for 4:2:0) as the top and left edge of a JPEG image must lie on a block boundary. When a losslessly cropped JPEG image's bottom or right side does not coincide with a block boundary, then the rest of the data from the partially used blocks will still be present in the cropped file and can be recovered.
lossless editing (e.g. adding of text):
1) original JPEG image
2) edited + losslessly resaved JPEG image
3) comparison
white: identical pixels
black: different pixels
lossy editing in Photoshop (e.g. adding fo text):
1) original JPEG image
2) edited + saved in Photoshop
(JPEG, max. quality 12)
3) comparison
white: identical pixels
black: different pixels

Bridge has started to destroy our JPEGs; known problem?

Hi,
half an hour ago something - possibly Bridge - has obviously started to destroy our JPEGs. We first noticed strange artefacts in the Bridge previews; then we were shocked when we discovered that the files themselves were altered (without changing the modification date of the file). We checked this by connecting the external drive that contains the files to another computer: It's not a problem with the previews, the files themselves are destroyed. (On this other computer GIMP gives the error "Corrupt JPEG data: 3841 extraneous bytes before marker 0xd9" when opening the file I've attached to this post.)
Fortunately the NEF files are unaltered. A check of the hard drive shows no problems.
We're not 100% shure that Bridge is causing this - but since Bridge was the only program open at the time and since the problem developed while using Bridge it seems very probable to us that Bridge is involved in this phenomenon.
Did you observe anything similar? Is this a known problem? We didn't find anything when searching Google or this forum.
Thanks for your help!
(We're using Adobe Bridge CS5 4.0.5.11 on an iMac with Mac OS X 10.7.5)

- mainly (only? I don't know exactly) files are affected where we added metadata;
The clue about no change in modification date in the first post would mean you did not alter the files. However this changes things because you seem to have done so.
In normal use while adding metadata or rename the file needs to be saved again to apply the changes. While doing so Bridge updates the thumbs and previews to reflect the new situation.
If this save action would be the cause of the destroyed jpegs they should have shown so immediate after applying the changes. But yes, we all are in a hurry and have a short memory
If you have pointed Bridge to another folder while the save was still in progress then you would not notice it but also the cache is not likely to rebuild until you point Bridge again to the folder.
The moment you point Bridge to that folder first the thumb rebuilds and then the preview to reflect the changes. Because the modification date did not change to the date you saw the changes happening it is likely the problem has been caused before but you have not noticed earlier until you pointed Bridge to this folder which started the recaching of the files (only modification of the cache file, not the original jpeg) to reflect the new situation.
Don't use Gimp myself but a jpeg is a jpeg and an international standard so they both should be able to read and write correct files.
Therefor it stays a strange problem and you should back up your files frequently in case this starts happen again. If it is a one off we keep wondering what it might have been but if it repeats I would first suspect the disk (running a health scan is not always pointing to other problems like correct read write permissions and also folders can get corrupted for strange reasons).
BTW, I never have been a fan of RAID, to expensive and to much space needed. A simple back up scheme with different disks has always done the trick for me.

How do i convert raw to jpeg in aperture

How do I convert raw to jpeg in Aperture 3 ?

I find all this rather strange! I often convert RAW to Jpeg if I want to keep an image for reference but it doesn't merit or require the 8 to 10MB of the RAW file (on my computer, my external drive, or anywhere else). For example, I take photos of artefacts in museums, and I also photograph the labels/legends beside them, for reference. I can keep those solely as quite small Jpegs since I'm never going to want to print them.
(No, I don't want to switch settings on the camera while I do this - I'll only forget to switch back, and then have loads of low-res Jpegs that were meant to be glorious RAW).
In other software I've used, there's a batch convert that makes this very simple. Seems that in Aperture I'm obliged to export and then re-import. Not a big deal, but a slight pain in the arse all the same, and a little odd.
Anyway, thanks to the above posts, I now know how to do the export-import malarkey. I couldn't find it in the manual.
cheers,
Helen

How to save JPEGs with a clean matte?

From a cut-out image on a transparent background, I use Save for web specifying a black matte to create a JPEG. The resulting image has compression artefacts within the black matte around the image just the same as if the original image had a black background. I can then apply a mask channel copied from the orignal file to the JPEG and fill the matte with black. Delete the mask and Save and I have a JPEG with a matte free of artefacts.
Is there a simple way to achieve the same thing and what's the point of the matte option?

I am currently using .png files with transparent backgrounds and dropshadows. These are significantly larger (2x or 3x) than the equivalent .jpg files so the site loading time is also much longer but, of course, .jpgs don't allow transparency. My sites are in Flash which, via ActionScript, allows me to apply drop shadows at runtime to transparent images. It also allows me to create a transparent bitmap image from a .jpg by setting to transparent all pixels that have the matte colour. Unfortunately, as I described above, not all the pixels in the matte area will retain the matte colour because of the way the JPEG compression is done. As a result, the cut out image created by ActionScript will not have clean edges. I can fix this by the second operation on the .jpg I've described but this process is not easily automated in an Action and one site in particular involves a lot of images!

Convert psd to jpeg

Dag,
Het omzetten van een groot PSD bestand naar een JPEG bestand gaat bij mij niet goed. Het bestand is zo'n 650mb groot, na omzetting blijft er maar zo'n 40mb en een wazige afbeelding over. Dit ondanks dat ik aangeef een maximale grote wil behouden (12). Heeft iemand een idee hoe het mogelijik is om van die 650mb psd een jpeg te maken van ongeveer 200-250mb?
Alvast hartelijk dank,
Johan

JPEG is a visually lossy compression and even at the best quality setting there will be artefacts. Your file will never become bigger, because the algorithm already is at its optimum. So far nothing is wrong here and even if it were technically possible, a larger file wouldn't necessarily mean better quality. If that's an issue, you simply need to use a different image format like a compressed TIFF to send your file out e.g. to a print facility.
Mylenium

Weird graphical artefacts -- black squares

Hi all,
I've got this weird graphics artefact that I sometimes see on my MBPro17. It's hard to describe, so I made a screenshot:
http://jfouhy.googlepages.com/mac-graphics-bug.jpg
(ignore the slight fuzzyness; that's just jpeg compression)
In this case, the boxes are black, but they're often red, or sometimes other colours. It only happens when I'm getting the graphics card to do something "difficult", eg expose with 100+ windows, 3d application (particularly if the 3d app doesn't have focus).
Anyone seen this before, or know what to do?

Yay artifacts rule
Through my experiences with artifacts I found out that it was a faulty graphics card. This was on a windows machine, so it could be a whole nother ball park with a Mac.
So maybe call Apple or go into an Apple Store and see what they can do fer ya

JPEG and color management

Hi. Is it impossible to get 100% identical colors (if we leave aside the jpeg compression artefacts) when saving a .jpeg file with Photoshop using the highest quality setting (12) ?

Thanks for helping in this test despite hating JPEGs
Your screenshots proves that there are differences not only along hard edges (i.e. the borders between color patches), but that also whole color patches are affected.
This would mean, that color management isn't working properly with jpeg files. I hope someone with sound color management knowledge can confirm this or otherwise explain the problem.
> When using the Magic Wand (which I confess I don't understand what that is supposed to prove)
I try to explain once again:
1) Download the original source file (png) from the link above
2) open it in Photoshop and assign sRGB profile
3) save it as jpeg with highest quality settings possible (12)
4) open the jpeg file
5) add it as new layer over the png file
6) select "difference" as blending mode in the layers palette
7) now the whole image should appear almost black
7) select the magic wand tool (with abovementioned settings!)
8] click somewhere into the formerly gray area
explanation: you just selected all completely black pixels (0,0,0) i.e. all pixels that are identical in both layers
9) you should see "marching ants" forming rectangular patterns
10) invert the selection (Shift+i)
explanation: the selection now covers all the other pixels, i.e. all pixels which are different between both layers
11) create a new empty layer and select it in the layers palette
11) set the foreground color to white
12) fill the selection with white (alt+backspace on Windows, accordingly on Mac)
13) set the blending modes of all layers back to normal
explanation: you now have the image I posted above, i.e. you see all identical pixels in their respective color and all different pixels in white
The expected results would be white pixels along the borders between color patches, resulting from jpeg compression, but if color management works correctly there must not be entire color patches with the wrong color (i.e. white here)

Audio Artefacts / Freeze Frames post-Onlining?

Hi all,
Am experiencing some issues with my captured clips in FCP... might not be an FCP or hardware problem, but would like some advice.
1) Recently, I've noticed that audio artefacts have been appearing in the audio of clips I've captured [DV footage from a DV camera, shot on new Sony MiniDV tapes, through a Firewire 400, sometimes using the same camera that shot the footage, through 'Offline Photo JPEG' and also 'DV25PAL']. There will be the occasional but noticeable 1 or 2 frames of audio distortion, whereas the rest of the audio is perfectly fine.
Incidentally, I've just finished reading 'Optimizing Your Final Cut System' from the Apple Pro series of training books - really useful stuff - and their audio troubleshooting section doesn't help in my situation.
It's not a settings problem - it was shot on 48kHz, 16 bit and captured as such. I've listened to the source tape - it's clean. The sequence is set for 48kHz and 16bit [plus, apart from the very random audio kink, the rest of the audio is fine].
I've tried recapturing the offending clips but the audio distortion will just occur in another section instead. Hmmm...
The only suspicion I have now is that the Firewire cable is wonky. Do you guys have any other suggestions? And if it's a Firewire issue [mine's a regular $10 cable bought from an electronics store] - any tips on picking a reliable Firewire cable?
2) A little question on smooth onlining [Ken Stone's website has done a good job of providing the tips and tricks... but there's just one thing I'm still curious about...] I realized that if I online using the process detailed here: http://www.kenstone.net/fcphomepage/basic_onliningjordan.html , I still face problems with freeze frames that I'd made - the corresponding footage that the freeze frame was taken from wasn't automatically selected and up-rezed by Media Manager.
Apart from going back and capturing the freeze frame footage manually or bringing it out to Photoshop and then bringing it in again, is there anything else I can do when preparing my offline sequence for online?
I'm currently editing with FCP 5.1.1 on a Powerbook G4.
Powerbook G4 Mac OS X (10.4.7) Final Cut Pro 5.1.1

ON the audio issue: are you finding the problem with a single track or do you have multiple audio tracks? I've seen some problems that were eliminated by "mixdown" of audio tracks in a project.
If video is fine and audio is not, the cable is not a good suspect - general data corruption would be in both, I think. It's possibly an RT problem; maybe your system is too slow?
Just some ideas.

Firefox mobile excessively compresses JPEG

I have Firefox Mobile 16.0.2 installed on my Asus tablet (Android ICS, 4.0).
The images are rendered with excessive JPEG compression, resulting in compression artefacts, like non-smooth gradients, blurs, etc.
I compared it to Chrome browser and Dolphin HD, where the same images show fine.
NB: I'm using my home wifi, and it is definitely not an issue of ISP compression.
Any idea why, and how I can fix that?

ok, I fixed the flash plugin problem, but still mov files crash my firefox and I get this message in the terminal:
http-on-examine-response [Exception... "Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsIInterfaceRequestor.getInterface]" nsresult: "0x80004002 (NS_NOINTERFACE)" location: "JS frame :: file:///home/ludovico/.mozilla/firefox/ccctda6r.default/extensions/%7B19503e42-ca3c-4c27-b1e2-9cdb2170ee34%7D/components/flashgotService.js :: anonymous :: line 2483" data: no] -- http://movies.apple.com/trailers/univer … s/480p.mov, video/quicktime
process 10527: arguments to dbus_connection_get_data() were incorrect, assertion "connection != NULL" failed in file dbus-connection.c line 5758.
This is normally a bug in some application using the D-Bus library.
D-Bus not built with -rdynamic so unable to print a backtrace
Aborted

Image is not saved in jpeg/bmp file but ok with png

Hi i am unable to save the image in disk in jpeg format.
Here is the code.
public void saveImage(){
//if no filechooser is there means no image file opened.
        if(fileChooser==null){
            if(errorWindow==null)
                errorWindow=new ErrorWindow(XXX.getPrimaryStage());
            errorWindow.showErrorWindow("There is no image to save !!\n");
        else{
            fileChooser.setTitle("Save The Image");
            File saveFile=fileChooser.showSaveDialog(XXX.getPrimaryStage());
            if(saveFile!=null){
                System.out.println("saveFile path= "+saveFile);
                //get the extension of output image to be saved.
                //XXX: is the main class name(say)
                outExtension=*XXX*.getImageExtension(saveFile);
                //if user does not give extension: set default extension as jpg
                if(outExtension.equalsIgnoreCase(saveFile.getName())){
                    outExtension="jpg";
                    String newPath=(saveFile.toString())+".jpg";
                    saveFile=new File(newPath);
                Task task = new Task<Void>() {
                    @Override
                    public Void call() {
                        Platform.runLater(
                                new Runnable() {
                                    public void run() {
                                        try {
                                            //The image is inside ImageView->inside ScrollPane-> inside TabPane.
                                            Image curImage=XXX.getCurrentImage();
                                            int width=(int)curImage.getWidth();
                                            int height=(int)curImage.getHeight();
                                            System.out.println("cur image width= "+width+" ht= "+height);
                                            bufferedImage=new BufferedImage(width, height,BufferedImage.TYPE_INT_ARGB );
                                            //set the current image to awt Buffered Image
                                            SwingFXUtils.fromFXImage(curImage, bufferedImage);
                                                imageTabPane=xxx.getImageTabPane();
                                                Tab tab=imageTabPane.getSelectionModel().getSelectedItem();
                                                TabPane childTabPane=(TabPane)tab.getContent();
                                                ScrollPane sp=(ScrollPane)childTabPane.getSelectionModel().getSelectedItem().getContent();
                                                final ImageView imageView=(ImageView)sp.getContent();
                                                WritableImage wim = new WritableImage(width,height);
                                                imageView.snapshot(null, wim);
                                                System.out.println(" snapShot width= "+wim.getWidth()+" ht="+wim.getHeight());
                                                *ImageIO.write(SwingFXUtils.fromFXImage(wim,null), outExtension, saveFile);*
                                                   //<------ its not working for png,jpeg,bmp,gif
                                                // the below lines are working only for png and gif
                                                OutputStream out = new FileOutputStream(saveFile);
                                                ImageIO.write((RenderedImage) bufferedImage, outExtension, out);
                                                out.flush();
                                        } catch (Exception ex) {
                                            Logger.getLogger(FileMenuController.class.getName()).log(Level.SEVERE, null, ex);
                                            //ex.printStackTrace();
                                        System.out.println("finished");
                        return null;
                Thread th = new Thread(task);
                th.start();
            }else{
                System.out.println("File is not saved");
    }//saveImageNote: The above code is executed in ubuntu(10.04) using Netbeans 7.2(Javafx(2.2), java(1.7.0_11).
When i run(from terminal) separately in a new class with an image in an Imageview( inside a Vbox) and take the snapshot
of the imageview and write into the file using ImageIO.write(SwingFXUtils.fromFXImage(wim,null), outExtension, saveFile);
with any extension (jpeg,png etc) it is working fine.
Please help me.
Any small hint is also helpful.Please feel free to comment or give suggestion.
Edited by: 963038 on Feb 17, 2013 7:14 PM

When i omit the line OutputStream out = new FileOutputStream(saveFile);
and write only
ImageIO.write((RenderedImage) bufferedImage, outExtension,saveFile);
//out.flush();
then saving the image even in "png" also fails.
The following is the error code:
Note : FileMenuController is my file where the saveImage() is wrtten.
javax.imageio.IIOException: I/O error writing PNG file!
finished
     at com.sun.imageio.plugins.png.PNGImageWriter.write(PNGImageWriter.java:1168)
     at javax.imageio.ImageWriter.write(ImageWriter.java:615)
     at javax.imageio.ImageIO.doWrite(ImageIO.java:1612)
     at javax.imageio.ImageIO.write(ImageIO.java:1536)
     at *newciptk.controls.menu.file.FileMenuController$1$1.run(FileMenuController.java:205)*
     at com.sun.javafx.application.PlatformImpl$4.run(PlatformImpl.java:173)
     at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:76)
     at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method)
     at com.sun.glass.ui.gtk.GtkApplication$3$1.run(GtkApplication.java:82)
     at java.lang.Thread.run(Thread.java:722)
Caused by: java.io.IOException: Operation not supported
     at java.io.RandomAccessFile.writeBytes(Native Method)
     at java.io.RandomAccessFile.write(RandomAccessFile.java:499)
     at javax.imageio.stream.FileImageOutputStream.write(FileImageOutputStream.java:124)
     at javax.imageio.stream.ImageOutputStreamImpl.writeInt(ImageOutputStreamImpl.java:91)
     at com.sun.imageio.plugins.png.ChunkStream.finish(PNGImageWriter.java:136)
     at com.sun.imageio.plugins.png.PNGImageWriter.write_IHDR(PNGImageWriter.java:401)
     at com.sun.imageio.plugins.png.PNGImageWriter.write(PNGImageWriter.java:1135)
     ... 9 more
javax.imageio.IIOException: I/O error writing PNG file!
     at com.sun.imageio.plugins.png.PNGImageWriter.write(PNGImageWriter.java:1168)
     at javax.imageio.ImageWriter.write(ImageWriter.java:615)
     at javax.imageio.ImageIO.doWrite(ImageIO.java:1612)
     at javax.imageio.ImageIO.write(ImageIO.java:1536)
     at newciptk.controls.menu.file.FileMenuController$1$1.run(FileMenuController.java:205)
     at com.sun.javafx.application.PlatformImpl$4.run(PlatformImpl.java:173)
     at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:76)
     at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method)
     at com.sun.glass.ui.gtk.GtkApplication$3$1.run(GtkApplication.java:82)
     at java.lang.Thread.run(Thread.java:722)
Caused by: java.io.IOException: Operation not supported
     at java.io.RandomAccessFile.writeBytes(Native Method)
     at java.io.RandomAccessFile.write(RandomAccessFile.java:499)
     at javax.imageio.stream.FileImageOutputStream.write(FileImageOutputStream.java:124)
     at javax.imageio.stream.ImageOutputStreamImpl.writeInt(ImageOutputStreamImpl.java:91)
     at com.sun.imageio.plugins.png.ChunkStream.finish(PNGImageWriter.java:136)
     at com.sun.imageio.plugins.png.PNGImageWriter.write_IHDR(PNGImageWriter.java:401)
     at com.sun.imageio.plugins.png.PNGImageWriter.write(PNGImageWriter.java:1135)
     ... 9 more

Weird artefacts in view window & QT

Hi all,
I'm wondering if anyone can shed some light on this, or have experienced it. Since upgrading to Leopard, Final Cut occasionally displays some crazy artefacts in the viewer window, usually when pressing 'f' for match frame. I've also noticed it a couple of times when exporting from QT, the window displays nonsense. I've posted a link to a screen shot:
http://www.alboardman.co.uk/image

I can just hear the narration now....
"When expecting heavy weather, it is advisable to pay special attention to securing the rain fly. I always use the super peg from Cotswolds Outfitters..."
I've never seen that other stuff, looks spooky. What happens when you trash the preferences? Any relief?

Artefacts in JPEGS.

Similar Messages

Maybe you are looking for