Bug#711774: [exact-image] Bug#711774: exactimage: dcraw vs libraw ?
I finally rather updated dcraw and glue to latest upstream. Committed revision 1860. Greetings, René On Jun 10, 2013, at 9:01 , Mathieu Malaterre wrote: On Sun, Jun 9, 2013 at 9:08 PM, Sven Eckelmann s...@narfation.org wrote: Just a small remark at the beginning: I didn't meant dcraw upstream with dcraw guys but the Debian maintainers for dcraw. And I really think it is a good question because the package is dead since 3 years and missing some updates from upstream. (Ok, the embedded copy of dcraw in exactimage seems to be older) On Sunday 09 June 2013 19:37:03 Rene Rebe wrote: I think dcraw did all the original research and he does not want to make it a library because he believes an executable to call is the unix way and a library he could boy change so flexible. This is why I embedded the not too big code to make it a simple built in library inside exact image. This is correct, but is not really about the problem here. Just to give more insight in what Mathieu Malaterre said: Embedded copies of code are bad when used in Distributions because (just some examples): * they increase the binary size when there would be shared object that could be used instead * they increase memory usage because different programs cannot share the loaded library * they are hard to maintain Ok, the first two points are easy to understand but the last one might be quite vague. So here an explanation with two different scenarios (actually it is the same example but with different impacts): dcraw gets a new version (lets call it 9.18 for obvious reasons) with X-Trans and EOS C500 support. Now all programs using an embedded copy have to be updated in Debian to bring these versions on par with the upstream one and fix outstanding bugs/request for EOS C500/X-Trans. This is not really trivial because the programs have to be identified first and then the maintainer has to be waken up. This is a lot of work and time spend on a task that is completely unnecessary. Therefore, it is better to use the library version when available. And yes, I am fully aware that interface changes are problems which can be a negative effect when switching to external libraries. Now to the part with a little more impact. Lets assume that dcraw has a bug which can be exploited quite easily (send a prepared image which causes some buffer overflows and so on). Now it is extreme important to find all versions of the embedded copy because otherwise it is a security risk. You don't really want to provide an web service doing raw image conversions when there might be a big security hole because the security bug was fixed in the original program/library but not in the embedded copy. So back to the main questions. Do you see a possible way to switch from your dcraw version to libraw and make more of the embedded copies optional? I know, the embedded copies from libjpeg for jpeg rotation are for example really hard because libjpeg doesn't export the necessary stuff. But it seemed to have caused some headaches for the previous maintainers of this package because no one updated the embedded copy of jpegint/transupp and it just crashed when used together with never versions of libjpeg like libjpeg8. And the current one in exactimage upstream still does. Very well summarized, Sven ! Security was mostly my main objection, since exactimage offer perl, python and php5 bindings it is quite likely this will be used on webserver, therefore security risk is not anymore just a theoretical issue. Regards, -- ExactCODE GmbH, Jaegerstr. 67, DE-10117 Berlin DE Legal: Amtsgericht Berlin (Charlottenburg) HRB 105123B, Tax-ID#: DE251602478 Managing Director: René Rebe http://exactcode.com | http://exactscan.com | http://ocrkit.com | http://t2-project.org | http://rene.rebe.de
Bug#711774: [exact-image] Bug#711774: exactimage: dcraw vs libraw ?
Hi, On Jun 10, 2013, at 9:01 , Mathieu Malaterre wrote: On Sun, Jun 9, 2013 at 9:08 PM, Sven Eckelmann s...@narfation.org wrote: Just a small remark at the beginning: I didn't meant dcraw upstream with dcraw guys but the Debian maintainers for dcraw. And I really think it is a good question because the package is dead since 3 years and missing some updates from upstream. (Ok, the embedded copy of dcraw in exactimage seems to be older) On Sunday 09 June 2013 19:37:03 Rene Rebe wrote: I think dcraw did all the original research and he does not want to make it a library because he believes an executable to call is the unix way and a library he could boy change so flexible. This is why I embedded the not too big code to make it a simple built in library inside exact image. This is correct, but is not really about the problem here. Just to give more insight in what Mathieu Malaterre said: Embedded copies of code are bad when used in Distributions because (just some examples): * they increase the binary size when there would be shared object that could be used instead * they increase memory usage because different programs cannot share the loaded library * they are hard to maintain Ok, the first two points are easy to understand but the last one might be quite vague. So here an explanation with two different scenarios (actually it is the same example but with different impacts): dcraw gets a new version (lets call it 9.18 for obvious reasons) with X-Trans and EOS C500 support. Now all programs using an embedded copy have to be updated in Debian to bring these versions on par with the upstream one and fix outstanding bugs/request for EOS C500/X-Trans. This is not really trivial because the programs have to be identified first and then the maintainer has to be waken up. This is a lot of work and time spend on a task that is completely unnecessary. Therefore, it is better to use the library version when available. And yes, I am fully aware that interface changes are problems which can be a negative effect when switching to external libraries. Now to the part with a little more impact. Lets assume that dcraw has a bug which can be exploited quite easily (send a prepared image which causes some buffer overflows and so on). Now it is extreme important to find all versions of the embedded copy because otherwise it is a security risk. You don't really want to provide an web service doing raw image conversions when there might be a big security hole because the security bug was fixed in the original program/library but not in the embedded copy. So back to the main questions. Do you see a possible way to switch from your dcraw version to libraw and make more of the embedded copies optional? I know, the embedded copies from libjpeg for jpeg rotation are for example really hard because libjpeg doesn't export the necessary stuff. But it seemed to have caused some headaches for the previous maintainers of this package because no one updated the embedded copy of jpegint/transupp and it just crashed when used together with never versions of libjpeg like libjpeg8. And the current one in exactimage upstream still does. Very well summarized, Sven ! Security was mostly my main objection, since exactimage offer perl, python and php5 bindings it is quite likely this will be used on webserver, therefore security risk is not anymore just a theoretical issue. Well, the dcraw author is the authority when it come to RAN reverse engineering. I would rather use his, than some other random library. That it is not a real library, and the ongoing compatibility breakage of libpng and libjpeg is very unfortunate, but honestly not my construction site. After all my decade of excessive open source work and contribution I'm left vastly disappointment by all this movements, incompatibly, breakage and flamewars. In the end all the big companies like Google, Facebook, IBM, Oracle and others just make the big money of all our work there. I'm afraid I can not longer donate my short life to their profit and thus mostly do other stuff now, like for Mac and even Windows. I adapt ExactImage to new library versions as time allows, but unfortunately the random breakage and incompatibility mess does not motivate me too much to look into things like that. Patches welcome. René -- http://exactcode.com | http://exactscan.com | http://ocrkit.com | http://t2-project.org | http://rene.rebe.de
Bug#575324: [exact-image] Re: exactimage: file format misdetection
Hi, thanks, applied, too. René On 30.03.2012, at 12:57, Sven Eckelmann wrote: tags 575324 + patch thanks On Wednesday, March 24, 2010 10:40:32 PM you wrote: Package: exactimage Version: 0.7.5-3 Severity: minor y.pbm is a perfectly valid PBM file: $ edentify y.pbm TGA: 80, 10, 1, 52, 255, 65343, ÿ y.pbm: TARGA 255x65343 0 bit, 3 channels The problem seems to be that the TARGA codec is added too early to the codec datastructure. I worked around that problem using different strategies to insert the codec. Kind regards, Svenmissing_include_vector.patchedentify_tga_mismatch.patch--- If you wish to unsubscribe from this mailing, send mail to li...@exactcode.de with a subject of: unsubscribe exact-image -- René Rebe, ExactCODE GmbH, Jaegerstr. 67, DE-10117 Berlin DE Legal: Amtsgericht Berlin (Charlottenburg) HRB 105123B, Tax-ID#: DE251602478 Managing Director: René Rebe http://exactcode.com | http://t2-project.org | http://rene.rebe.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#474706: HP5300C, some progress?
Hi, Bert Verbeek wrote: Op Friday 11 July 2008, schreef René Rebe: Hi Julien, Patches, especially for stuff I can not reproduce welcome. Hello Rene, first of all, thanks for your time in advance. As I like to get this scanner going again, I started today reading in the tree of the debian sane-backends source package. For your info: I'm a scientist with C++ experience in number-crunching, not in programming devices, but I'm willing to learn ... I found the 'sane-backends-1.0.19/frontend/tstbackend.c' program, liked it for simpleness as a starter and compiled it. ./tstbackend -l 1 -r 0 gives: -- tstbackend, Copyright (C) 2002 Frank Zago tstbackend comes with ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under certain conditions. See COPYING file for details This is tstbackend build 18 TEST: init/exit using device avision:libusb:004:002 TEST: open/close TEST: options consistency ERROR : cannot set option [25, power-save-time] value, although it is active and settable (Error during device I/O) ERROR : cannot set option [25, power-save-time] value, although it is active and settable (Error during device I/O) ERROR : cannot set option [27, nvram-values] value, although it is active and settable (Invalid argument) ERROR : cannot set option [27, nvram-values] value, although it is active and settable (Invalid argument) ERROR : cannot set option [27, nvram-values] value warnings: 0 error: 5 checks: 1140 testing option 25 and up, takes a lot of time. After this usb access is messed up. the next call to tstbackend -l0 gives: tstbackend, Copyright (C) 2002 Frank Zago tstbackend comes with ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under certain conditions. See COPYING file for details This is tstbackend build 18 TEST: init/exit ERROR : no SANE devices found warnings: 0 error: 1 checks: 28 - rmmod uhci-hcd; modprobe uhci-hcd, makes the scanner react again, without rebooting. Is this info helpfull Rene? Is it consistent with the HP5300C you own? I will dig further and try to understand what is going on, but any guidance in the digging is of course welcome. Bert Hm, have not used this test thing for ages, probably should give it a try and fix the special nvram and power-save-time. I'm right now quite busy, but I recall some user reported long delays using xsane, so maybe resetting tons of options takes some time. I can some other day check on my side, for your bug hunting I woudl strongly recommend starting with simple scans using xscanimage instead of this massive random option tweaking. Yours, -- René Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474706: HP5300C, some progress?
Hi Julien, Julien BLACHE wrote: Bert Verbeek [EMAIL PROTECTED] wrote: Hi, So the segfault is gone, but the xsane program is still not working for my HP5300C. I've got no reply from Rene in weeks, so... Yeah, probably as raw scanning works for me (tm) on my HP5300, HP7400, and the 20++ Avision scanners I have over here. Patches, especially for stuff I can not reproduce welcome. Yours, -- René Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474706: xsane segfaults when trying a preview or scan
Hi, yes, same issue as with the 7400 on the sane list. Somehow some code chunks, including variable assignment where lost while merging before the last major release. I promissed to commit the fixes, and still plan to to do some just in some minutes(++) after evening dinner. Yours, Julien BLACHE wrote: Bert Verbeek [EMAIL PROTECTED] wrote: Hi, Rene, this is a issue with the HP 5300C and avision in 1.0.19. See below for the tail of the log, the full log is on bugs.debian.org. Thanks for responding so quickly. The tests in Lenny give: [EMAIL PROTECTED]:~$ scanimage out.pnm scanimage: received signal 15 scanimage: trying to stop scanner scanimage: received signal 15 scanimage: aborting So no segfault with scanimage, the corresponding scan.log you asked for is attached. OK, good to know. There's a condition XSane doesn't handle properly. Unfortunately I don't have a debug package for xsane. Can you rebuild XSane with debugging symbols and try to obtain a backtrace? [avision] normal_calibration: using color calibration [avision] get_calib_data: type 62, size 167076, chunk_size: 167076 [avision] get_calib_data: Reading 167076 bytes calibration data [avision] Timeouts: write: 3, read: 3, status: 1 [avision] try to write cmd, count: 10. [avision] wrote 10 bytes [avision] try to read 167076 bytes [avision] read 167076 bytes [avision] avision_usb_status: timeout 1, 1 retries [avision] == (interrupt read) going down ... [avision] == (interrupt read) got: 1, status: 0 [avision] get_calib_data: Got 167076 bytes calibration data [avision] sort_and_average: [avision] sane_start: perform calibration failed: Out of memory Now, that looks weird :) [avision] do_cancel: scanimage: received signal 15 scanimage: trying to stop scanner [avision] sane_cancel: [avision] do_cancel: scanimage: received signal 15 scanimage: aborting JB. -- René Rebe - ExactCODE GmbH - Europe, Germany, Berlin Geschäftsführer: Susanne Klaus, René Rebe Sitz: Berlin, Amtsgericht Charlottenburg HRB 105 123 B USt-IdNr.: DE251602478 http://exactcode.de | http://t2-project.org | http://rene.rebe.name
Bug#443254: sane: Scanner heads goes too far, bangs against frame (HP ScanJet 7400C)
Hi, I can not reproduce the crashing head on my side, however I know about the stripes, those color stripes are a regression from calibration changes in the avision backend. I so far had no time to track them down, However with some C knowledge and some trial'n error or SVN change review it should be possible to track it down in some hours. The calibration worked on the 7400 when I implemented 74xx support like 4 years ago or so :-) Can the reporter try my latest development code from: http://svn.exactcode.de/sane-avision/trunk/backend/ to see if the crashing head issue disappears? On Saturday 22 September 2007 13:35:41 Julien BLACHE wrote: reassign 443254 libsane 1.0.18-5 thanks Sebastien Desreux [EMAIL PROTECTED] wrote: Hi Rene, Could you have a look at the following bug report for avision in SANE 1.0.18 ? Thanks. This report is written with regard to the HP ScanJet 7400C scanner (avision driver). When scanning with 'scanimage', it seems that the first scan of the day always sends the head (the moving part) too far, until it collides with the plastic frame at the bottom. I tried uncommenting the line option force-a4 in /etc/sane.d/avision.conf but the result is the same. Interestingly, after the first failure, shutting down the scanner and powering it again, subsequent scans are OK. There is also a vertical band of approximately 1cm that is not really scanned; it's weird: bright colors appear, but white patches look like they didn't exist. This problem is independent from the first, it shows on all scans. I happen to have a (fully paid) commercial version of the program Vuescan made especially for Linux; none of the two problems mentionned above appear with this software. I would really prefer to use scanimage of course, not least for the scripting capabilities and the better rendering... Scanimage worked great with my old ScanJet 6300C. JB. -- René Rebe - ExactCODE GmbH - Europe, Germany, Berlin Geschäftsführer: Susanne Klaus, René Rebe Sitz: Berlin, Amtsgericht Charlottenburg HRB 105 123 B USt-IdNr.: DE251602478 http://exactcode.de | http://t2-project.org | http://rene.rebe.name
