This is Interesting: Free Magazines for Graphics designers and webmasters
Home > Archive > PainShop Pro Scripting > October 2007 > Targed compressed size
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Targed compressed size
|
|
| Jean-Luc 2007-10-15, 6:20 pm |
| Is it possible to create a script that compress a file at a certain size (in
JPEG)?
Suppose I want to limit the size to 64K (not over but I accept the nearest
value just under).
Actually, to do that, I need to run the JPG Optimizer, set the Compress
value manually and read the Compressed resulted value. If to high (over
64K), I put another value until I get something just under 64K, like perhaps
59K.
Could a script do the job "automatically"?
I know the limitations:
- if the file is too big, the aimed size will not be possible even at
maximum compression rate.
- quality problem may occurs if too compressed
But I speak about files of small or medium sizes to be placed on a website,
for example. If compressed at 15% or 20%, there will not be a noticeable
quality difference.
I don't know if the compressed resulted value can be read during the
optimization process or anywhere else which could permit the script to be
run again (internal loop) until the targeted value is aimed.
Cordialement,
Jean-Luc
| |
| SuzShook 2007-10-15, 6:20 pm |
| I don't know of any scripting value that stores this information, Jean-Luc -
there may be one, but I have no knowledge of it. Neither the JPEGOptimizer
command nor the ReturnImageInfo command contain any such informatio. I
don't think this can be done in a script. Suz
Jean-Luc wrote:
> Is it possible to create a script that compress a file at a certain
> size (in JPEG)?
>
> Suppose I want to limit the size to 64K (not over but I accept the
> nearest value just under).
> Actually, to do that, I need to run the JPG Optimizer, set the
> Compress value manually and read the Compressed resulted value. If to
> high (over 64K), I put another value until I get something just under
> 64K, like perhaps 59K.
> Could a script do the job "automatically"?
>
> I know the limitations:
> - if the file is too big, the aimed size will not be possible even at
> maximum compression rate.
> - quality problem may occurs if too compressed
> But I speak about files of small or medium sizes to be placed on a
> website, for example. If compressed at 15% or 20%, there will not be
> a noticeable quality difference.
>
> I don't know if the compressed resulted value can be read during the
> optimization process or anywhere else which could permit the script
> to be run again (internal loop) until the targeted value is aimed.
>
> Cordialement,
> Jean-Luc
| |
| Spandex Rutabaga 2007-10-15, 6:20 pm |
| Jean-Luc wrote:
>
> Is it possible to create a script that compress a file at a certain size (in
> JPEG)?
Not without much pain. You would have to write a file with a known
compression level, determine the size of the file, determine an
"improved" compression level by means of some kind of reasoning,
delete the file, and write it with the new compression level. At
this point you would determine the size again and do everything
all over again until you were as close to the target size as you
wanted. How many iterations were needed would depend on the
intrinsic compressibility of the image content and on how clever
you were in predicting an "improved" compression level.
| |
| Jean-Luc 2007-10-15, 6:20 pm |
| The final image size after compression displayed on screen is calculated
inside the program as I understand. I thought it was possible to capture
this value...
Thank you for trying, Suz.
Cordialement,
Jean-Luc
"SuzShook" <suzshook@roadrunner.com> a écrit dans le message de news:
47134a47$1_1@cnews...
>I don't know of any scripting value that stores this information,
>Jean-Luc - there may be one, but I have no knowledge of it. Neither the
>JPEGOptimizer command nor the ReturnImageInfo command contain any such
>informatio. I don't think this can be done in a script. Suz
>
| |
| Jean-Luc 2007-10-15, 6:20 pm |
| We should have access to the calculations done inside the program which
display the final compressed size. How does the program know the final size
and displays it before to do it?
Your suggestion to write the file on disk is ingenious but would not be
useable, I think (too much time to calculate and reiterate). Perhaps a
simple if/then/else/until could calculate the "best" compression level (in
terms of final size, I mean).
Cordialement,
Jean-Luc
"Spandex Rutabaga" <SpRu@agabatur.xednaps> a écrit dans le message de news:
47136A9A.C4CCFC32@agabatur.xednaps...
> Not without much pain. You would have to write a file with a known
> compression level, determine the size of the file, determine an
> "improved" compression level by means of some kind of reasoning,
> delete the file, and write it with the new compression level. At
> this point you would determine the size again and do everything
> all over again until you were as close to the target size as you
> wanted. How many iterations were needed would depend on the
> intrinsic compressibility of the image content and on how clever
> you were in predicting an "improved" compression level.
| |
| Spandex Rutabaga 2007-10-15, 6:20 pm |
| Jean-Luc wrote:
>
> We should have access to the calculations done inside the program which
> display the final compressed size. How does the program know the final size
> and displays it before to do it?
I don't know but I think it does the compression without writing
the file and counts the number of compressed bytes.
> Your suggestion to write the file on disk is ingenious but would not be
> useable, I think (too much time to calculate and reiterate).
I told you it would be painful.
> Perhaps a
> simple if/then/else/until could calculate the "best" compression level (in
> terms of final size, I mean).
Whatever you do, I think the issue is that you can't predict the
size of the compressed file because it depends on the specific
image data and how it is distributed in the image. You have to
measure the amount of compression and then predict a better level
of compression, i.e. one that gives closer to the target file
size. You could always use the Save For Web option in Photoshop.
[color=darkred]
> "Spandex Rutabaga" <SpRu@agabatur.xednaps> a écrit dans le message de news:
> 47136A9A.C4CCFC32@agabatur.xednaps...
>
| |
| Big Bad Dave 2007-10-16, 3:16 am |
| Jean-Luc wrote:[color=darkred]
> We should have access to the calculations done inside the program
> which display the final compressed size. How does the program know
> the final size and displays it before to do it?
>
> Your suggestion to write the file on disk is ingenious but would not
> be useable, I think (too much time to calculate and reiterate).
> Perhaps a simple if/then/else/until could calculate the "best"
> compression level (in terms of final size, I mean).
>
> Cordialement,
> Jean-Luc
>
> "Spandex Rutabaga" <SpRu@agabatur.xednaps> a écrit dans le message de
> news: 47136A9A.C4CCFC32@agabatur.xednaps...
>
I have a cunning plan!
Write a script that brings up the dialog box displaying it's proposed file
size, and make it put the dialog box at a known position on the screen.
Then have the script perform a screen-grab which can be pasted as a new
image. It should then crop the screen-grab to isolate the proposed file
size part, and hand this image off to an OCR program (ABBYY FineReader Pro
4.0 is a very good example and came free on a PcPlus magazine coverdisk a
few years ago). This would read the text in the image and return it as an
ASCII string to the script which could then adjust the quality control and
repeat the operation until the desired file size is acheived.
We should start an annual competition for people to try to use a PSP in the
most bizaar, imaginative and entertaining ways, to try to solve a set
problem. The Python libraries available inside PSP contain functions to
perform virtually all the OS functionality that you might want. There could
be a special bonus prize if your script can be run from the
Scripts.Restricted folder.
DaveP
| |
| Spandex Rutabaga 2007-10-16, 6:16 am |
| Big Bad Dave wrote:
> I have a cunning plan!
>
> Write a script that brings up the dialog box displaying it's proposed file
> size, and make it put the dialog box at a known position on the screen.
> Then have the script perform a screen-grab which can be pasted as a new
> image. It should then crop the screen-grab to isolate the proposed file
> size part, and hand this image off to an OCR program (ABBYY FineReader Pro
> 4.0 is a very good example and came free on a PcPlus magazine coverdisk a
> few years ago). This would read the text in the image and return it as an
> ASCII string to the script which could then adjust the quality control and
> repeat the operation until the desired file size is acheived.
>
> We should start an annual competition for people to try to use a PSP in the
> most bizaar, imaginative and entertaining ways, to try to solve a set
> problem. The Python libraries available inside PSP contain functions to
> perform virtually all the OS functionality that you might want. There could
> be a special bonus prize if your script can be run from the
> Scripts.Restricted folder.
You can use this as a precedent:
http://en.wikipedia.org/wiki/Intern..._C_Code_Contest
| |
| Jean-Luc 2007-10-16, 6:16 am |
| I have emailed to Corel for asking this new feature in the next version (my
report number: 071016-000035 )
Cordialement,
Jean-Luc
"Spandex Rutabaga" <SpRu@agabatur.xednaps> a écrit dans le message de news:
4713E6D4.5F264EDC@agabatur.xednaps...
>
> Whatever you do, I think the issue is that you can't predict the
> size of the compressed file because it depends on the specific
> image data and how it is distributed in the image. You have to
> measure the amount of compression and then predict a better level
> of compression, i.e. one that gives closer to the target file
> size. You could always use the Save For Web option in Photoshop.
>
| |
| SuzShook 2007-10-16, 6:22 pm |
| underprocessable | |
| Spandex Rutabaga 2007-10-16, 6:22 pm |
| SuzShook wrote:
> The script will ask for the desired target size, in KBs, and then do its
> thing. It starts with a compression factor of 5, and increases that
> compression factor by 5 on each iteration, until it gets below desired
> target size. It prints values in the SOP so if you run it in Single Step
> mode, you can follow its progression. Give it a whirl. Let me know what
> you think. Suz
You might make it more efficient in several ways. For example,
knowing the image pixel dimensions you might start with some
common compression value like 20 and determine the file size
per pixel. That size will be a measure of the compressibility
of the image. You can include a table which contains next
guesses based on the size of the file. In other words the
bigger the file at compression 20 the bigger the guessed
compression value should be. These tabulated values would
constitute the real starting point for the compression level
search.
You could consider a divide and conquer strategy, which halves
early guesses that are too big and doubles those which are too
small, averaging when the last guess was too big and the current
one is too small (or vice versa). In place of halving and
doubling you could use a history of guesses and results deciding
what to do by interpolating between the two closest guess that
straddle the target size. With at least three guesses straddling
the target you can home in on the best one using a parabola fit
to the size error and the minimum of the fitted parabola for
the next guess. This could help since the file size is non-linear
in compression value. Of course this may be overkill if you don't
intend to be precise about the target size, only very approximate.
However, the table could still save a lot of time. For example,
a 512 x 512 pixel grey 128 image compressed at 20 with chroma
subsampling YbCbCr 1x1 1x1 1x1 has as JPEG file size of 7,777
bytes. If you add noise to this same image (random, 100%,
non-monochrome) the file size for the same compression conditions
is 357,810 bytes, a factor of 46 difference. Even at a
compression level of 99 the latter image is still 25,491 bytes
in size. While these examples were chosen to give an indication
of the limits of the table, real photo images could easily differ
by factors of 2 to 5 in size per pixel at compression 20. For
instance, a lightbox shot of a glass object against a plain
background compared to an image of identical pixel size of a
moderately busy landscape with mostly vegetation but with some
sky produced a threefold difference in JPEG file size.
Whether you polish the script or not, you might want to post
a note about it in the Photography group since I think Eleanor
Culling was looking for something like this a couple of times
and I don't think she reads this group.
| |
| SuzShook 2007-10-16, 6:22 pm |
| underprocessable | |
| Spandex Rutabaga 2007-10-16, 6:22 pm |
| SuzShook wrote:
>
> Spandex Rutabaga wrote:
>
> Not sure about this, Spandex. The script has to first save the file in
> order to extract the file size, so I have to give it some starting
> compression factor.
Right. That would be the file size (per pixel) for a compression
of 20. Then you would use the resulting file size per pixel as
an index into the table to initialize the compression level for
the actual iterative search. The initial value for the search
would now be based on the compressibility of the image, not
simply on some arbitrary starting point (even though the very
first compression was arbitrary).
As far as I can see you are iterating compression levels in steps
of 5. I thought that something like being within 1 KB (or perhaps
some percentage such as 1%) of the target size might be a more
useful criterion. But I guess it all depends on the objective.
| |
| Jean-Luc 2007-10-16, 6:22 pm |
| Hi Suz,
thank you for trying!
The script doesn't work : nothing is done.
Give me a clue...
I have modified the 16 and 17 lines.
%:> )
Jean-Luc
"SuzShook" <suzshook@roadrunner.com> a écrit dans le message de news:
4714afc9_2@cnews...
> Well, I love a challenge, so I came up with a script that might just do
> what you want, Jean-Luc. Give this script - still in its infancy - a try:
| |
| SuzShook 2007-10-16, 10:16 pm |
| It works fine here, Jean-Luc. Are you getting any error messages???? Suz
Jean-Luc wrote:[color=darkred]
> Hi Suz,
> thank you for trying!
>
> The script doesn't work : nothing is done.
> Give me a clue...
> I have modified the 16 and 17 lines.
> %:> )
> Jean-Luc
>
>
> "SuzShook" <suzshook@roadrunner.com> a écrit dans le message de news:
> 4714afc9_2@cnews...
| |
| SuzShook 2007-10-16, 10:16 pm |
| underprocessable | |
|
|
| Spandex Rutabaga 2007-10-17, 3:18 am |
| SuzShook wrote:
>
> Here's a new version of this script - the save is now attempted first with a
> compression factor of 1 which is increased by 1 for each iteration until the
> saved file is smaller than the target size. Suz
Heh, heh - you really want to do this by brute force don't you? :)
| |
| Jean-Luc 2007-10-17, 6:19 am |
| underprocessable | |
| SuzShook 2007-10-17, 6:18 pm |
| Strange! Though this script worked perfectly for me when I was testing, I'm
now getting that same error in PSP X2. I'm about to re-install X2, as I
think some things are getting pretty flakey. I'm wondering if anyone else
can get this to work in PSP X2. Maybe it's just us, Jean-Luc. Does this
script work for anyone in X2???? Suz
Jean-Luc wrote:[color=darkred]
> Yes...
> See attached.
>
> Cordialement,
> Jean-Luc
>
> "SuzShook" <suzshook@roadrunner.com> a écrit dans le message de news:
> 4715656d$1_3@cnews...
| |
| SuzShook 2007-10-17, 6:18 pm |
| underprocessable | |
|
| On Wed, 17 Oct 2007 08:37:22 -0400, "SuzShook" <suzshook@roadrunner.com>
wrote:
>Strange! Though this script worked perfectly for me when I was testing,=
I'm=20
>now getting that same error in PSP X2. I'm about to re-install X2, as I=
=20
>think some things are getting pretty flakey. I'm wondering if anyone =
else=20
>can get this to work in PSP X2. Maybe it's just us, Jean-Luc. Does =
this=20[color=darkred]
>script work for anyone in X2???? Suz
>
>Jean-Luc wrote:
No fails with the same error message as Jean-Luc
--=20
David: NorthWest England
| |
| SuzShook 2007-10-17, 6:18 pm |
| Try version 03, attached to previous post, David. Let me know if that
works. Suz
David wrote:
> On Wed, 17 Oct 2007 08:37:22 -0400, "SuzShook"
> <suzshook@roadrunner.com> wrote:
>
>
> No fails with the same error message as Jean-Luc
| |
| Jean-Luc 2007-10-17, 6:18 pm |
| Now it works for me !
Amazing, your script is more precise than X2. When I move the slider and
select for example 99 Kb, the real resulted file size created by X2 is 102Kb
(greater). I hope this is not a bug in X2!... %:> ))
Now, the improvements needed...
I have not verified but I suppose that the resulted file size could be equal
or lower than the target value and not only lower.
Perhaps :
- something displayed on screen (text or somewhat) during the process
showing that it is in progress and a "Finished!" when the process is
completed.
- to close (or not) the opened image when saving in reduced size is done.
Needed :
- an input window where to put the target directory.
- the ability to use it in a batch process or on all the images opened on
the workspace
- we should not give ourself the name of the file (no need to change it
inside the script). The file's name should be trapped automatically.
Suppose I have:
file01 102000 Kb
file02 125000 Kb
file03 137000 Kb
that I want to reduce to no more than 100 Kb
Those files could be in a directory or opened on the workspace.
PS : you have done a wonderful work based on Spandex's idea (saving the
temporary file) !
Jean-Luc
"SuzShook" <suzshook@roadrunner.com> a écrit dans le message de news:
47160888_2@cnews...
> Found the error - try this version. Suz
| |
|
| On Wed, 17 Oct 2007 10:28:31 -0400, "SuzShook" <suzshook@roadrunner.com>
wrote:
>Try version 03, attached to previous post, David. Let me know if that=20
>works. Suz
Yes that works OK
--=20
David: NorthWest England
| |
| SuzShook 2007-10-17, 6:18 pm |
| underprocessable | |
| SuzShook 2007-10-17, 6:18 pm |
| Spandex Rutabaga wrote:
> SuzShook wrote:
>
> Heh, heh - you really want to do this by brute force don't you? :)
Yes - I like brute force, and it is simple, and works.
| |
| Jean-Luc 2007-10-17, 6:18 pm |
|
"SuzShook" <suzshook@roadrunner.com> a écrit dans le message de news:
47162df8_3@cnews...
> Progress is indicated in the Script Output palette.
Ooops, didn't open this palette...
> Are you saying you would rather type in the path name during the execution
> of the script?
No. Editing the script needs time. I thought is was easier to put the target
directory in an input window. Will test in my workflow...
> That will make running in batch a problem. I find it easier to type in
> the path in the script, and this would also allow you to run the script in
> a batch job. So for now, you must enter the path name within the script
> before running.
Yes. It may perhaps stay like this. I need to play with the script in real
situation for deciding what is the best to do...
> That would work for files previously saved, but not for unsaved files. I
> could use the actual file name for existing files, and give you a dialog
> box for unsaved images.
I didn't think about unsaved images. In my workflow, the optimisation
(target size) occurs at the end, after the files have been created and saved
once. When I said "images opened on the workspace", I thought about
previously saved images.
> If we go this route, and you choose the same path where the file exists,
> you run the risk of overlaying the file. I'm not sure you would want this
> risk. However, the attached script does process the image this way.
>
Thank you, Suz. Will test...
> If these files are in a directory, and you wish to process them in batch
> mode, you can do that. However, you will be asked for the TargetSize for
> each image. To prevent this dialog from being produced for each image,
> you can edit the script, changing the ExecutionMode for the GetNumber step
> to Silent, and changing the DefaultValue in that same step to your desired
> target file size.
Will test...
> I think that if you want to process these same files open in your
> workspace, you will have to do it one by one. I can't think of a way to
> cause a script to be executed on multiple open images - the
> right-click...apply to other open documents doesn't work for scripts, and
> neither does the drag-and-drop-action-on-the-image technique.
I thought I had for example 5 files open on the workspace (previously
saved).
I start the script.
I put the desired target value in the input window.
I hit OK.
The script processes the first image.
When done, it closes the processed image and goes to the next image (without
to ask the target value) until no more images are open.
> Note also that when running in batch, you need to check the "Script Save"
> option in the Save Mode panel.
>
I asked such a script because I wanted to work more rapidly. If editing the
script is needed for each step, it takes too many time. It is quicker to
move the compression slider in X2. Between the desired tool (dreamed) and
what you have realized (the real), there is some differences due to the
reality and the limitations.
%;> )))
I have asked in the French group to test your script in their workflow.
|
|
|
| | Copyright 2003 - 2009 forum4designers.com Software forum Computer Hardware reviews |
|