crop a jpeg without recompressing?

zozo
Posted:
in General Discussion edited January 2014
I have a ton of pics I took that are jpeg that I want to crop but don't want to re-save and therefore re-compress an already compressed pic.



Any tools that can do the trick to shave off them pixels?



Photoslop and other tools are in my goodies bag of course...



merci
«1

Comments

  • Reply 1 of 23
    Depends how you want to display them...



    Any re-saving of a JPEG will be a quality hit. No way around that.



    If you have to open and edit them, save as .psd or .tiff during interim stages and only spit out a JPEG again at the end (beware of autosave, too).



    A simple open -> save as .psd -> crop, tweak, etc -> export max quality JPEG might not cause too obvious a visual degradation, but it really depends on your source image content and standards of acceptable image. Architectural shots with lots of horizontal and vertical lines are much more likely to experience Moiré as they get 'Pegged, for example.



    If you were displaying them in a wrapper application on screen only...

    it is possible you could build masks which might 'crop' the pre-positioned (original) JPEGS underneath in much the same way a picture box in quark or indesign can frame and act as a clipping box for the image in it (though you wouldn't use a JPEG for print).



    You might also be able to do this with absolute layer positioning in HTML, but I'm not sure if all cross-platform browsers would support the same tags, so it might take some versioning for iframes or other visibility properties in DHTML, etc.



    Not sure how much that helps.



    Edit: iPhoto crops, but I believe it recompresses and resaves in doing so.
  • Reply 2 of 23
    amoryaamorya Posts: 1,103member
    I think GraphicConverter can save cropped without recompressing.
  • Reply 3 of 23
    Quote:

    Originally posted by Amorya

    I think GraphicConverter can save cropped without recompressing.



    I don't see how.



    If you remove pixels, algorithmic recalculation ought to be required in bicubic sampling. If you edit the headers to redefine the dimensions, you'd get data in the file that no longer applied.



    Maybe I'm overlooking something or thinking myself into a box (still fighting a head cold).



    Google suggests there might be a way if your crop is equal to the block size:

    Quote:

    This means that you can make local modifications to a JPEG image without material degradation of other areas of the image. The areas you change will degrade. Unfortunately, cropping does not count as a local change! JPEG processes the image in small blocks, and cropping usually moves the block boundaries, so that the image looks completely different to JPEG. You can take advantage of the low degradation behavior if you are careful to crop the top and left margins only by a multiple of the block size, typically 16 pixels, so that the remaining blocks start in the same places.



    More recent summaries tend to repeat my comments earlier, and though some companies are trying to suggest they can manage this trick in XP, the ratio of vapor to accurate claim tends to be a bit high on most of these sites.
  • Reply 4 of 23
    Beyond the lossless second and third passes, JPEGs are compressed on a block-by-block basis. The size of these blocks (in pixels) can vary. It would be possible to crop on block boundaries, thus maintaining the per-block compression, but I don't know of any programs off-hand that do so.



    Though, I would put money on the chance that some independent developer wrote a shell script or a small program for Unix/posix that does what you need to do.
  • Reply 5 of 23
    zozo Posts: 3,117member
    sigh... I don' see why you can't just "take away" the pixels you don't want without touching any others. I mean, its just digital information in the end. there are lots of apps that let you snip out information in an Mp3 (for example) without the need to re-compress the file again.



    Nonetheless, I vaguely remember the option in GC to save without recompressing. But I think it was for when you rotate a JPEG



    I guess I'll just crop and then "save for web" in PS and try n get the best size/quality compromise
  • Reply 6 of 23
    Quote:

    Originally posted by ZO

    sigh... I don' see why you can't just "take away" the pixels you don't want without touching any others. I mean, its just digital information in the end. there are lots of apps that let you snip out information in an Mp3 (for example) without the need to re-compress the file again.



    Nonetheless, I vaguely remember the option in GC to save without recompressing. But I think it was for when you rotate a JPEG



    I guess I'll just crop and then "save for web" in PS and try n get the best size/quality compromise




    Yes... rotation doesn't count as 're-saving' since there is no change to the image data.



    Not the same as cropping.
  • Reply 7 of 23
    squashsquash Posts: 332member
    Stole this info off another site. I'd guess even if you found a program that claimed to not lose anything,it would be bs



    Notice the more you compress a JPEG image, the more artifacts you begin to see. This is because you are actually loosing information. JPEG compression is therefore called lossy compression. You may also notice that the color fidelity does not change. Colors are not lost in JPEG images.



    To me it sounds like what you want to do isn't possible without some sort of loss.
  • Reply 8 of 23
    scottscott Posts: 7,431member
    I just did a comparison. I took a high res jpeg, compressed it "50%" and saved it. Then I cropped it and save it at "100%". Reopened both, cropped the larger one back down and compared it to the saved cropped image. As far as I can tell it's the same image with the same pixels. I did this with GC.
  • Reply 9 of 23
    Quote:

    Originally posted by Splinemodel

    Beyond the lossless second and third passes, JPEGs are compressed on a block-by-block basis. The size of these blocks (in pixels) can vary. It would be possible to crop on block boundaries, thus maintaining the per-block compression, but I don't know of any programs off-hand that do so.







    ^^what he said:



    dunno if anyone has wrapped this in a gui yet:

    http://www.ben.com/jpeg/
  • Reply 10 of 23
    Quote:

    Originally posted by ZO

    sigh... I don' see why you can't just "take away"



    JPEG is a lossy compression. Here's what happens, from 100,000 feet.



    1) A block is inspected. It's a 2D matrix of datapoint, thus it's a 3-variable system.



    2) The fourier series of this block is analyzed. That is, the frequency content is analyzed. Depending on the settings you select, a certain threshold of high-frequency content is thrown out.



    3) The modified fourier series is saved, and then losslessly encoded. The predictable gaps in the frequency domain make the compression work very well.



    So, when your image program transforms the frequency data to image data, it's not "remembering" the frequency data. Secondly, cropping a frequency block will have very strange affects on the entire block, once it is transformed to image data. Likewise, cropping an image block will have very profound affects on the frequency block.



    As an aside, the reason why JPEG has so much trouble with edges is due to its nature of removing high frequency content. Edges are high frequency.
  • Reply 11 of 23
    So I've compiled jpegtran with the cropping patches and can now crop and rotate jpegs losslessy from the command line. I am working on Cocoa GUI that wraps the command line tool and it will (eventually) look something like this:







    (click for larger image)




    I haven't put in the crop guides/bounding boxes yet and am just learning how to wrap a unix tool.... so it might not be done till next weekend (maybe...)
  • Reply 12 of 23
    zozo Posts: 3,117member
    awesome Havanas!!!
  • Reply 13 of 23
    Update:



    So it took 5 weeks, but heres my first attempt at shareware-ish:



    squarePusher



    It has bugs and probably memory leaks too, worst it should do is crash itself.



    When you save a file I'm inserting an underscore_ into the filename to try to help prevent overwrites. I'll have a better saving system in place eventually.



    Also it has massive room for performance increases. I literally just got it cohesive enough to use a few hours ago.



    Feedback? And good luck... be careful with yer file-naming.



    *By using my program you absolve me of any horrible things that (may)happen to you plus or minus a few hours* :P





    PS: A few features are not enabled (optimize / exif) and will go with defaults.

    Also when you rotate I'm invoking the trim so my editor reflects the pixels that will be lost from the sides as they swing into the top/left side (non block pixels sizes are usually sent to the opposite side in an unsightly mess)..



    screenshot

  • Reply 14 of 23
    zozo Posts: 3,117member
    it works great in the non-recompressing department! Amazing!



    However, it noticiably brightened a couple pictures I tried. They were portraits of friends. It was skin tone, and it the "squarepusher" file resulted with paler skin tone.



    Otherwise, the interface is good. I didnt initially inderstand how to crop the pic (drag the sides of the pic you've imported).



    I would also change "save" to "save cropped pictures as:" and then the filename space, and then the save dialog box at the end of the dialog box (sequential flow of steps)



    Otherwise, amazing! Great work!!!
  • Reply 15 of 23
    memory leaks, eh?



    Remember the creed: free the mallocs.



    Of course, I'm not sure what kind of language or level of abstraction you're programming this in, and your code, per se, might be free of mallocs altogether.
  • Reply 16 of 23
    Quote:

    Originally posted by ZO

    However, it noticiably brightened a couple pictures I tried. They were portraits of friends. It was skin tone, and it the "squarepusher" file resulted with paler skin tone.









    Really thats me being lazy as it would take all of 5 minutes to add the preserve markers code in. What you are seeing is a result of the embedded color profile getting ripped out (this does not alter the image data so much as how its rendered...certain progs IE for example dont respect colorsync anyway...open the same photo in IE/safari). If I can summon the energy I'll try to put another version out tonight.



    Unfortunately the command line tool its based on also leaves the old preview in when you preserve all markers. I might need to look for a more robust back end... that or a combination of apps slicing and dicing.



    Thanks for the save suggestions, that part really needs a bit of polish/logic.



    EDIT: OK, I have uploaded a version that should preserve color settings (at the expense that the preview will show the old image)



    download

  • Reply 17 of 23
    Quote:

    Originally posted by Splinemodel

    memory leaks, eh?



    Remember the creed: free the mallocs.



    Of course, I'm not sure what kind of language or level of abstraction you're programming this in, and your code, per se, might be free of mallocs altogether.










    Yeah, in Cocoa mostly, which follows the whole remember to release any objects which you have allocated or retained. I need to go over the whole app one of these days... my architecture isn't great so thats where they may have crept in. Its hard to figure out sometimes if you want to try to go with less memory or less processing power. Also message dispatch, hard to tell if i should have less assessors and let my Interface talk more directly to the current data or go with the strictest MVC that I can. I dunno I went to art school....hah....but did have 2 C classes there.
  • Reply 19 of 23
    Just tired your app on my dual G5 and it worked well. Thanks!



    Now could you make it easy to crop to certian sizes like 4 x 6?
  • Reply 20 of 23
    zozo Posts: 3,117member




    Worked like a charm



    Usability wise, its not obvious how to select the cropping "tool"



    colors match perfectly now though...



    Planning on releaseing on VT? Freeware?
Sign In or Register to comment.