Results 1 to 3 of 3

Thread: JPG_TRANSFORM: lossless wipe support

  1. #1

    Default JPG_TRANSFORM: lossless wipe support

    According to the jpegtran authors, "wipe" is intended as an option to discard (gray out) data inside a given image region while losslessly preserving what is outside.

    Example

    I'd like to suggest adding such feature to the JPG_TRANSFORM plugin.

    As alternative i've tried jpegcrop but it seems to produce broken images.

  2. #2
    Hobby User Sprintdriver's Avatar
    Join Date
    Aug 2006
    Location
    Norway
    Posts
    158
    OS
    32-bit Linux Distribution
    CPU Cores
    4

    Default

    That is a very good idea - if possible.

    But I think it expand way beyond only making background gray. Say having the original JPG image from internet (or any source that make poor quality).

    Then you use e.g. Inkscape to put some symbol onto that image (say stop sign just for example) and export that to a png image. Such a feature should make it possible to re-encode only the part of the new image (png with a stop-sign over the original look) that is different from the original jpg image file.

    In your case - since IV is not an image editing program - it will be needed to use a second program like Gimp or Inkscape to make the gray effect - and then using the function that partially re-encode the jpg image.
    If it hurts not to drint, don't waste the bottle then.

  3. #3
    Power User j7n's Avatar
    Join Date
    Jun 2006
    Location
    Cyberspace
    Posts
    535
    Version
    IrfanView 4.51
    OS
    32-bit Win Server 2003 SP1
    CPU Cores
    1

    Default

    This function is useful. Although I would prefer JPEGCrop myself because there the selection snaps to macroblocks, and I can see the area being blanked or cropped before committing. Perhaps the macroblock intersects too much needed detail, or leaves a dirty border. Choose the best tool for the job.

    JPEGCrop does not produce broken files. Maybe you need to go to Preferences and choose Huffman Optimized instead of Arithmetic coding. Bad idea for them to make ari the default. This is probably related to the recent patent expiry, and calls for support for arithmetic to be included in web browsers and widely used. Despite that the space savings are only around 10% and bandwidth is cheap and generally wasted today.

    The issue with JPEGCrop is that if you choose Save, and write the choice to an ini file, it will not be used when loading images via the command line, and Arithmetic will be the default again. This was so with the old version which defaulted to Huffman default. I would always process edited images with IrfanView to decrease their size.

    The stop sign would have to be reduced to poor quality too then, if the rest of the image stays untouched with the original set of quantization tables. Especially not a good choice if the pasted symbol is red. I feel that lossless editing restricts the user too much, and is probably a pain to implement for the programmer. If the low quality image stays the same size during editing, the lower quality portions will already consume less space if re-saved normally.

    Edit: I didn't notice that the post was a few months old.
    Last edited by j7n; 18.01.2018 at 02:17 AM.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •