I have used MiniMagick to compress JPEG files.
With strip function, I want to get rid of EXIF from image. So, I do:
image = MiniMagick::Image.open("my_picture.jpg")
image.strip
image.write("my_picture_small.jpg")
but sometimes the size of my_picture_small.jpg is bigger than my_picture.jpg.
However, when I don't use the strip function, like
image = MiniMagick::Image.open("my_picture.jpg")
# image.strip
image.write("my_picture_small.jpg")
my_picture_small.jpg's size is smaller.
That situation happened with some picture deal with Photoshop and in my CentOS computer, but run well with my Macbook. I don't know why stripping some information led to more storage.
Can anyone explain it?
Have found that ImageMagick will recompress image even if it with any arguments, such as
convert image.jpg new_image.jpg
new_image.jpg will be different from image.jpg more or less. If image.jpg is from a phone or camera or a image processing tools, the degree of difference is also different.
So compress images with MiniMagick or Rmagick that use ImageMagick as there system support, just do convert -strip image.jpg new_image.jpg may led to a unexpected result, avoid to use MiniMagick command if there is no need to greatly compress file.
Related
I dont understand the explanation about why GIF files always has image resolution 72ppi.
I have tried using ImageMagick converting PNG to GIF specifying -density to be 300ppi, but the resulting GIF is still 72ppi.
The GIF format does not store any value for "ppi" or "dpi" or pixel density/resolution - see Wikipedia.
I think software assumes 72 dpi, and then loads your image, updating that assumption if it finds anything better... which it never will in the case of GIF.
In any case, the dpi/ppi is irrelevant until such time as you want to print your image, and I don't know of anyone ever using GIF as a method of submission of images to any reputable printers or publications - TIFF is probably the preferred or most common method.
I use gostscript to convert text to outlines with the following code :gswin32c.exe -sDEVICE=pdfwrite -sOutputFile=output.pdf -dQUIET -dNOPAUSE -dBATCH -dNoOutputFonts -f test_new.pdf,it works.But i got a very small output file from 2.5M to 70kb.Then i find the picture became blurred in pdf.
Add -dPDFSETTINGS=/default,This will have the same result.
I's better to use -dPDFSETTINGS=/printer or -dPDFSETTINGS=/prepress,but 300dpi is not enough for me(or for my boss).
Is there any way to keep the original resolution of the picture.
Or how to set a higher dpi for images in output pdf.
The test file is here.
Thanks in advance.
The answer to your question is 'yes' (but see later). Don't use PDFSETTINGS, that sets lots of things all in one go. If you want control then you need to specify each setting individually.
Rather than use this shotgun approach you need to read the documentation, decide which controls affect areas you want to change, and alter those controls only.
However, image downsampling is not your problem. If you don't use -dPDFSETTINGS then PDF file written by Ghostscript contains an image at exactly the same resolution as the image in the original file.
Your problem is that the image is being written with JPEG compression, and JPEG is a lossy compression, so you are losing fidelity. Note that in the original file the image is written uncompressed, which is why its so large.
It looks like the original image was a JPEG, and the free PDF editor you are using has realised that so it saved the image uncompressed (I may be giving it too much credit here, it may save all images uncompressed). Applying JPEG to an image which has already been quantised simply amplifies the artefacts.
Instead you need to specify that you want images compressed with Flate, which is a lossless compression. The documentation for the pdfwrite controls can be found here, you need to change AutoFilterColorImages and ColorImageFilter.
Note that by not applying JPEG quantisation (a second time) and DCT encoding, the compression is less than your first experience. For me the output file comes in at just over 600Kb (leaving the font in place, and the text as text, would be a couple of Kb smaller). However the image is identical, as expected.
Since you are clearly using Ghostscript in a commercial environment, can I just point you at the licence and ask you to check that your usage is compatible with the AGPL, bearing in mind that this covers software as a service usage as well.
I have a small problem, I have a set of animated gif images. I want to pick individual gif image files, and create multiple tiff images capturing individual frames.
I am looking to do it in Python/Java.
Help would be appreciated!
You can do this easily from the command-line using ImageMagick. It is available for free from here. It has bindings for Perl, C/C++, Python and lots of others. It is ready installed in many Linux distros.
Your command looks like this:
convert -coalesce input.gif %02d.tif
which will produce TIFF format output files, numbered 01.tif, 02.tif etc. according to the frame number.
You can also extract an individual frame, say frame 7, like this:
convert -coalesce input.gif[7] my_favourite.tif
or a sequence of frames, say 3-7 like this:
convert -coalesce input.gif[3-7] frames%02d.tif
Note however, that when you extract individual frames, you may get artefacts depending on how well compressed your original GIF files are - since they sometimes only store DIFFERENCES between frames, so you may be best advised to extract all frames then discard any you don't want.
I'm using a nice enough cms (locomotive(github)) to allow some non-tech savy users to upload pictures to the system. The program is able to resize and crop pictures to any given size.
Trouble is, Internet explorer doesn't know how to deal with CMYK-encoded images. The users of this app are not exactly tech-savy; asking them to transform their images from CMYK to RGB is not an option. I'd like to modify locomotive so that it does the change automatically. I've been trying this for some hours but had no luck so far.
This is what I have found:
Locomotive uses dragonfly to perform the resizing.
Concretely, it uses dragonfly's imagemagick module.
The file that defines how Dragonfly is used in locomotive can be found here.
There is also a dragonfly initializer file.
I have also found that what (think) I need is adding a -colorspace RGB option to the parameter sent to Imagemagick by Dragonfly. It doesn't look like Dragonfly provides an easy option to do that.
I've tried several things, the last one consisting on monkeypatching Dragonfly's Imagemagick Processor so that the -colorspace RGB option is always used. I've added this in locomotive's config/initializers/dragonfly.rb:
# locomotive's config/initializers/dragonfly.rb
# ... Locomotive's default initialization
module Dragonfly
module ImageMagick
class Processor
alias :old_convert :convert
def convert(temp_object, args='', format=nil)
args += ' -colorspace RGB' # force RGB in all thumbnails
old_convert(temp_object, args, format)
end
end
end
end
I was pretty sure that this should work, but unfortunately it doesn't. And I have run out of ideas. Can anyone help?
On the commandline, I sometimes need to add -type truecolor to make colorspace conversions work reliably:
convert cmyk.jpeg -colorspace rgb -type truecolor rgb.jpeg
Maybe you try to add it in your code as well?
From the related list to the right, might this SO answer help?
Properly converting a CMYK image to RGB with RMagick
Unfortunately there doesn't seem to be a straightforward way to do this with Dragonfly. I've given up.
I'm working on a Sidebar Gadget and cannot get my JPEGs to show up (PNGs work). When I try to open the file by itself in IE8 it doesn't work. Firefox, of course, can open it fine.
JPEG Details:
Dimensions: 1080X900
180 dpi
Bit depth 24
Color representation: uncalibrated
I've found some things talking about the images being compressed incorrectly (?) but I haven't been able to get it working...
Any clues?
IE8 drops support for CMYK JPEG and renders them as the infamous red X without so much as a warning.
If you have ImageMagick:
identify -verbose image.jpg
will show you the image colorspace. If it's CMYK, you can convert to RGB with:
convert broken.jpg -colorspace RGB fixed.jpg
If you need to do CMYK to RGB conversion on a whole batch of JPEG-images, this command may be helpful to you:
for i in *.jpg; do convert "$i" -colorspace RGB "$i"; done
PS: If you'd like to see what is going on, just add -verbose:
for i in *.jpg; do convert "$i" -colorspace RGB -verbose "$i"; done
I had a similar issue with IE8 not displaying two JPEG images. FF, Safari, Chrome all displayed them without complaint but IE acted as if the files were not there. I have no idea what was going on, but a quick image conversion to gif or png fixed the problem. Just another in a long line of confirmations that IE sucks.
Had similar problems with existing images, which will not show up in IE8.
Problem is, as converter42 says: CMYK-Images
Convert them to RGB colorspace and all is good
The Solution with the PNG is not the best, because PNG files can be MUUUCH larger than JPGS.
If you are using photoshop for creating the jpgs. Try the below.
Open the file and go to 'Image' menu
Go to Mode
Select RGB
Save and upload to server.
This should work.
Why are you dealing with the image at 180 dpi and not the 72dpi screen resolution? At screen resolution the image will be roughly double that size. Still, the size is manageable for any browser.
When creating a gadget, you should be using PNGs for all the elements of the gadgets. Are you having issues displaying JPEG photos?
Have you looked for the yellow bar at the top of IE that blocks certain suspicious content from being loaded (popups, activex, javascript, etc.)? If it appears, try telling it to "allow".
Lastly, what are you using to compress your images to JPEG?
EDIT: If you want to do batch conversion use the batch converter in photoshop or use the Actions panel to record the conversion process for a single image, then replay the action on an entire folder. Additionally, you can save this action to a "droplet" which is a small application containing the action that you can drop an image or folder on top to.
Alternatively, if you don't fell like learning Actions, XNView is an excellent image viewer and converter that supports something like 160 different image formats and can batch convert and batch rename huge lists of files.
I fixed this issue by opening the CMYK JPEG file in Windows Paint and then saving as a JPEG, which Paint encodes as RGB by default. Not a great solution because I'm sure that Paint's converter is not as robust as Photoshop's, but this can be a quick fix if the job needs to be done now and there's no access to the tools above.