No jpeg compression in iphoto6?

There is no compression in iphoto 6 correct?
I don't understand why Apple would leave that feature out of a photo app.
I have found that I can open up a jpeg and go to file...save as...and decrease the quality and that helps but I would sometimes like to squash a jpeg to 60kb and I can't figure out how to do this on my mac with iphoto6.

James: If you're referring to keeping the image size the same but reducing the file size then you'll need a 3rd party application that can vary the quality (compression). Resize! and freePhotoConverter 2 are two that can do it. iPhoto can resize the image, pixel dimensions, by exporting and selecting the height and width desired.

Similar Messages

Is there any way to reduce the JPEG compression ap...

I'm wondering if there is any way to reduce the fierce amount of JPEG compression applied to photos taken with the 6220 classic? I'm 99.99% sure that there isn't, but I thought I'd ask anyway.
I'm a professional graphic designer with 15 years experience, and as such understand the technicalities of digital imaging better than most.
What the general public fails to understand is that ever higher megapixelage doesn't automatically equate to ever higher quality images.
The 6220 classic has a 5MP camera, which is one of the reasons I bought it, along with the fact that it has a Xenon flash and a proper lens cover. Its imaging quality also generally gets very positive reviews online.
However, the 6220 classic takes far poorer photos than my 5 year old Olympus digital camera which only shoots 4MP. Why is this? Many reasons. The Olympus has a much larger imaging chip, onto which the image is recorded (physical size as opposed to pixel dimensions), a far superior lens (physical size & quality of materials), optical (not digital) zoom, and the ability to set various levels of JPEG compression, from fierce (high compression, small files, low quality images) to none at all (no compression, large files, high quality TIFF-encoded images).
When I first used the camera on the 6220 classic (I've never owned a camera phone before) I was appalled at the miniscule file sizes. A 2592 x 1944 pixel image squashed into a few hundred kilobytes makes a mockery of having decent pixel dimensions in the first place, but then the average consumer neither cares about nor would notice the difference. They're not going to be examining & working on their images in Photoshop on a 30" Apple Cinema Display.
Is fierce JPEG compression (and an inability to alter it) the norm with camera phones, or do other camera phones (perhaps from other manufacturers) allow greater latitude in how images are compressed?
Thanks.
Solved!
Go to Solution.

Believe me, I was very aware that this was a phone with a camera attached, not a dedicated camera, before I bought it. I went into this with my eyes open. I knew the lens, imaging chip, zoom, etc, would all be grossly inferior, but given all of this, surely the phone manufacturers should help to compensate for this by adding a few lines of code to the software to reduce (or ideally remove) the JPEG compression, or at least give the user the option to do so if they want? The fierce compression just makes images obtained with compromised hardware even worse than they would have been otherwise.
It adds insult to injury and is totally unnecessary, especially given that the memory card in the 6200 classic is 1GB but the one in my Olympus is only 128 MB! It's not as if lack of storage space is an issue! On the Olympus I can only take about 8 pictures without compression (although I could obviously buy a much larger memory card). On the 6220 classic, given the ridiculous amount of compression, there's room for over 1200 photos! It would be far better to let 70 uncompressed images be stored than 1200 compressed ones. Does anyone seriously need to take over a thousand photos on a camera phone without having access to a computer to offload them? I doubt it.
Also, compressing the images requires processing power, which equals time. If they were saved uncompressed, the recovery time between shots would be reduced, although obviously writing the larger files to memory may offset this somewhat.
Just to give people an idea, an uncompressed 8-bit RGB TIFF with pixel dimensions of 2592 x 1944 takes up approximately 14.5 MB of space. (The exact number of bytes varies slightly depending on the header information stored with the file). The 3 photos I've taken so far with the 6220 classic (and that I've decided to actually keep) have files sizes of 623, 676 & 818 KB respectively. An average of these 3 sizes is 706 KB. 706 KB is less than 5% the size of 14.5 MB, which means that, on average, the camera, after is records the 5038848 pixels in an image, throws over 95% of them away.
I'm deeply unimpressed.

LR JPEG compression vs. Photoshop JPEG compression

I haven't found any documentation of the meaning of the 0 - 100% JPEG compression value in LR's (v1 or v2) Export File window. And the default value of 100% is overkill and results in huge files. At least I'm familiar with the Photoshop's 0-12 JPEG quality scale with associated quality names: Low, Medium, High, and Maximum.
Via trial and error, I have found that LR has the same 13 quality levels as Photoshop and gives the same results, they are just mapped on a 0 - 100% scale. This also means that changing a few percent may not make any change at all, since a quality change only happens about every 7 percent.
For those who might find it useful, here is a table of the mappings:
The first column is the Photoshop compression number and name; the second column in the range of Lightroom percentages that will give the same results.
0-Low 0-7%
1-Low 8-15%
2-Low 16-23%
3-Low 24-30%
4-Low 31-38%
5-Med 39-46%
6-Med 47-53%
7-Med 54-61%
8-High 62-69%
9-High 70-76%
10-Max 77-84%
11-Max 85-91%
12-Max 92-100%

I looked at this again using PS's 'Baseline Standard' JPEG format option instead of 'Baseline Optimized. LR does not provide the format options Standard, Optimized, and Progressive, but appears to use 'Baseline Standard.' The equivalent compression level LR file size is within 16KB of PS's file size, which is probably due to slight differences in in the file metadata.
This pretty much confirms LR and PS use the same 'Baseline Standard' JPEG compression algorithms. The PS level 7 reduced quality is also seen at LR's level 54-61 JPEG Quality setting. Jeffrey Friedel mentions this in his analysis of LR's JPEG Quality settings and a reply from Brian Tao:
http://regex.info/blog/lightroom-goodies/jpeg-quality
Jeffrey Friedel's comment:
One thing I find interesting (but don't understand) is that in the first example, the difference in file size between the 47〜53 quality and 54〜61 quality is considerable (49k to 66k bytes), while in the second example, the the same two levels of quality produces essentially the same file size. There seems to be some kind of switch in compression algorithm once Lightroom is at a quality setting of 54 or above that puts the emphasis on encoding the easily-discernible smooth gradients of the sunset example, and if they are lacking in the image, as with the reed-window-shade example, the attempt at extra quality fails, and the file size does not increase. That's my guess, but it's just a guess.
Brian Tao's Reply:
This is due to the downsampling (basically, a reduction in resolution) of one or more of the image channels before passing it to the actual compression routine. Human vision is much more sensitive to changes in luminance (brightness) than chrominance (colour). JPEG takes advantage of this by reducing the amount of colour information stored in the image in order to achieve higher compression ratios. Because it is colour and not brightness that is sacrificed, this is called “chroma subsampling”. Look up that term in Wikipedia for a far better and more detailed description than I can provide here.
In a nutshell, Adobe products will use either a 4:4:4 subsampling (which is no subsampling at all, and thus full resolution) or 4:2:0 subsampling (both red and blue channels are reduced to one-quarter resolution before compression). There is no switch to specify the amount of subsampling to use. In Photoshop, the change from 4:2:0 to 4:4:4 happens between quality 6 and 7. In Photoshop’s Save For Web, it happens between quality 50 and 51. In Lightroom, you already noticed that something unexpected happens between 47-53 quality and 54-61 quality. Guess what levels those correspond to in Photoshop? 6 and 7… exactly as expected.
You can very easily demonstrate this by creating a worst-case scenario of JPEG chroma subsampling. Create a small image in Photoshop with a pure blue (RGB = 0,0,255) background. Now type in some pure red text (RGB = 255,0,0). For maximum effect, turn off anti-aliasing, so each pixel is either full on red or full on blue. Zoom in to 500% or so for a clear view of the pixels. Now save the image as a JPEG. With the JPEG quality dialog visible, you will see a real-time preview of the effects of JPEG compression. Start at 12, and work your way down to 0, one step at a time. Watch what happens when you go from 7 to 6. You can do the same with Save For Web and with Lightroom to confirm where they switch from 4:4:4 to 4:2:0.
The file size discrepancy is more noticeable in the sunset shot because most of the information (relatively speaking) is needed to encode the gradual change in chrominance values. There is virtually no luminance detail to worry about, except around the silhouette of the bird. But in the photo of the reed window shades, the fine detail and texture and lack of colour result in practically no difference going from 4:4:4 and 4:2:0.
Because of this hidden (and inaccessble) switch, I have been recommending that to be safe, one should never go below quality 7 in Photoshop, or 51 in Save For Web. In Lightroom, this corresponds to quality 54.
Hope this helps.

What jpeg compression does image capture use to save an image

I am about to scan colour positive slides from many years ago, using image capture and a scanner (Epson 2450 photo). Can anyone tell me what jpeg compression is used when the scan is saved to disk? Further, is there any way to alter the quality of suh compression, from say, medium, to highest?

You might be able to find it when you export it from Image Capture.

N8: Missing JPEG compression settings and gallery ...

1) Where's the use of a fine 12 MP camera if a harsh JPEG compression algorith destroys almost all photos taken ?
PLEASE introduce a setting for adjusting the compression strength.
I know there are solutions available already - but these only work with flashing the phone.
2) After updating some social network software the button for opening the gallery (right after taking a photo) vanished - and now shows an icon for uploading the photo instead of opening the gallery. ARGH ! - Even deinstalling that update did not bring the gallery button back. I now curse myself (and Nokia) for installing that senseless update.
That gallery button was such a nice workaround for checking the quality of a photo taken:
That instant photo display after shooting does not allow zooming - so it's of no use because you cannot check the quality; without zooming in, you cannot see if a picture taken was out of focus or blurred by hands shaking.
So PLEASE: Restore the gallery button OR lets us zoom a photo taken right after shooting.
It's of no use instantly uploading a picture to social networks if you can't check if the quality is sufficient.

Hape: There are always people who like everything. There are even people who like getting slapped in the face. So this shouldn't be an excuse for every nonsense possible.
The problem: That new button is just useless because you wouldn't upload a picture prior to knowing if it really is of the quality needed: On the N8s small screen, even blurred or out-of-focus pictures look ok. You'll only see the differences after zooming in.
But you CAN'T zoom in using the quick view feature right after taking the photo - you need to open the picture taken using the gallery.
Of course you may open the gallery via the menu - but you need to scroll down for finding the right menu entry. Takes unnecessary time and is a source of error.
A QUICK review should be a QUICK review - you don't want to miss the next photo opportunity just because you waste your time fiddling with the menu entries just because Nokia destroyed a working system by introducing a button which is of no use if you cannot check the photo's quality prior to using it.
And again: Why doesn't deinstalling restore the previous state ? - As said: I deinstalled that senseless update - but that ugly button is still there.
So again:
PLEASE, Nokia: Remove that senseless button OR let us zoom photos in quick view.

Some of Photo (JPEG)-compressed images by Flash Pro are not shown in AIR app (3.7/3.8)

Does anyone see this issue happening? In Flash Pro it's OK, but in AIR, it's broken.
https://bugbase.adobe.com/index.cfm?event=bug&id=3558175
Problem Description:
Some JPEG-compressed images in swc produced by Flash Pro CS6 is not shown in AIR.
Steps to Reproduce:
1. Create a fla with Flash Pro CS6
2. Put a png image in it and open the property of the image to make sure its compression option is Photo (JPEG)
3. Produce an swc out of the fla
4. Create an AIR app that shows the contents in the swc
Actual Result:
All images are shown
Expected Result:
Some of the images are not shown (nothing is shown where they are supposed to be)
Any Workarounds:
Use Lossless (PNG/GIF) for all images

i was able to get it to work from a suggestion in another thread: if you write a JSFL that goes through all your bitmaps and makes sure they do not uset he default compression of the document, but instead use custom compression (it can match the default however). this worked for me

Large .jpeg compression/artifacts?

I'm struggling with Muse's jpg compression, which I can't seem to bypass. I'm uploading very large images (2560px wide) for full-screen slideshows which have been optimized for the web in Photoshop. These images have large light backgrounds and hence Muse's jpg compression produces noticeably artifacted areas. I want to make sure it is indeed Muse that's the problem, and not Chrome. I'm previewing these locally. Thanks.

First, I have to say the delta between the screenshots is extremely small. I've had multiple people drop into my office for other reasons and none could see differences without me pointing them out using a pixel magnifying tool.
That said, here are some thoughts regarding this specific case.
Given this appears to be a photograph of black and white line art, it's a very problematic case for JPEG compression. To get a high quality result for this specific use case you'd want to start with a Camera RAW image from the camera (to avoid the camera introducing JPEG compression artifacts) and then go directly to a lossless image format such as PNG or GIF, rather than JPEG. For this specific subject matter going from Camera RAW directly to PNG/GIF would provide the best result, but at the cost of page load speed since the PNG/GIF image will likely be several times larger than a JPEG.
I expect what's occurred in this case is that the original image was a JPEG from a camera that was resized smaller and then re-encoded as JPEG.
The encoding as JPEG in the camera would introduce some artifacts but due to the very high resolution image the artifacts would be very small. Then the image was resized smaller. Resizing alters the image by using one of any number of algorithms to combine/average a set of pixels into a single pixel. The most common high quality approach is bicubic resampling. When resizing smaller this has the side effect of softening any hard edges within an image resulting in a final image that's sometimes considered ever so slightly blurry or "softer" than the original. I see this in the format.com example, in that it looks every so slightly soft or blurry compared to the PS and Muse examples. The algorithm available in PS and used by Muse when resizing smaller is bicubic sharper. This approach combines bicubic resampling with a very small amount of sharpening to counteract the blurring/softening effect of the resizing. For the specific subject matter in your image and the JPEG artifacts that were likely introduced before the image was resized, the sharping results in making the edges of the JPEG artifacts more noticeable (along making all the edges in the image crisper).
Without the URL for the webpage and the original image file (and probably the .muse file), I can only speculate on exactly what's being generated and why, but hopefully the above information is helpful.

V25 JPEG Compression in PDF folio sucks....

Guys -
What happened to compression in v25 folios?
I've had two deisgners ask me this in the last week...and I noticed it myself. I don't think we are doing anything differently...
It seems that JPEG compression in PDF folios has been increased since prior releases of Folio Builder.
Pixelization is really noticeable even over JPEG folios set to high quality.
look at this screenshot...
The image on the left is a High Quality Print PDF exported straight from inDesign. The central image is the doc as a JPEG folio. The right image is the doc as a PDF folio.
https://dl.dropbox.com/u/74532153/dps.png
Any one else notice this? And/or is there a way to override the default compression settings for PDF folios?

Hi Javad -
This was not resolved.
I worked closely with Yasin at DPS Gold Support - and he could reproduce the problem but was unsure what or why it was happening.
My guess is that a decision was made by Adobe to increase default compression to reduce file size.
The knock against DPS is file bloat - both as it relates to file transmission and file storage.
I think this was how they attempted to address both issues.
There are no controls within inDesign or Folio Builder to override the default compression.
The only way around is to create a PNG or JPEG folio and lose vector artwork.
I'm hoping it may be addressed with V 26
Mike

Lower jpeg compression on masters

This might seem like an odd question but how can I resave masters with lower jpeg compression or even lower resolution to save disk space?
Please dont make this a thread lecturing the downsides of actually doing this I know what Im asking of

I'm fairly sure you're going to have to export at the compression you want and then re-import the files. I'd create a new library to import into to make it easier to remove the originals.

JPEG compression codec in C

Hi guys.. I am trying to write a JPEG compression code in C language. Does any of you have the code already?? Can you pls post it for me? Also, i am trying to compress an image and send it over wireless link. Can i use JPEG or should i use only JPWL??
thanks.

Your inquiry appears to have no relationship to Oracle Database Advanced Compression.
I would suggest you ask it in a forum where it is on-topic.

Jpeg compression for tiff image (nt gettin a view of jpeg compressd pages)

Hi All,
I have a problem of jpeg compression inside a tiff file. When I convert no. of pages in a multi-page tiff file I m not getting a view of jpeg compressed pages. I convert black and white as well as gray scale jpeg images inside the tiff file. I used Compression Group4 for black and white image and JPEG compression for gray scale image. Also set the dpi of each page. But most of the viewer doesnt support my jpeg compressed pages. When I set the quality of jpeg images to 0.1f that time I m getting a view of particular images for some image viewer.
My requirement is to show the jpeg compressed image inside the IMAGING PREVIEW 2.5 VERSION. But it doesnt support for my output tiff. As well as cant get properties of that page inside the Fax viewer except Resolution 200x200 dpi.
     If anybody has any idea to compressed jpeg image inside the tiff file, please tell me how I can compress the gray scale image using jpeg compression.
Thank you in advance
Dipak

Hi Maxideon,
Thank u 4 ur immediate reply. But my requirement is, to show d tiff file only in IMAGING PREVIEW 2.5 VERSION. I tried lots but didnt manage to get a view of JPEG compressed page. I think somewhere I m doin wrong. Somewhere I wrote wrong code, cause d properties of jpeg compressd images also not getting in Fax Viewer except DPI. I change the BaselineTIFF Tags of JPEG compressed image, but cant manage output yet. I think d problem create at d time of metadata writing. My problem is tht, tiff created using sum other soft. is suppported by IMAGING PREVIEW 2.5 VERSION, y nt mine?
Here is my code for BaselineTIFFTagSet:
if(isBinaryImage) {
             // resolution unit
             rootTiffIFD.addTIFFField(new TIFFField(base.getTag(296), 2));
             // bit per sample
             rootTiffIFD.addTIFFField(new TIFFField(base.getTag(258), 1));
             // compression
             rootTiffIFD.addTIFFField(new TIFFField(base.getTag(259), 4));
             // rows per strip
             rootTiffIFD.addTIFFField(new TIFFField(base.getTag(278), bImageImage.getHeight()));
        } else {
             rootTiffIFD.addTIFFField(new TIFFField(base.getTag(296), 2));
             rootTiffIFD.addTIFFField(new TIFFField(base.getTag(258), 8));
             rootTiffIFD.addTIFFField(new TIFFField(base.getTag(259), 7));
             // thresholding
             rootTiffIFD.addTIFFField(new TIFFField(base.getTag(263), 3));
             rootTiffIFD.addTIFFField(new TIFFField(base.getTag(278), bImageImage.getHeight()));
        }     If u have any idea 4 write a metadata of jpeg page wid jpeg compression, can u plz suggest me hw to write a metadata 4 jpeg image? Which Baseline Tags r needed to set d jpeg compression?
Thank you
-dipak

I can't save tif with jpeg compression method

Hello, I've trouble to saving image in tif format with jpeg compression method.
With the same image this option some times is unavailable, randomly, I don't know how.
After some practice I leave that if I open an image previously saved in tif-jpeg the option turn on for the next save.
I've got both CS5 and CS4, and the odd thing is this occour on all.
Someone have triks?
Thanks.
Luca

I know very well the difference betwin a background layer and transparent layer...
I'm writing about a bug, or interference from something, when I want saving an image in tiff format with jpeg compression.
I'm asking if someone had a similar trouble and know a solution and/or trik to solve this!!!
I hope make myself clear.

Error saving TIF image with JPEG compression (IndexColorModel)

Hi all,
i recently came upon the following error:
javax.imageio.IIOException: Metadata components != number of destination bands
     at com.sun.imageio.plugins.jpeg.JPEGImageWriter.checkSOFBands(JPEGImageWriter.java:1279)
     at com.sun.imageio.plugins.jpeg.JPEGImageWriter.writeOnThread(JPEGImageWriter.java:694)
     at com.sun.imageio.plugins.jpeg.JPEGImageWriter.write(JPEGImageWriter.java:339)
     at com.sun.media.imageioimpl.plugins.tiff.TIFFBaseJPEGCompressor.encode(TIFFBaseJPEGCompressor.java:489)
     at com.sun.media.imageioimpl.plugins.tiff.TIFFImageWriter.writeTile(TIFFImageWriter.java:1835)
     at com.sun.media.imageioimpl.plugins.tiff.TIFFImageWriter.write(TIFFImageWriter.java:2686)trying to save a tif file with jpeg compression. The code used is this:
public static void main(String[] args) throws Exception{
    String s = "c:/sample images/gray_bug/graybug.tif";
    BufferedImage bi = ImageIO.read(new File(s));
    File outFile = new File(s + "-out.tif");
    ImageWriter writer = (ImageWriter)ImageIO.getImageWritersByFormatName("TIF").next();
    ImageOutputStream ios = ImageIO.createImageOutputStream(outFile);
    ios.setByteOrder(ByteOrder.LITTLE_ENDIAN);
    writer.setOutput(ios);
    TIFFImageWriteParam writeParam = new TIFFImageWriteParam(Locale.ENGLISH);
    writeParam.setCompressionMode(ImageWriteParam.MODE_EXPLICIT);
    writeParam.setCompressionType("JPEG");
    writeParam.setCompressionQuality(1f);
    IIOImage iioImage = new IIOImage(bi, null, null);
    writer.write(null, iioImage, writeParam);
    writer.reset();
    writer.dispose();
    ios.flush();
    ios.close();
}The test image that creates the problem can be found here:
http://s11.postimage.org/7wl195w8z/graybug.png
Any ideas what might be wrong?
I am using imageio 1.2-pre-dr-b04 and JDK 1.6.
TIA,
Costas

I can't help you but here's an exercise for you. When you get an exception you can't explain yourself, try posting it in Google. With a catch: remove anything from the error message that is specific to you like a classname or a specific value.
In this case there is nothing specific in the error message so try a search for "javax.imageio.IIOException: Metadata components != number of destination bands". One thing is for sure: you're not the first to run into this error.

Flatten transparency without lossy JPEG compression

Acrobat is using lossy JPEG compression (quality: medium) on some images after transparent objects were flattened. Even if the images had a ZIP compression before, Acrobat will use a lossy JPEG compression. The result is a loss of quality. There are also differences in quality within a single image, cause some images are divided in parts with a ZIP compression and with a lossy JPEG compression.
Is there a workaround to use Acrobat's transparency flattening without JPEG compression? The problem appears in Acrobat 7, 8 and 9.

Hi Cropas!
As stated above my PDF export settings you can read that this option is set to OFF. <Create Tagged PDF: Off>.
Indd can not cope with this option for embedded PDF document indd?

Help Maintaining Existing JPEG Compression

I have some very simple code which is reading a JPEG in with ImageIO.read and writing it out again with ImageIO.write. My image is 51kb to start and my new image ends up being 28kb. I assume this is happening because of some type of JPEG compression. I have found examples of how to change the level of JPEG compression, but I haven't found an example to just write the image out the way it was.
I'm trying to read in the image, add a small watermark, and write it out the way it the way it was, but the JPEG always ends up with different compression.. This seems like a common thing to do. Is there a FAQ or an example somewhere which shows how to do this?
Thanks,
Zack
Edited by: Zack_Grossbart on Dec 10, 2007 4:35 AM

>They seem to look good but I am wondering how well they will print
Anything above 85% that is appropriately scaled and sharpened will print identical.
>It was my assumption that larger file sizes would print better especially printing a large photo.
For the same photograph using the exact same compression algorithm that is strictly true. However, in a double-blind test, you will not see the difference above a certain level. This is even true for experienced printers. So there is a rapidly diminishing return on investment. The difference in quality of prints from a jpeg that were compressed at 50 and 60% will be enormous. However, the difference between 80 and 90% will only be visible to a very select few and between 90 and 100% basically undetectable. The file size difference at the same time will just keep going up.

No jpeg compression in iphoto6?

Similar Messages

Maybe you are looking for