Program To Compare Pictures

Posted:
in General Discussion edited January 2014
I'm looking for a program that compares pictures...perfectly!





i know that opening, resaving and transferring files over a network are all a possibility to lose data...so my question is how can i check after doign all these if the orig file is different then the original?





i just want this to do some testing after one of my coworkers noticed that after she just brought the levels of a picture up it was 2x the size and both were in jpg



orig was from her camera

new was after the orig was in Photoshop and levels were raised and saved again as a jpg

Comments

  • Reply 1 of 16
    ringoringo Posts: 328member
    If i understand you correctly, the easiest solution would be to compare the file sizes. If you're worried about corruption, then the best way would probably be to do a checksum, but I'm not aware of how to do that.
  • Reply 2 of 16
    ebbyebby Posts: 3,110member
    Quote:

    Originally posted by Ringo

    If i understand you correctly, the easiest solution would be to compare the file sizes. If you're worried about corruption, then the best way would probably be to do a checksum, but I'm not aware of how to do that.



    You can make a checksum on disk images. Copy your files you want to transfer, make a disk image of them and add a checksum. Then ship it ove a network and open the disk image. Your Mac should automatically check the checksum.
  • Reply 3 of 16
    ringoringo Posts: 328member
    that wouldn't compare the checksums, just create a checksum inside the image file
  • Reply 4 of 16
    ast3r3xast3r3x Posts: 5,012member
    there is no way to check it...byte for byte?
  • Reply 5 of 16
    Quote:

    Originally posted by ast3r3x

    there is no way to check it...byte for byte?



    You don't know what a checksum is, do you?
  • Reply 6 of 16
    ghost_user_nameghost_user_name Posts: 22,667member
    Okay, I guess my last post wasn't too greatly helpful.



    You can checksum an individual file from the command line with the md5 command. For example, here I check two files I suspect to be the same. If they give the same checksum, they are the same.





    [~/Desktop] bwsmith% md5 someimage1.jpg

    MD5 (someimage1.jpg) = 548ace7b013458686d4b8c8272d678f8

    [~/Desktop] bwsmith% md5 someimage2.jpg

    MD5 (someimage2.jpg) = 548ace7b013458686d4b8c8272d678f8



    Sure enough, they are the same. Got it?
  • Reply 7 of 16
    ast3r3xast3r3x Posts: 5,012member
    Quote:

    Originally posted by Brad

    Okay, I guess my last post wasn't too greatly helpful.



    You can checksum an individual file from the command line with the md5 command. For example, here I check two files I suspect to be the same. If they give the same checksum, they are the same.





    [~/Desktop] bwsmith% md5 someimage1.jpg

    MD5 (someimage1.jpg) = 548ace7b013458686d4b8c8272d678f8

    [~/Desktop] bwsmith% md5 someimage2.jpg

    MD5 (someimage2.jpg) = 548ace7b013458686d4b8c8272d678f8



    Sure enough, they are the same. Got it?




    i do know what checksum is...or well i had an idea, but i thought it checked the checksum for the disk and not the files inside of it so i was really asking if there was a way for individual files instead of that





    but thank you very much for you help (where do you learn stuff like that?!)
  • Reply 8 of 16
    ast3r3xast3r3x Posts: 5,012member
    uh...looks to be a hexidecimal number...well what does it stand for?
  • Reply 9 of 16
    alcimedesalcimedes Posts: 5,486member
    lol, he just wants to clean the dupes out of his porn collection w/o doing it manually.
  • Reply 10 of 16
    ast3r3xast3r3x Posts: 5,012member
    Quote:

    Originally posted by alcimedes

    lol, he just wants to clean the dupes out of his porn collection w/o doing it manually.



    haha...md5 has more uses then what i planned i see...





    ahhh so brad reads unix books on better ways to manage his porn collection...makes sense to me
  • Reply 11 of 16
    ebbyebby Posts: 3,110member
    Quote:

    Originally posted by Ringo

    that wouldn't compare the checksums, just create a checksum inside the image file



    Maybe I am missing something, but when you open the disk image on another computer, Disk Copy checks ALL the files in that image for corruption using the checksum. This checks for errors in each file as well as the image file. If it is not automatic (which it is for me) there is an option to verify the checksum in one of the menus.
  • Reply 12 of 16
    cowerdcowerd Posts: 579member
    Quote:

    orig was from her camera

    new was after the orig was in Photoshop and levels were raised and saved again as a jpg



    Standard save in PS saves the file with an icon preview that adds to file size. If it is a small file you can easily double the file size.



    Sounds like you need version control more than just to learn how to use checksum.
  • Reply 13 of 16
    curiousuburbcuriousuburb Posts: 3,325member
    Quote:

    Originally posted by ast3r3x

    i know that opening, resaving and transferring files over a network are all a possibility to lose data... one of my coworkers noticed that after she just brought the levels of a picture up it was 2x the size and both were in jpg



    orig was from her camera

    new was after the orig was in Photoshop and levels were raised and saved again as a jpg



    < Bolding added for emphasis. >



    to clarify, you're discussing jpg to jpg numbers at identical resolution and pixel dimensions, right?



    network packet loss is a separate issue from size change due to image manipulation software.



    discrepancies in identical files between machines on a network is possible based purely on OS.



    minimum addressable cluster size based on hard disk volume is common in some OS's. "blank" documents saved from many apps report 4k on some machines with small drives and 16k on machines with multi-gigabyte storage due to limitations in the way Win95 (for example) couldn't address enough clusters at formatting time and therefore set unusually large "sizes" for minimum blocks. uploading things to a UNIX server would report the actual filesize in bytes and you'd see 762 bytes for a blank html document (head and body tags, no code) that reported 4k on your machine. The 762 was more correct.



    UNIX <unixes, unices, unixii? > are normally more efficient and robust file systems which have historically provided a more accurate and honest bytecount to track (and then checksum if req). most Unix compression formats, are lossless and offer built-in checksumming, IIRC.



    Mac OS X is better than OS 9 in regard to more honest filesize reportage, and it looks like Panther, in it's 64-bitness, will lead the way to even better file systems (no more 2 or 4Gb limit if RAM holds 8Gb)



    with regard to the image manipulation as prime cause of different sizes, packet loss seems less likely.

    two explanations leap to mind...



    1. camera jpg algorith preset -vs.- Photoshop "full" jpg control



    Default jpg compression setting by the camera (controlled by a selector like "Quality - L-M-H -" still maxes out at 90% quality in many cases) likely differs from the jpg compression setting in Photoshop (more precise, with customizable preferences for bicubic sample size, etc). I'd expect most cameras to be preset to optimize storage and hedge a bit on jpg size/quality. Photoshop should represent a more "accurate" model of the algorithms in action, so purely for technical implementation of the algorithms, i'd expect the computer to offer more data than the camera.





    Other than the re-pegging a jpg issue (usually smaller file, but possible that nasty artifacting adds info on its own), the most likely explanation, IMO, is



    2. addition of information at level adjustment = resultant larger file post-compression.



    In pumping up the levels in Photoshop, your friend likely added enough information and difference to some formerly similar pixels in the photo that the sampling of data actually received a more complex image after her tweak than the uncorrected image had. Since most lossy compression algorithms work on similar runs of pixels, altering every fifth pixel with enough levels to break the run would result in a new picture that doesn't compress as small because of increased variety in the pixels.



    For example: if the original image had lots of dark sky that was subject to very efficient compression (lots of similar pixels to aggregate and "lose" in representing a block of sky) and your friend brightened the clouds enough that the formerly black areas were now filled with 75 shades of dark grey cloud as well as darker sky (now aggregated blocks of lossy compression aren't as large because contiguous areas of similar colour are less common than before level pump), we would _expect_ the modified image to be larger after compression since complex images don't compress as efficiently. Altering every x pixels of a solid colour will show similar results in simple tests.



    < if you want to know more of the nuts and bolts of compression, ask... that feels like enough of tangent without getting way more technical >



    my 2 bytes



    edited repeatedly... still needs adjustment.
  • Reply 14 of 16
    ast3r3xast3r3x Posts: 5,012member
    Quote:

    to clarify, you're discussing jpg to jpg numbers at identical resolution and pixel dimensions, right?



    of course





    Quote:

    Originally posted by curiousuburb



    Other than the re-pegging a jpg issue (usually smaller file, until artifacting adds info on its own), next most likely explanation, IMO, has to do with the addition of information at level adjustment and the resultant larger file post-compression. Go figure, eh?



    In pumping up the levels in Photoshop, your friend likely added enough information and difference to some formerly similar pixels in the photo that the sampling of data actually received a more complex image after her tweak than the uncorrected image had. Since most lossy compression algorithms work on similar runs of pixels, altering every fifth pixel with enough levels to break the run would result in a new picture that doesn't compress as small because of increased variety in the pixels.



    For example: if the original image had lots of dark sky that was subject to very efficient compression (lots of similar pixels to aggregate and "lose" in representing a block of sky) and your friend brightened the clouds enough that the formerly black areas were now filled with 75 shades of dark grey cloud as well as darker sky (now aggregated blocks of lossy compression aren't as large because contiguous areas of similar colour are less common than before level pump), we would _expect_ the modified image to be larger after compression since complex images don't compress as efficiently.



    < if you want to know more of the nuts and bolts of compression, ask... that feels like enough of tangent without getting way more technical >



    my 2 bytes




    this is what i figured





    i wouldn't call jpg bad compression...at highest quality (from .psd) is what we used to send our pictures to the printing lab (i work at a photography studio)



    i understand there is a quality loss, but my question is...how much? the indoor camera takes pictures in tiff, well raw so there is enough info to adjust the levels without taking it into photoshop (kodak compression scheme it uses)



    the outdoor camera is jpg and after we grab them from the camera we do put them into PSD to edit and retouch them (retouching in my job) but to send any picture to the lab be it outdoor or in we put it into jpg first.



    my main question like i said earlier is HOW MUCH of a loss is there if u use best quality?







    and if you want to tell me about compression...tell me about PNG, its my favorite format because it handles transparency on the web perfectly
  • Reply 15 of 16
    curiousuburbcuriousuburb Posts: 3,325member
    note some clarifying edits above.



    uh, from memory...



    JPEG max compression gets 100:1

    JPEG min compression gets 2:1



    and it's clear the Photoshop coders are fans of Spinal Tap.

    their latest quality slider now goes up to 12



    the real problem for purists is that in lossy compression, this info is gone, buh-bye.



    TIFFs are larger but retain all the information

    distribution of larger files is an issue for many networks (and the web), hence JPEG, but degradation of image is bad, and I'm surprised photographic studios would allow jpg for larger format work. preview camera sure, replaces the polaroid for many, but not the hasselblad... similarly the CD costs more than the cassette, because you're paying for "digital quality" that doesn't degrade. Maybe most folks can't spot minimum JPG, the same way compared to the hearing of most people, only dogs can spot DAT from CD, but all of the printers and photo-manipulators I know insist on TIFF or PSD source because they don't want to be blamed when the client complains about image quality after providing a jpg that no longer possesses the detail they're asking for.



    personally, i teach my photoshop students only to jpeg as a final step or to ship a web preview. always stay TIFF or PSD. re-compression is bad. PNG isn't widely enough supported in the commercial world yet for our Academy to endorse it, except from Fireworks for DreamWeaver usage.



    i'd offer setting=blah ratings, but content matters too.



    rich variegated pictures don't compress as well as larger block solids.



    certain architectural shots should never be jpg'd because of moire patterns that the compression inevitably adds between the grid in some structures.



    colour is an issue worthy of a whole thread (RGB-to-CMYK aside) and digicams may not solve this until better CCDs arrive, but flesh tones compress differently than sky in some cases.



    there are a few real camera buffs on these boards with wider experience in which cameras are used for which result, and what presets or idiosyncrasies each holds
  • Reply 16 of 16
    ast3r3xast3r3x Posts: 5,012member
    well PNG should take over where jpg left off (only slightly larger file sizes...well slght for broadband)





    jpg is the last step we use when sending it...we actually burn a copy of tiff and jpg to disc to store the images





    i am glad i'm not the only one that finds it odd that the slider goes up to 12
Sign In or Register to comment.