Applet for showing JPEG compression effects

Hi,
I'm currently trying to code an applet that will load a JPEG (or lossless image maybe), let you choose a new compression (quality) setting and then show the results.
I'm having a really hard time trying to figure out how to get this to work as I know there are firstly a few issues with an Applet and security when it comes to trying to put a loader in. Also how I'm going to either update, or show the new compression (quality) setting is a problem.
The method I think I'm going to use is to first load an image, then have maybe a choice of a few options of quality settings. I think I will then have to save the image with a new filename and reload the new file to show the effects of different compression quality.
I've come accross many examples of image stretching, resizing etc... but none that illustrate Java compression. As you can tell I'm at a bit of a loss, even where to start, so does anyone here have any insight into how I might do this? Any examples out there I could look over to see implementation and get idea's from?
Thanks for any help.
Dar.

I think you should be able to do this using the ImageIO functionality.
You'd need to do something like this,
- get your original image in memory
- create an ImageOutputStream from a ByteArrayOutputStream
- set the compression details for the image writer
- write the image
- re-read the compressed image via ImageIO
That's a pretty high-level description obviously and leaves you a bit of API reading to do, plus finding how to set the compression parameters (Google and the forum should provide the answer), but it should do just what you want, and you shouldn't need to save the file to the file system, nor do you need any non-standard loaders from the IIO toolkit - the standard JRE includes a JPEG reader/writer.
The main problem (though it may not be an issue in your circumstances) will be that it requires multiple copies of the image in memory at once, and if you're dealing with moderately large images then you can max out on the default heap allocation. Naturally this depends on th image sizes you're dealing with and whether you're in a constrained deployment environment where it's acceptable to ask the user to modify the Java Plug-In control panel (which usually isn't the case).
A workaround may be to ditch the original image after encoding it and reload it once the compression preview is closed, though this obviously has time performance implications which depend on where you're obtaining the image from, etc.

Similar Messages

  • 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 doesn’t 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 doesn’t 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 didn’t 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 can’t 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

  • Am using Adobe acrobat for iPad and pictures are showing JPEG and not PDFs

    I Am using Adobe reader for iPad and converted pictures from camera to ipad and pictures are showing JPEG and not pdf

    Hi bsmigs23,
    I'm not sure that I follow. You have the Adobe Reader app for iOS, and converting photos to PDF? Where are the photos showing up as JPEG? Do you see the converted PDFs when you look at the Recents List?
    Best,
    Sara

  • Changing default jpeg compression for Web Gallery files

    I have created several web galleries from both Raw and Jpeg files with Iphoto '08 that suffer from serious jpeg compression artifacts. I haven't found any way to change the compression amount to reduce the artifacts. Is there actually a way?

    papasteveo:
    Welcome to the Apple Discussions. There is no way in iPhoto for the user to manage the jpg compression of the web gallery photos. If the option for visitors to download the photos is selected the copy that's uploaded is compressed approximately equivalent to an Photoshop quality setting of 8 or 9 out of 12. The pixel dimensions are the same as the original unless the max dimension in the original exceeds 3054. The the file is resized to 3054 max dimension.
    If the gallery is just for viewing the image is resized to 800 x 600 with additional compression.
    You could manually replace the file with one that you've prepared but it would be very tedious as each file has it's own folder and the file name is changed to web.jpg (viewing only) or large.jpg (download). You would have to rename each file to be uploaded to the new name and make sure it's placed in the correct folder.
    Do you Twango?
    TIP: For insurance against the iPhoto database corruption that many users have experienced I recommend making a backup copy of the Library6.iPhoto 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 08 libraries. 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.

  • Automator - Changing JPEG Compression has no effect

    I have an application using Render PDF Pages as Images, using JPEG compression, but no matter what I change the Compression setting to, the image is always the same size. Bug or something else?

    and Oh Surprise! the background music is louder than what it should be. Its clip volume is set to 20% >and the Voiceover track's is set to 200%; as it was before.. but the music is so loud that we can't hear >the Voiceover track anymore.
    This could happen if ducking is set on the music track. Ducking defines the music track as 100% and works everything else out from there. Ducking will diminish every other track. If you had ducking set to 25%, and volume of voiceover 200%, the music track would need to be 800% of the voiceover track.
    My recommendation, turn ducking totally off. And use it only on short clips or short audio clips. If you have any long clips or music tracks, use the volume slider to set the volume.

  • 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.

  • 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.

  • 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.

  • "convert colors" causes jpeg compression?

    I recently had to re-install Acrobat, and since doing so whenever I run my preflight profile which is set to convert spot colors to cmyk, it's also apparently increasing the jpeg compression at the same time. Everything seems to be gaining bad jpeg artifacts after the color conversion (even when the colors being converted have nothing to do with the images).
    It may be unrelated, but it also seems to be creating all sorts of ICC profile non-cmyk colors in the process. I.e., before "convert to cmyk for digital printing" I run a preflight that simply checks for non-cmyk colors. This profile warns me that there is a Pantone color in the ad. I check the separation preview and find only one or two things with Pantone colors. I then run the convert fix. The Pantone colors go away, but now there are sometimes dozens of items that are showing up as ICC profile colors, and this seems unfixable. I can't create a profile to convert them.
    What's going on? Are there settings somewhere that can select the degree of (or lack of) jpeg compression? Why is it compressing the file at all? I have no such setting selected in the preflight profile. I tried creating a profile that does absolutely nothing at all but convert to cmyk, and it's still causing these problems.
    This is using Acrobat 8. It's the same version, same disks, we used before, but these problems are new. I may have a setting wrong somewhere.

    You are not making sense, and your methodology is fundamentally flawed.
    Hitting Command+S without editing the file is NOT "saving".  It's not doing anything at all.  The program just idles.
    You can verify this by observing that the file's modification date does not change.
    Even your limited but flawed methodology will show the degradation if you change even a single pixel before hitting Command+S.  Then you will be degrading the image.  Just make a one-pixel change, for instance with the pencil tool, then save.  That is the same as doing a Save As.
    Note that in your original query you were indeed changing a file by converting it to a different color space.  THAT is a change.
    Independently from the above, your methodology of comparing two layers blended in Difference mode has the inherent limitation of the monitor's performance in displaying the shadows.  Your monitor, no matter how high-end, will NOT show you a difference between a 0,0,0 pixel (R,G,B,) and 0,0,1 or 1,0,0 or 1,0,1 for instance.  SAme goes for 1,0,2 etc., until you reach the lower threshold of your particular monitor.
    There are two preferred methods of comparing two layers to see if they're identical.
    Comparing allegedly identical images in Photoshop
    The first one, championed by the late, lamented author and guru Bruce Fraser, is as follows [direct quote by copy and paste]:
    A better way of comparing images with identical pixel dimensions is to use [Image menu >] Apply Image… > Subtract with an Offset of 128.
    Difference only shows pixels that are lighter in the source than in the target (or maybe it's the other way around—I forget) where Subtract with Offset 128 shows differences in both directions.
    Pixels that are identical in both images come in as RGB 128 gray, those that are different come in at a value that exactly reflects how different they are.
    It also makes it much easier to spot subtle differences…
    === ===
    The second one was suggested by someone in the Color Managament and Photoshop Windows forums, which follows:
    (NOTE: only the methodology is of interest and pertinent, not the questionable context in which it has brought up and used.)
    * 1) Open the two images to be compared in Photoshop
    * 2) Move one image as a layer over the other one
    * 3) select "Difference" as blending mode in the layers palette
    * 4) now the whole image should appear seemingly black on the monitor
    [So far this is the traditional, "time honored" method.]
    * 5) select the magic wand tool with these settings: Tolerance: 0/ Anti-alias: no/ Contiguous: no/ Sample All Layers: yes
    * 6) click somewhere into the formerly gray area
    [This refers to an image of a Color-Checker type of card that had wide gray border around it. The test, therefore, requires a pure gray image in the image, something highly unlikely to change, in order for the magic wand to select all pure-black images (255,255,255). Such a border can easily be created around an image by increasing the canvas size and filling the newly created space with pure gray (128,128,128). ]
        Explanation: you just selected all completely black pixels (0,0,0) i.e. all pixels that are identical in both layers.
    * 7) you should see "marching ants" forming rectangular patterns
    * 8_) invert the selection (Shift Command I)
       Explanation: the selection now covers all the other pixels, i.e. all pixels which are different between both layers.
    * 9) create a new empty layer and select it in the layers palette
    * 10) set the foreground color to white
    * 11) fill the selection with white (Alt+backspace on Windows, accordingly on Mac)
    * 12) set the blending modes of all layers back to normal
        Explanation: you now see all identical pixels in their respective color and all different pixels in white.
    This method is a lot more sensitive than the traditional one which stops at step #4 above.
    Finally:
    jfraze wrote:
    Wow, the level of hostility is amazing on these adobe forums…
    Only because people like you come in here itching for a fight, rather than to seek help.  It's just the way you choose to react—and to intereact with others.
    Wo Tai Lao Le
    我太老了

  • N700 - Excessive Jpeg compression

    The camera is actually pretty good, but the result is badly spoilt by way too excessive Jpeg compression.
    There is no need for that these days. Memory is cheap. I have just put in a 32G MicroSD card, for about £25, and that is a Samsung one, not some no-name cheapo one. The phone is saving images to heavily compressed files and paying the price for that.
    Nokia should make the quality (i.e. the compression level) configurable.
    Apologies for the +1 change in the username; I managed to mess up my logins, and Nokia operates separate logins for the store and the forum and they seemingly cannot be the same.

    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 didn’t 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 can’t 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

  • Export to jpeg:  Show jpeg file size prior to export

    Photoshop save to jpeg dialog box shows the jpeg file size associated with each jpeg compression level (1 - 12).  Lightroom export dialog box does not show jpeg file size.  Showing the expected jpeg file size is useful when needing to limit file size while maximizing jpeg quality.  For example, some email applications limit attachment file size; some photo hosting sites (e.g., Zenfolio) limit file size to 12mb.  If I export a cr2 file at 100 quality, it may result in a file size of 14mb.  However, I cannot determine this until after I export.  Then I may try 90 quality and find that the resulting file size is only 8mb.  So, I try 95 quality, and get a 12.5mb file.  This iterative process is a waste of time.  I need to se the file size resulting from each jpeg quality setting in the export dialog box.

    I have tried trashing the plist file. The files look fine through the media manager when copied to the other profile. They look like they are suppose to. The small videos also look fine when played on that computer. Unfortunately our other mac pro computer doesn't have final cut so i can't open and play proress files and my laptop, due to the extreme resolution can't be played on my laptop with final cut studio installed. Tomorrow i'm going to install the proress decoder on the one mac pro to check the files and make sure the self contained is checked but i'm almost positive on that. Other than nuking the profile i don't know what else to do. This is really weird.

  • Best jpeg compression mode..?

    When using PhotoShop's (CS2) "Save-for-Web", the popup window offers some options that 'help' doesn't explain well enough - for me.
    Both "Optimized" and "Progressive" have cautions appended, which are, respectively: "however, some older browsers do not support this feature" and " not supported by some browsers".
    What to do, what to do.? (accompanied by a wringing of hands).
    Originally, I'd thought that "Progressive" would be the preferred; now I'm not sure of either, eh.
    any help here appreciated.
    ThanX

    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 didn’t 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 can’t 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

  • 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.

Maybe you are looking for