Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Program should not modify input data #12

Open
ospalh opened this issue Mar 14, 2015 · 2 comments
Open

Program should not modify input data #12

ospalh opened this issue Mar 14, 2015 · 2 comments

Comments

@ospalh
Copy link
Contributor

ospalh commented Mar 14, 2015

In my opinion the step mogrify -colorspace gray -depth 1 "NN.tif" should not be done. It should be done as convert, writing the depth 1 image to a temporary file. (As /tmp/ may be too small perhaps a temp folder in the working directory should be used?)

The program should not modify the input data without clearly stating that. What if i like my bitonal images with higher depth. What if i like the modification time of my images. What if i want to keep the raw images, but don't want them backed up twice, once before the djvubind run, once after it.

P.S.: I have started using pgmagick. Works well for me.
(copy-edited)

@strider1551
Copy link
Owner

First off, I am honestly sorry that you experienced some data loss with djvubind from #11 when you interrupted it's execution.

You are correct that modifying input data is a bad idea, and one of my intentions was to never have djvubind do any image processing, even for the sake of better compression. In the case of modifying bit depth, that was a duct tape patch. If I remember correctly, either jb2 or minidjvu would get very upset if the bit depth was more than 1 even though the images were bitonal. This was a quick fix that I didn't think would matter much to anyone. Like you noticed, with #8 this is a bigger issue because it's doing this unnecessarily. But even without #8, I agree that it needs to at least be changed to a convert.

Unfortunately, my professional life will be at a busy peak for the next three weeks. Everytime I say that I manage to eek out a few minutes to fix things, but fair warning that it might not be a rapid fix.

@ospalh
Copy link
Contributor Author

ospalh commented Mar 14, 2015

I can work around this (i now work on a copy of the images) so no hurry.

Btw, that i report problems here of course means that i like the program.
So, thanks for the great work so far.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants