The Concert for piano, violin and string quartet in D major, Op.21 by Ernest Chausson is one of the most important and beautiful french chamber music pieces of the late 19th century.
Anyone as access to the score and parts ?
Chausson: Concert for piano, violin and string quartet
-
goldberg988
- forum adept
- Posts: 97
- Joined: Sun Dec 31, 2006 5:51 am
- notabot: YES
- notabot2: Bot
- Location: Tulsa, OK, USA
As a starter...
http://imslp.org/wiki/Concert_in_D_For_ ... 2C_Ernest)
http://imslp.org/wiki/Concert_in_D_For_ ... 2C_Ernest)
Actually, it is not at all grayscale, but B&W (1bit) at @600dpi. The grayscale aspect probably comes from the method I use:
(i) scan pages B&W@600dpi (stored to tiff files)
(ii) crop each page to remove useless margins (and the amount of bitmap data)
(iii) transform to pdf (acrobat)
(iv) use acrobat to remove angle problems (no resampling)
(iv) imposition step to make the pages size uniform (only bounding boxes are redefined)
After step (iii) the size of the pdf file does not significantly change.
I prefer 600dpi to 300dpi, because it can make a big difference if you plan to perform OCR with the pdf (especially for narrow staves). It's true that it is approximately equivalent if you only plan to print it.
Of course, I am opened to any suggestion that can reduce the output size.
(i) scan pages B&W@600dpi (stored to tiff files)
(ii) crop each page to remove useless margins (and the amount of bitmap data)
(iii) transform to pdf (acrobat)
(iv) use acrobat to remove angle problems (no resampling)
(iv) imposition step to make the pages size uniform (only bounding boxes are redefined)
After step (iii) the size of the pdf file does not significantly change.
I prefer 600dpi to 300dpi, because it can make a big difference if you plan to perform OCR with the pdf (especially for narrow staves). It's true that it is approximately equivalent if you only plan to print it.
Of course, I am opened to any suggestion that can reduce the output size.
Matthieu a couple of things:
(i) - After examining the images, it looks like you're letting your scanner pick the right sampling rate rather than you explicitly telling it (or it's not obeying) because the images aren't all 600dpi. They range anywhere between 590-600. If you have the option, make sure your scanner interface is set to use optical resolution (hardware) and NO software interpolation. You want the hardware to drive the image output quality with no software interference.
(ii) - A better and quicker way to do this is (if your scanner interface of some kind supports this, which most do) is to create a profile with the crop box built into it. Rather than scanning the entire surface of your scanner and cropping the resultant file, if you set the crop info. in the profile, place your pages in the same location on the bed, then the output file will be cropped to contain only the logical page data (the "print").
(iii) - In doing this step, for maximum compression on 1-bit images, use the JBIG2 compression
(iv) - Doing this step rather than on the images themselves creates artifacts on the output images after compilation and increases the filesize because Acrobat is applying a mask to the images.
(v) - Not necessary if you fix step (ii).
As far as OCR is concerned, the chances of high success on images engraved 100 years ago is not good to begin with. I wouldn't personally let this be a concern. Even vendors of the OCR (I assume you mean music OCR and not text) software specify it's hit or miss on plate-engraved music, i.e. music produced before about 1970. If your setup as I've outlined about is in-line, 300dpi (on this score) will look very good, and I would guess that changing these would cut your filesize on this Chausson score in half.
(i) - After examining the images, it looks like you're letting your scanner pick the right sampling rate rather than you explicitly telling it (or it's not obeying) because the images aren't all 600dpi. They range anywhere between 590-600. If you have the option, make sure your scanner interface is set to use optical resolution (hardware) and NO software interpolation. You want the hardware to drive the image output quality with no software interference.
(ii) - A better and quicker way to do this is (if your scanner interface of some kind supports this, which most do) is to create a profile with the crop box built into it. Rather than scanning the entire surface of your scanner and cropping the resultant file, if you set the crop info. in the profile, place your pages in the same location on the bed, then the output file will be cropped to contain only the logical page data (the "print").
(iii) - In doing this step, for maximum compression on 1-bit images, use the JBIG2 compression
(iv) - Doing this step rather than on the images themselves creates artifacts on the output images after compilation and increases the filesize because Acrobat is applying a mask to the images.
(v) - Not necessary if you fix step (ii).
As far as OCR is concerned, the chances of high success on images engraved 100 years ago is not good to begin with. I wouldn't personally let this be a concern. Even vendors of the OCR (I assume you mean music OCR and not text) software specify it's hit or miss on plate-engraved music, i.e. music produced before about 1970. If your setup as I've outlined about is in-line, 300dpi (on this score) will look very good, and I would guess that changing these would cut your filesize on this Chausson score in half.
Daphnis,
(i) the driver of my scanner may have been responsible for the fuzzy resolutions, because it is not an expensive one. But after check, my tiff files are really 1bit 600dpi. Definitely, this comes from acrobat and its mass of half hidden options.
(ii) thanks for this good point.
(iii) here I think you found the source of the problem. I have just tried to convert 1 page: using CCITT4 (default) gives 259 Ko, and moving to JBIG2 looseless gives 171 Ko. This is a 66 % decrease. I cannot figure why Adobe still puts CCITT4 as a default.
(iv) This angle step is not satisfactory. The on-screen result neither is (by the way, I am almost sure Sibley use the same trick). But its sometimes really hard to place really correctly the score on the scanne'r, and I really don't like non-horizontal stave in printed scores.
(v) see (ii)
Concerning (music) OCR, your opinion was mine 1 year ago. But, they actually made huge progress. As surprising at may seem, the OCR program gives really results even with clear handwritten music (!)
Conclusion for Chausson: I still have the tiff files, and I am currently producing a smaller version. When it's done, I'll replace my first submission.
(i) the driver of my scanner may have been responsible for the fuzzy resolutions, because it is not an expensive one. But after check, my tiff files are really 1bit 600dpi. Definitely, this comes from acrobat and its mass of half hidden options.
(ii) thanks for this good point.
(iii) here I think you found the source of the problem. I have just tried to convert 1 page: using CCITT4 (default) gives 259 Ko, and moving to JBIG2 looseless gives 171 Ko. This is a 66 % decrease. I cannot figure why Adobe still puts CCITT4 as a default.
(iv) This angle step is not satisfactory. The on-screen result neither is (by the way, I am almost sure Sibley use the same trick). But its sometimes really hard to place really correctly the score on the scanne'r, and I really don't like non-horizontal stave in printed scores.
(v) see (ii)
Concerning (music) OCR, your opinion was mine 1 year ago. But, they actually made huge progress. As surprising at may seem, the OCR program gives really results even with clear handwritten music (!)
Conclusion for Chausson: I still have the tiff files, and I am currently producing a smaller version. When it's done, I'll replace my first submission.
(iv) - Really the best way to fix for skew in images is to process them in either Photoshop (which is what I use) or a free alternative in Gimp.
Maybe I'll have to give music OCR another go. Last time I used it, I came to the conclusion that it was quicker to just manually enter everything rather than try to use any of the post-OCR files.
There's really no need to re-scan the Chausson. I, for one, am glad someone uploaded it, which means there is one less score for me to worry about when I get to completing his catalogue! Thank you again for your diligent work!
Maybe I'll have to give music OCR another go. Last time I used it, I came to the conclusion that it was quicker to just manually enter everything rather than try to use any of the post-OCR files.
There's really no need to re-scan the Chausson. I, for one, am glad someone uploaded it, which means there is one less score for me to worry about when I get to completing his catalogue! Thank you again for your diligent work!
You can do it manually by using an anchor point and then manual rotation, however I've created a few macros where I can select the degree of rotation, then apply it with one click. Generally, and if you're at all careful of your scanning process, images won't need more than about a 1 degree rotation in either direction, so I create a set for my 300dpi scans (0.5 clockwise, 1.0 clockwise, 0.5 counter, 1.0 counter) and a set of the same for 600dpi.
-
horndude77
- active poster
- Posts: 293
- Joined: Sun Apr 23, 2006 5:08 am
- notabot: YES
- notabot2: Bot
- Location: Phoenix, AZ
I highly recommend pagetools for automatic skew detection. There is even a gimp plugin based on it. On some of the more recent scanning I've been doing I scan in grayscale, deskew the image, and then convert to b&w. This avoids some of the artifacts and quality loss that can occur when rotating b&w images.
I've started some scripts to deskew each image in a pdf automatically: http://github.com/horndude77/image-scri ... ter/rotate. This is only for linux right now (possibly cygwin also), but I'm thinking about writing more of it in java (instead of shell script and c) to make it easier to run across different platforms. Also it's still using ccitt group 4 compressions. I need to look more into jbig2 compression.
I've started some scripts to deskew each image in a pdf automatically: http://github.com/horndude77/image-scri ... ter/rotate. This is only for linux right now (possibly cygwin also), but I'm thinking about writing more of it in java (instead of shell script and c) to make it easier to run across different platforms. Also it's still using ccitt group 4 compressions. I need to look more into jbig2 compression.