Author Topic: RIOT tool that respects folder hierarchy? (for JPEG compression?) (Read 38,929 times)

dcsev · « **on:** October 04, 2011, 05:23 PM »

Hi all,
RIOT:
Fileforum: http://fileforum.betanews.com/detail/RIOT-Radical-Image-Optimization-Tool/1242238434/1
HOME PAGE: http://luci.criosweb.ro/riot/

I am currently using RIOT (a program that efficiently optimize images for the Web? ) , but I need a tool that respects folder hierarchy. RIOT does not currently do that, nor does its plugins.
Anyone have any recommendations that their current program that does?

vlastimil · « **Reply #1 on:** October 04, 2011, 05:57 PM »

If you only want to re-compress JPEGs (or strip metadata), you can use my tool PhotoResize.exe http://www.rw-designer.com/picture-resize

Rename it to PhotoResizeP100IRSOEQ85.exe to recursively process all .jpg file in given folder(s) and overwrite the images. Change the 85 to a quality level you want.

dcsev · « **Reply #2 on:** October 04, 2011, 05:58 PM »

I don't want to strip metadata.

Basically, I like the idea of optimizing JPEGs to take up less space. I couldn't perceive any difference between RIOT-optimized images + regular JPEGs but the size difference in some cases were up to 70%(!!!).

Does your utility do the same thing?

vlastimil · « **Reply #3 on:** October 04, 2011, 06:41 PM »

Well, stripping metadata is quite usual when optimizing images - metadata include EXIF info, color profile, etc. They are relatively useless when the pictures are simply displayed online. But it is your choice.

If you want to keep metadata, rename it to PhotoResizeP100IMRSOEQ85.exe

It is not a specialized "RIOT" tool as you call it, it simply resizes .jpegs, but with P100, the physical size remains the same, and it only re-compresses them. Today's digital cameras usually produce relatively large file with unreasonable compression options, so saving a lot of space with negligible quality loss is possible - experiment with the compression quality.

skwire · « **Reply #4 on:** October 06, 2011, 03:29 AM »

stisev, what do you mean by "respects folder hierarchy?"

dcsev · « **Reply #5 on:** April 02, 2012, 10:00 PM »

Hi guys,
I am really embarrassed to say I forgot about this request -_-
Just remembered now that I had a need for it.

SS-- see the following link:

http://luci.criosweb.ro/riot/bbpress/topic.php?id=60

scores of users are wanting the same thing. RIOT does everything we want except the following:
1) Allow you to save the processed file inside each folder (and delete original file)
2) drag and drop folder and recursively

dcsev · « **Reply #6 on:** May 11, 2013, 08:20 AM »

Hi all,

It's been one year and there STILL isn't a solution for this. RIOT does not support “Batch optimizing into original subfolders". I have tried every other program I could find by Google on the Internet and could not locate a good program to do this.

Please help!

vlastimil · « **Reply #7 on:** May 11, 2013, 08:36 AM »

Have you actually tried mine? Mentioned right in the second post? 'cause it DOES what you say you need and did from the beginning. So, is there any special reason why you refuse to try it? I am really curious...

dcsev · « **Reply #8 on:** May 11, 2013, 08:37 AM »

Stand by vlastimil. I am online now. Let me see what your post is about :-)

dcsev · « **Reply #9 on:** May 11, 2013, 08:39 AM »

Quote

It is not a specialized "RIOT" tool as you call it, it simply resizes .jpegs, but with P100, the physical size remains the same, and it only re-compresses them. Today's digital cameras usually produce relatively large file with unreasonable compression options, so saving a lot of space with negligible quality loss is possible - experiment with the compression quality.

vlastimil -- the reason I didn't try it because I was uncertain that it did the same thing. Does RIOT do the same thing as your tool (in term of "optimizing" that RIOT does? IS that all it does?)

dcsev · « **Reply #10 on:** May 11, 2013, 08:56 AM »

I tried your tool vlastimil. It didn't do anything. I tried dragging folder/folder structure Nothing. Just folder structure and nothing. Pictures only and nothing.

Name is PhotoResizeP100ICRSOQ85.exe and PhotoResizeP100IMRSOEQ85.exe

I tried both and neither worked. Am I doing something wrong? I am dragging folders with jpeg files inside.

UPDATE: when I remove "Skip smaller" option, it worked. Will I be able to tell the difference in quality between two images? With RIOT, I really cannot.

dcsev · « **Reply #11 on:** May 11, 2013, 09:43 AM »

I tried comparing the file sizes/quality. I really want to use your app vlastimil. It would serve me TREMENDOUSLY and is exactly what I am looking for.

I tried using your tool and RIOT still gave me better file sizes. Could you replicate the best setting/file name for me? If I use "skip smaller" option, it doesn't do anything.

vlastimil · « **Reply #12 on:** May 11, 2013, 02:48 PM »

You are right, the 'skip smaller' option does not make sense in this case (the final image dimensions do not change and so the tool skipped all files, because they had the correct dimensions). If you want smaller file sizes, change the number at the end - instead of Q85, try Q75 or even smaller numbers and run the tests. That number controls the compression quality, the lower the number, the smaller file sizes and lower quality.

dcsev · « **Reply #13 on:** May 11, 2013, 06:56 PM »

vlastimil,
Thanks for the clarification regarding the skip smaller feature.

I think where I am having difficult and need your help desperately is to find the "sweet spot" for JPEG optimization. Am I wrong to assume that RIOT has some magic algorithim for quality/size ratio?

These are the settings:

0. I do NOT want to mess with the dimensions!!
1. Remove all meta dataa (EXIF, comments, etc)
2. 75% quality
3. Chroma subsampling 4:1:1 (????)
4. Standard optimize (not progressive)
5. Preserve file modification date

This is the name that I got: PhotoResizeP100ICROEG.exe
PhotoResizeP100ICROEG.exe

Please confirm if this is the correct name matching what I got. I am going to do some basic tests and compare file sizes/quality

dcsev · « **Reply #14 on:** May 11, 2013, 07:34 PM »

Okay I finished the tests

test 1 Photoresizer: 473 MB (496,117,161 bytes)
test 2 - RIOT folder: 470 MB (493,519,346 bytes)

Quality is pretty much the same. Minor difference in some pixels when flipping back and forth repeatedly between pictures, but overall I am very pleased.

This is the tool I was looking for now and makes it really easy to process my stuff!!!! thank you so much!

Now if there was only one for video

vlastimil · « **Reply #15 on:** May 11, 2013, 09:52 PM »

You should probably drop the C (put to current folder) - it has no effect when I (overwrite originals) is used (and can actually slow things down if the software is on different drive than the images).

Chroma subsampling controls the resolution of the color planes (Cb, Cr) relative to the brightness plane (Y). 4:1:1 (1 color sample for 2x2 pixels) is the default for PhotoResize as well.

Hard to guess where the <1% difference in file size comes from.

dcsev · « **Reply #16 on:** July 19, 2013, 09:54 PM »

rofl just a heads up.
After YEARS of asking/begging/yelling-kicking-screaming profanities for this function in RIOT and Caesium ... after I found Photoresize, both programs now support what I want.

Can you believe that! ROFL

dcsev · « **Reply #17 on:** August 25, 2013, 06:58 AM »

vlastimil,
Very weird thing here.
When I drag and drop a photo (essentially reducing the size) and then double click it in Windows 7, rotate it and save it, the file size returns to around what it was previously. Any ideas why?

vlastimil · « **Reply #18 on:** August 26, 2013, 07:13 PM »

Not sure. There are 2 possibilities. Maybe you have had the photo opened in the Win7 viewer moments before resizing it and the viewer kept it in cache and then used that original file as the source file for the rotation. Or the viewer does not do a lossless JPG rotation and instead re-encoded the image using default quality settings.

dcsev · « **Reply #19 on:** April 20, 2015, 08:27 PM »

vlastimil,
I have been using your app for the longest time and it has saved me a lot of time and grief. Thank you!

I want to tell you two things:

1. The problem in the aforementioned thread (with respect to sizing) still exists. I am following all steps correctly.
a) Send JPEG to your app. b) rotate the picture in ANY app [windows, xnview, acdsee, etc] and save. c) observe file back to original size. d) send picture back to your app to get it back to lower size. No idea why this is happening

2. Any chance for a front end GUI / progress bar for your app? I know it's a simple app, but I was just converting 26GB of Pics and it would've been nice to know the progress of it.

4wd · « **Reply #20 on:** April 21, 2015, 04:04 AM »

Quote from: stisev on April 20, 2015, 08:27 PM

1. The problem in the aforementioned thread (with respect to sizing) still exists. I am following all steps correctly.
a) Send JPEG to your app. b) rotate the picture in ANY app [windows, xnview, acdsee, etc] and save. c) observe file back to original size. d) send picture back to your app to get it back to lower size. No idea why this is happening

Wouldn't a better methodology be:
a) Rotate
b) Resize

Why resize twice, it just increases the number of artifacts.

And you still don't mention whether you're using Lossless JPEG Rotation, arbitrary angle rotation, etc.

XNView, from my testing just now doesn't change the file size appreciably when doing a Lossless JPEG rotation unless your options for JPEG writing will cause information, (metadata, internal thumbnail, etc), to be stripped, added, or changed.

eg. Here's the results of a 40MB JPEG after it's gone through four Lossless 90° Right rotations when compared to the original:

Maximum difference in file size was ~60kB and that was only after the first and third rotation, (ie. the image was now 90° left or right rotated w.r.t. the original).

dcsev · « **Reply #21 on:** April 21, 2015, 05:12 AM »

Wait, are we talking about the same thing? I am talking about rotating it after its been compressed with the aforementioned tool. After I rotate it, the file returns to original size and I have to rotate it again to get it back to where it was.

4wd · « **Reply #22 on:** April 21, 2015, 08:35 AM »

Quote from: stisev on April 21, 2015, 05:12 AM

Wait, are we talking about the same thing?

Obviously not, since it was unclear whether your reference to size refers to:
a) file size (re. "observe file back to original size")
b) image dimensions

Quote

I am talking about rotating it after its been compressed with the aforementioned tool.

The steps you gave were:
1) compress
2) rotate (after this you noted: "observe file back to original size" - and considering that your previous remarks in this thread were about not altering image dimensions, then my conclusion was that you were referring to the file size - and the next step you gave bears that out.)
3) compress again

Quote

After I rotate it, the file returns to original size and I have to rotate it again to get it back to where it was.

Now you seem to be saying that when you rotate an image, save it, and then display it, it isn't rotated.

It might help if you gave us the settings you're using for vlastimil's program and attach one of the images that won't rotate so we can have a look at the EXIF data and try for ourselves.

dcsev · « **Reply #23 on:** April 21, 2015, 07:12 PM »

I am using:
PhotoResizeP100ICROEG

If I compress the image and then rotate it, the file size will return to normal

4wd · « **Reply #24 on:** April 22, 2015, 12:50 AM »

Since you haven't attached an image that's giving you problems, this is the one I'm using to test, so the following are just screengrabs of the results of each step:

1) Original (42,465,102 bytes, 10358x3803 pixels 300DPI)

2) Step 1 - compression with PhotoResizeP100ICROEG (6,587,712 bytes, 10358x3803 pixels 300DPI)

3) Step 2 - Rotation using XNView 2.32, Lossless 90° Right (6,570,854 bytes, 3803x10358 pixels 300DPI)

As you can see, the picture is rotated and the file size decreased after rotation.