shrink JPGs to some resolution (dpi) ?
Hi, so here's my very generic question #1 for my India book: is it possible that context (lua?) will "shrink" all \externalfigure jpegs automatically to some specified dpi resolution and quality (e.g. 300 dpi with 95% jpeg 'quality' for print and 100 dpi and 75% for screen quality) ? since I'm only using Linux, using Acrobat unfortueately is not an option (thanks, Adobe:-( that book will be ~100 A4 pages with ~50% and 50% pictures, trying to have 2 pictures per page with text flowing around. the pictures are JPG photos with quite high resolution, upto 24 Mpixel. so those picutres are HUGE and horrible overkill for a final print on A4 with typical images withs around 0.5\textwith. I know about ghostscript being able to convert/shrink PDFs, but first the "original" PDF with full size JPGs with be really huge, and ghostscript takes ages to shrink them. so that's not real fun doing this too often... right now I write the real typeset size of all images to the log file and use some external script to calculate the current resolution and then create a new set of images which e.g. 300 dpi. but that's still an ugly hack still has some issues with EXIF data, rotation, clipping, ... and right now leads to strage problems (see mext mail;) any hints to read the original large JPGs, but only write "print quality" 300dpi images, or low quaity 75dpi images for speed (and saving net bandwidth when mailing PDFs to co-workers of the group)? thanks, Harald -- "I hope to die ___ _____ before I *have* to use Microsoft Word.", 0--,| /OOOOOOO\ Donald E. Knuth, 02-Oct-2001 in Tuebingen. <_/ / /OOOOOOOOOOO\ \ \/OOOOOOOOOOOOOOO\ \ OOOOOOOOOOOOOOOOO|// \/\/\/\/\/\/\/\/\/ Harald Koenig // / \\ \ koenig@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^
Hi,
is it possible that context (lua?) will "shrink" all \externalfigure jpegs automatically to some specified dpi resolution and quality (e.g. 300 dpi with 95% jpeg 'quality' for print and 100 dpi and 75% for screen quality) ?
[....]
any hints to read the original large JPGs, but only write "print quality" 300dpi images, or low quaity 75dpi images for speed (and saving net bandwidth when mailing PDFs to co-workers of the group)?
Why not eliminate the orignal high quality jpegs altogether? Use imagemagick or your favorite photo batch processor to convert all the high quality jpegs to low quality jpegs. Say you have directories images/print that contain 300dpi images and images/screen that contain 100dpi images. Then you can use: \setupexternalfigures [directory={images/print}] \startmode[screen] \setupexternalfigures [directory={images/screen}] \stopmode Run with context --mode=screen to get low-resolution images. Aditya
On Mar 09, Aditya Mahajan wrote:
Why not eliminate the orignal high quality jpegs altogether? Use
one reason is that the jpgs are not in final shape either. the selected pictures will be reworked from raw files, maybe some brightness/contrast correction, clipped, etc. whenever the images are reworked, this will happen on the original pictures and then the resize/... steps are needed again. yes I know, makefiles and easy shell scripting can do all this work (actually they do already;) but I dream of reducing the number of tools, processing steps, ... I thought everyone using jpeg images might have the same interest without additional hassle: just make my output PDF suitable for printing at 300dpi quality or similar... runtime potimisation (e.g. caching) is a different topic, and that also can be solves nicely with lua I'd guess?!;-)
imagemagick or your favorite photo batch processor to convert all the high quality jpegs to low quality jpegs.
ACK -- sort of: have a look for my next mail "jpeg problem: Dimension too large" as I'm running into a strange problem exactly using imagemagick to shrink the images... and I need information about the rendering size of the image from context (if pictures are used in different sizes or come from different types of cameras etc.), so it's not a imagemagick-only thing.
Say you have directories images/print that contain 300dpi images and images/screen that contain 100dpi images. Then you can use:
\setupexternalfigures [directory={images/print}]
\startmode[screen] \setupexternalfigures [directory={images/screen}] \stopmode
Run with context --mode=screen to get low-resolution images.
except for the "mode" thing (thanks for that nice context example!!) that's how my setup looks already! though I'd like context (lua?) to shrink the images (and maybe even write to some "cache" directory? not really needed, but nice idea while typing;-) thanks, Harald -- "I hope to die ___ _____ before I *have* to use Microsoft Word.", 0--,| /OOOOOOO\ Donald E. Knuth, 02-Oct-2001 in Tuebingen. <_/ / /OOOOOOOOOOO\ \ \/OOOOOOOOOOOOOOO\ \ OOOOOOOOOOOOOOOOO|// \/\/\/\/\/\/\/\/\/ Harald Koenig // / \\ \ koenig@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^
On 3/10/2015 12:33 AM, Harald Koenig wrote:
ACK -- sort of: have a look for my next mail "jpeg problem: Dimension too large" as I'm running into a strange problem exactly using imagemagick to shrink the images...
that is often an indication that the image lacks tags describing the resolution
except for the "mode" thing (thanks for that nice context example!!) that's how my setup looks already! though I'd like context (lua?) to shrink the images (and maybe even write to some "cache" directory? not really needed, but nice idea while typing;-)
you can configure a cache (with the cache parameter) but normally that is not needed Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Harald,
I use ImageMagick/GraphicsMagick to resample HUGE high resolution tiff
images to something more manageable to work with. Using a script, I
converted hundreds of images to lower resolution copies. Then it was
simply a question of pointing ConTeXt to use the appropriate directory
to find the right figures.
The basic comand is
convert -resample 300x300
(or 100x100) and you can play with "-quality 75%"
This can be done once and is much better than getting ConTeXt to
convert every time on the fly.
Alan
On Mon, 9 Mar 2015 22:12:24 +0100
Harald Koenig
Hi,
so here's my very generic question #1 for my India book:
is it possible that context (lua?) will "shrink" all \externalfigure jpegs automatically to some specified dpi resolution and quality (e.g. 300 dpi with 95% jpeg 'quality' for print and 100 dpi and 75% for screen quality) ?
since I'm only using Linux, using Acrobat unfortueately is not an option (thanks, Adobe:-(
that book will be ~100 A4 pages with ~50% and 50% pictures, trying to have 2 pictures per page with text flowing around.
the pictures are JPG photos with quite high resolution, upto 24 Mpixel. so those picutres are HUGE and horrible overkill for a final print on A4 with typical images withs around 0.5\textwith.
I know about ghostscript being able to convert/shrink PDFs, but first the "original" PDF with full size JPGs with be really huge, and ghostscript takes ages to shrink them. so that's not real fun doing this too often...
right now I write the real typeset size of all images to the log file and use some external script to calculate the current resolution and then create a new set of images which e.g. 300 dpi.
but that's still an ugly hack still has some issues with EXIF data, rotation, clipping, ... and right now leads to strage problems (see mext mail;)
any hints to read the original large JPGs, but only write "print quality" 300dpi images, or low quaity 75dpi images for speed (and saving net bandwidth when mailing PDFs to co-workers of the group)?
thanks,
Harald
On Mon, Mar 9, 2015 at 10:50 PM, Alan BRASLAU
Harald,
I use ImageMagick/GraphicsMagick to resample HUGE high resolution tiff images to something more manageable to work with. Using a script, I converted hundreds of images to lower resolution copies. Then it was simply a question of pointing ConTeXt to use the appropriate directory to find the right figures.
The basic comand is
convert -resample 300x300
(or 100x100) and you can play with "-quality 75%"
This can be done once and is much better than getting ConTeXt to convert every time on the fly.
texnically ConTeXt mkiv could be able to convert images with swiglib and GraphicsMagick see https://swiglib.foundry.supelec.fr/ It should work under linux64 and windows (and yes, I'm looking for Freebsd support...)
-- luigi
On 3/9/2015 10:50 PM, Alan BRASLAU wrote:
This can be done once and is much better than getting ConTeXt to convert every time on the fly.
Do you really think that we let context convert a big file each run in a critical workflow? Context will only resample when an image file changed (which happens when you have to process from repositories updated by authors). Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On Mar 09, Hans Hagen wrote:
On 3/9/2015 10:50 PM, Alan BRASLAU wrote:
This can be done once and is much better than getting ConTeXt to convert every time on the fly.
Do you really think that we let context convert a big file each run in a critical workflow? Context will only resample when an image file changed (which happens when you have to process from repositories updated by authors).
I guess that's a question for me ? of course I don't plan to run context on the big files every time -- as I know that that's still way too slow;) but it would be nice if I don't need magic external tools to guess the correct physical print size, calculate the actual number of pixels for e.g. 300 dpi, etc. I already have script which extracts all JPGs from a context's pdf using pdfimage, and then rename them to the "input" file names according to the log file. right now I shrink the PDFs using 'gs -dPDFSETTINGS="/screen" ...' and then extract a copy of the small images into some ...-screen/ directory and use them for all futur context runs. but using gs or ImageMagick's convert plus some magic log file reading/calculation is a bit ugly, while context knows all the details about physical image size, native pixel size of input jpgs etc. so that context perfectly could do the job if asked to (and without huge intermediate PDFs)... finally I like the idea to be able to create the final PDF in a "single" context run from *original* source (== original JPGs) without lots of additional tools and steps/scripts (or if I want to start over "form scratch" from input files). just an idea... (more to come;-) Harald -- "I hope to die ___ _____ before I *have* to use Microsoft Word.", 0--,| /OOOOOOO\ Donald E. Knuth, 02-Oct-2001 in Tuebingen. <_/ / /OOOOOOOOOOO\ \ \/OOOOOOOOOOOOOOO\ \ OOOOOOOOOOOOOOOOO|// \/\/\/\/\/\/\/\/\/ Harald Koenig // / \\ \ koenig@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^
On 3/10/2015 12:18 AM, Harald Koenig wrote:
On Mar 09, Hans Hagen wrote:
On 3/9/2015 10:50 PM, Alan BRASLAU wrote:
This can be done once and is much better than getting ConTeXt to convert every time on the fly.
Do you really think that we let context convert a big file each run in a critical workflow? Context will only resample when an image file changed (which happens when you have to process from repositories updated by authors).
I guess that's a question for me ?
More for Alan.
of course I don't plan to run context on the big files every time -- as I know that that's still way too slow;) but it would be nice if I don't need magic external tools to guess the correct physical print size, calculate the actual number of pixels for e.g. 300 dpi, etc.
150 pixels is probably enough for color print ... if you have raw files you can also consider png anyway, i need to think a bit about it but we do have all the info available, like - needed width/height - original width/height and from that we can calculate some conversion parameters if it would help you i can provide a tracker that will save info like this (per image): ["used"]={ ["colordepth"]=0, ["depth"]=0, ["format"]="pdf", ["fullname"]="t:/sources/cow.pdf", ["height"]=13156352, ["name"]=false, ["pages"]=1, ["path"]=false, ["suffix"]=false, ["width"]=18089984, ["xresolution"]=0, ["xsize"]=18089984, ["yresolution"]=0, ["ysize"]=13156352, },
finally I like the idea to be able to create the final PDF in a "single" context run from *original* source (== original JPGs) without lots of additional tools and steps/scripts (or if I want to start over "form scratch" from input files).
that is what we also prefer: only luatex/mkiv + gm / gs Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On Mar 10, Hans Hagen wrote:
anyway, i need to think a bit about it but we do have all the info available, like
- needed width/height - original width/height
and from that we can calculate some conversion parameters
if you start thinking/working on this, some data from EXIF might be interesting and helpful too, esp. the "Orientation". using that data, automatic rotation to the "correct" orientation would be possible. maybe there are more interesting information in the exif data?! what about color space infos ? or time stamps or GPS data which might be used to be typeset...
if it would help you i can provide a tracker that will save info like this (per image):
that would be great as my current \message{} stuff is far from being perfect... Harald -- "I hope to die ___ _____ before I *have* to use Microsoft Word.", 0--,| /OOOOOOO\ Donald E. Knuth, 02-Oct-2001 in Tuebingen. <_/ / /OOOOOOOOOOO\ \ \/OOOOOOOOOOOOOOO\ \ OOOOOOOOOOOOOOOOO|// \/\/\/\/\/\/\/\/\/ Harald Koenig // / \\ \ koenig@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^
Hallo Harald, lange nicht gesehen! ;)
Am 2015-03-10 um 07:33 schrieb Harald Koenig
if you start thinking/working on this, some data from EXIF might be interesting and helpful too, esp. the "Orientation". using that data, automatic rotation to the "correct" orientation would be possible.
maybe there are more interesting information in the exif data?! what about color space infos ? or time stamps or GPS data which might be used to be typeset...
Oh yes, and then include a OpenStreetMap snippet of the location… (I’m working on an architectural guide, and I planned to put all the material in a database and use ConTeXt and Python to automatically create the book as well as an mobile app, plus a map with the building locations… But now we have a contract with a publisher, and he wants InDesign data. Since we must also use his serial layout, that makes sense. And he thinks a separate map is too expensive. Maybe I’ll create that app anyway, I already put so much work in enhancing OSM data…) Greetlings, Hraban --- http://www.fiee.net http://wiki.contextgarden.net https://www.cacert.org (I'm an assurer)
On 3/10/2015 2:33 AM, Harald Koenig wrote:
On Mar 10, Hans Hagen wrote:
anyway, i need to think a bit about it but we do have all the info available, like
- needed width/height - original width/height
and from that we can calculate some conversion parameters
if you start thinking/working on this, some data from EXIF might be interesting and helpful too, esp. the "Orientation". using that data, automatic rotation to the "correct" orientation would be possible.
maybe there are more interesting information in the exif data?! what about color space infos ? or time stamps or GPS data which might be used to be typeset...
if it would help you i can provide a tracker that will save info like this (per image):
that would be great as my current \message{} stuff is far from being perfect...
Luigi and I looked into the engine bit and decided that it makes no sense to intercept it there as it would mean obscuring possible errors. But, I can intercept it in context so that is what happens now. You will get something: LuaTeX warning: arithmetic: number too big graphics > inclusion > image './IMG_9712c1_bad.jpg' has bad dimensions (-32768pt,23849.10001pt), discarding I also added a tracker: \starttext % \pdfimageresolution300 \enabletrackers[graphics.lognames,graphics.usage] \externalfigure[IMG_9712c1_ok] \externalfigure[IMG_9712c1_bad] \stoptext btw, you can simulate some of the issues with setting \pdfimageresolution to 1-10 The tracker makes a file <jobname>-figures-usage.lya that has two subtables, one with found images, and another with how they are used, including an error flag. I'll upload a beta. Now who will wikify this ... Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On 03/09/2015 10:12 PM, Harald Koenig wrote:
any hints to read the original large JPGs, but only write "print quality" 300dpi images, or low quaity 75dpi images for speed (and saving net bandwidth when mailing PDFs to co-workers of the group)?
Hi Harald, how about converting the JPEG files with ImageMagick with two directories (such as print-quality and screen-quality)? If you use the same image file names, you could also use modes: \enablemode[print] \startmode[print] \setupexternalfigures[location=/home/user/project/img-print/] \stopmode \startmode[screen] \setupexternalfigures[location=/home/user/project/img-screen/] \stopmode \starttext \externalfigure[image-filename.jpg] \stoptext As long as you use the same filenames and the right mode, ConTeXt will choose the right file for each format. BTW, I don’t know whether ConTeXt can shrink image quality, but I think this workaround could do the job. I hope it helps, Pablo -- http://www.ousia.tk
On Mon, Mar 09 2015, Harald Koenig wrote:
is it possible that context (lua?) will "shrink" all \externalfigure jpegs automatically to some specified dpi resolution and quality (e.g. 300 dpi with 95% jpeg 'quality' for print and 100 dpi and 75% for screen quality) ?
Hi, Does this work: http://modules.contextgarden.net/grph-downsample ? (I did not test it with the latest context version...) There is no support for changing the quality, but it should be easy to add it. -- Peter
On Mar 10, Peter Münster wrote:
Does this work: http://modules.contextgarden.net/grph-downsample ? (I did not test it with the latest context version...)
There is no support for changing the quality, but it should be easy to add it.
that should great! but how do I use it ? problems with me as newbe start with installation: reading http://wiki.contextgarden.net/Modules#Installation I unzipped the file in .../context/tex/texmf/ and run "context --generate" BUT then I found the hint about first-setup.sh --modules="grph-downsample" which removed the unzipped module:-( so for now I stay with unzup and "context --generate" and do not run first-setup.sh again. what's the "real way" here ? next problem: how to use your module ? I can't find the docs and just a \usemodule[grph-downsample] doesn't seem to do the trick ?! btw, I've added your suggested patch to grph-inc.lua thanks, Harald -- "I hope to die ___ _____ before I *have* to use Microsoft Word.", 0--,| /OOOOOOO\ Donald E. Knuth, 02-Oct-2001 in Tuebingen. <_/ / /OOOOOOOOOOO\ \ \/OOOOOOOOOOOOOOO\ \ OOOOOOOOOOOOOOOOO|// \/\/\/\/\/\/\/\/\/ Harald Koenig // / \\ \ koenig@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^
On Tue, Mar 10 2015, Harald Koenig wrote:
but how do I use it ?
- Copy grph-downsample.lua to .../context/tex/texmf-local/tex/context/third/grph-downsample/grph-downsample.lua - context --generate - Copy hacker.jpg to your directory. - Write this to test.tex: --8<---------------cut here---------------start------------->8--- \loadluafile[grph-downsample] \setupexternalfigures[conversion=lowres.jpg, resolution=10] \starttext \externalfigure[hacker.jpg][width=5cm] \stoptext --8<---------------cut here---------------end--------------->8--- - Then: "context test" (I hope it works...) - Perhaps wikify it.
first-setup.sh --modules="grph-downsample"
which removed the unzipped module:-(
Unfortunately, grph-downsample is not in the context-suite. Mojca, could you add it?
what's the "real way" here ?
For now, you have to put it to texmf-local.
next problem: how to use your module ? I can't find the docs and just a
\usemodule[grph-downsample]
\loadluafile seems to do the trick, but perhaps there is an official "context-way", Hans?
btw, I've added your suggested patch to grph-inc.lua
The patch is only needed, when you change the size of the image, for example 5cm -> 6cm. Without the patch, the down-sampled file won't be regenerated. -- Peter
participants (8)
-
Aditya Mahajan -
Alan BRASLAU -
Hans Hagen -
Harald Koenig -
Henning Hraban Ramm -
luigi scarso -
Pablo Rodriguez -
Peter Münster