Switch to English Language Passer en langue française Omschakelen naar Nederlandse Taal Wechseln Sie zu deutschen Sprache Passa alla lingua italiana
Members: 70,708   Posts: 1,548,564   Online: 1115
      
Page 6 of 11 FirstFirst 1234567891011 LastLast
Results 51 to 60 of 105
  1. #51

    Join Date
    Feb 2012
    Location
    Australia
    Shooter
    Multi Format
    Posts
    45
    Hah! Yes that's why I try to keep away from computers and mains electricity - don't understand any of it.

  2. #52
    polyglot's Avatar
    Join Date
    Jun 2009
    Location
    South Australia
    Shooter
    Medium Format
    Posts
    3,285
    Images
    12
    A new release (the "eat your own dogfood" edition now that I have my new darkroom operational) is coming soon because I've fixed a couple of bugs:
    - Going into focus mode in the middle of a program or test strip no longer resets the program; that really pissed me off!
    - Foot switch (or pressing the rotary encoder) is now supported by the software
    - Serial communication is implemented and half-tested but the host-side program is not ready yet
    - Saving to Slot 7 no longer tries to write off the end of the EEPROM (!)

    I've got to do a little more testing on the serial code and will release it soon; the host program will probably be released separately later without requiring you to update the code on the timer.

    First question is, I've been considered a "dependent test strip" mode which would allow you do things like test different burn options after applying a prior sequence of exposures, or to do split-grade test-strips. I'm looking for your input on how people normally approach this kind of printing to ensure my approach is not crazy.

    I imagine the workflow to be:
    a) do first test strip, select desired exposure
    b) program that exposure
    c) do dependent test strip, select desired exposure
    d) program second exposure in
    e) rinse & repeat steps c-d until program complete.

    The intention is that a secondary exposure need not be merely a burn, it could be the second part of a split-grade print. So in step a-b you choose the magenta exposure to get a desired black then in steps c-d you select the yellow exposure to get the white point.

    The idea of a dependent test strip is that you first execute the current program and then the test strip. If you're doing a strip where each part need not represent the same point on the image, the current software is sufficient - you just run the program with the whole strip uncovered and then run the test strip, either covering as you go or exposing only small areas at each step. This approach is really unwieldy for the printing approach I've been using where each test-strip tile is an exposure of the very same part of the print, so you're comparing the same image portion across all the exposure options; you need to re-run the whole prior program before each test-strip tile.

    Let me know if you have any thoughts on how to approach this part of the workflow and what you'd like the timer to do. I could make the timer re-run the prior exposure before each individual tile (in dependent-individual mode) but it could be really confusing. I suspect it might be simpler for the operator, though more keypresses, to just have you run the program for each step then skip through the test strip to the appropriate point. Both approaches are quite error-prone I think; the only really good way I know of (for split-grade tests at least) is with a colour head under the direct control of the timer.

    The next issue to address is that my new (and probably forever) enlarger has huge warmup-time issues (nearly 1s of deadtime at warmup) that the timer doesn't account for at the moment (a constant linear time needs to be added to each exposure). This means that (for my enlarger, and many others like it), a 2 stop base exposure and 1 stop burn is notably less exposure than a single 3-stop exposure. That makes it difficult or impossible to compute a burn sequence from test strips done in various areas of the print. Optimally, you'd do a test strip at a few critical parts of the image and use those results to compute the burn sequence; that's only possible if warmup correction is present and accurate, so I think that will be coming soon. If you have an enlarging meter that can read in stops, this is a fantastic approach. You'll need a test-wedge and a spreadsheet to compute the calibration for your enlarger+paper combination.

    Next option under consideration is a "dependent burn". The timer currently assumes that all dodges/burns are with respect to the base exposure, which is great until dodge/burn areas overlap. Would you find it useful to specify that a particular burn is specific with respect to the previous program step rather than the base exposure?
    For example, you could specify this program:
    2 stop: base
    0.5 stop: first burn
    0.5 stop: second burn

    Currently, that will result in a base exposure of 4s followed by two exposures of 1.657s (for a total of 5.657 = 2.5 stops) for each burn area. What you might have intended was an exposure sequence of 4s, 1.657 and 2.343s to achieve net exposures of 2, 2.5 and 3 stops respectively, i.e. assuming that the second burn was inside the first. Let me know if this is something you'd want; it will make the Edit-Program interface more complicated but I think it will more-naturally represent some very common printing manipulations.

    All feedback and suggestions welcome!
    Last edited by polyglot; 06-19-2012 at 02:20 AM. Click to view previous post history.

  3. #53
    billdlv's Avatar
    Join Date
    Mar 2008
    Location
    Los Angeles California
    Shooter
    Multi Format
    Posts
    18
    The improvements sound great. I am making the enclosure for mine right now, hopefully it will be finished soon.

    The only one I don't really see myself using is the dependent burn/dodge. But your explanation makes sense and having that capability there should be good as long as the interface does not get too complicated.

  4. #54
    polyglot's Avatar
    Join Date
    Jun 2009
    Location
    South Australia
    Shooter
    Medium Format
    Posts
    3,285
    Images
    12
    Cheers. I think I can make the dependent-burn thing easy enough - press D to toggle "dependent/relative" on each program-step in the Edit mode, which will be represented on the screen with an R by the stop-count (D currently indicates drydown correction). I'll only be supporting dependent-with-respect-to-previous initially, which means you can nest burns as deeply as you like but you couldn't (for example) burn two separate areas within a first area.

    Secondly, host interface (from PC) user-interface design. Any thoughts welcome. It's Java so should run on Win/Linux/Mac as long as you have the libRXTX that comes with your Arduino dev environment.

  5. #55
    polyglot's Avatar
    Join Date
    Jun 2009
    Location
    South Australia
    Shooter
    Medium Format
    Posts
    3,285
    Images
    12
    Version 0.4 is now released. You can download the source here.

    This version of the timer software has USB/serial comms in it, so I intend to just release the host software when it's ready without needing to update the timer software again until it gets warmup correction functionality. The host software will be Java, so it should run on any Windows/Linux/OSX platform that supports Java 1.6, Arduino and the libRXTX library (which comes with the Arduino SDK).

    The manual still sucks, sorry. If you get stuck using the timer, email me.

  6. #56
    Mr Man's Avatar
    Join Date
    Mar 2010
    Location
    UK
    Shooter
    Multi Format
    Posts
    34
    I would like to have a go at building one of these as I need a new timer that can handel multiexposures and am in the process of converting to f-stop printing. But could you explain why this timer can only handel 7 exposures. Is it to do with the available memory on the ATmega 328.

  7. #57
    polyglot's Avatar
    Join Date
    Jun 2009
    Location
    South Australia
    Shooter
    Medium Format
    Posts
    3,285
    Images
    12
    It can handle 8 exposures per program (print) and can store 7 programs in the internal EEPROM. The global limit is that the mega328 EEPROM is 1kB and my code represents each exposure as 16 bytes: 14 chars of text plus 2 bytes of EV. And there's about 20 bytes of configuration data for the device as a whole, so you can't fit 8 programs of 8 exposures.

    If you wanted to have more-complicated exposure programs, it'd be fairly easy to change it to support 10 exposures per program and store only 6 programs (or conversely, 6 exposures per program and 10 stored programs). Beyond that it gets messier because the code assumes a single-digit keypress while in Edit-mode to specify which exposure you're modifying, so there would be some really annoying user-interface changes required to go to something like 16 exposures/program. Do you really make more than 8 or 10 separate exposures for a single print though?

    With regards to progress on the timer itself... I have a Java interface library that talks to the timer and can upload/download the EEPROM (stored print program) contents. However it has absolutely no user interface and I'm assuming other Java-hacks are pretty thin on the ground out here in analogue land so I haven't made a release. I also have some detailed plans (an XML schema) about how I want programs to be stored on a PC, so I want to release that as a complete and working whole.

    The other interesting thing is that I bought a couple of light-to-frequency converters and will be playing with those with a view to adding them to the timer as enlarger-meter functionality, maybe eventually closed-loop but that's a lot more work. If you've previously bought a PCB from me it will require a small amount of rewiring though because the light meter needs to connect to a specific pin that's currently allocated. I'll probably make up a new batch of PCBs, appropriately rewired, but that is many many months away.

    The limiting factor: I now have a 6-week old girl and it transpires that such things are remarkable time-sinks! Many of my projects are making little to no progress.

  8. #58
    Mr Man's Avatar
    Join Date
    Mar 2010
    Location
    UK
    Shooter
    Multi Format
    Posts
    34
    Thanks for the info. I've had a look at your code but it is a bit over my “BASIC” head. I do not have one of your PCBs I was just going to breadboard it up to see if I liked it before trying to produce a single sided PCB version. However the limiting factor is the number of exposures and I do regularly produce prints with more than ten exposures. So I have decided to write my own, rather less elegant, code. I have sacrificed some of the functionality, EEPROM storage and only one program, for the ability to have more exposures and corresponding grade information, for later implementation. I like the idea of transferring programs between pc and timer and will be looking at some way, maybe with Processing, to store and transfer .cvs files between timer and PC but I fear I may run out of memory before I achieve that, would be good to be able to write cleaner code. I will post the results here if any one is interested.
    I'm A photographer not an artist

  9. #59
    polyglot's Avatar
    Join Date
    Jun 2009
    Location
    South Australia
    Shooter
    Medium Format
    Posts
    3,285
    Images
    12
    Since mine is open source, you should feel free to use it as a starting-point; in fact you could keep the majority of the program by setting MAXEXP=60, LASTSLOT=1 (one program of up to 60 steps) and modifying it so that the rotary encoder moves between exposures instead of adjusting exposures. This should probably work (not tested):

    void FstopTimer::st_edit_poll()
    {
    // keypad events?
    if(keys.available()){
    char ch=keys.readAscii();
    if(isspace(ch))
    return;
    switch(ch){
    case 'A':
    // edit text
    changeState(ST_EDIT_TEXT);
    break;
    case 'B':
    // edit EV
    changeState(ST_EDIT_EV);
    break;
    case 'C':
    case 'D':
    changeState(ST_MAIN);
    break;
    case '#':
    case '*':
    exec.setProgram(&current);
    changeState(ST_EXEC);
    break;
    default:
    errorBeep();
    }
    }

    // knob events?
    int rot=rotary.getDelta();
    if(rot != 0){
    expnum+=rot;
    if(expnum < 0)
    expnum=0;
    if(expnum > 0)
    expnum=MAXEXP-1;

    current[expnum].display(disp, dispbuf, false);
    }
    }
    If you're breadboarding, I suggest buying something like eBay items 110838610978 or 271026616035. The second thing is that my current schematic is a bit stupid because it uses the INT pins for the rotary encoder while the AVR can support state-change interrupts on nearly any pin. It would be better to move the rotary encoder (if you use one) to two of the other spare pins and keep the timer-counter pins free. That will allow you to attach a light-to-frequency probe in future for use as an enlarger meter.

  10. #60
    polyglot's Avatar
    Join Date
    Jun 2009
    Location
    South Australia
    Shooter
    Medium Format
    Posts
    3,285
    Images
    12
    I had a hack on my code this evening to support much longer programs and the problem is that the AVR runs out of RAM, not just EEPROM. So my timer software is probably not a good starting point to extend to much longer programs unless you want to run it on a larger device, e.g. a mega2560 or similar.



 

APUG PARTNERS EQUALLY FUNDING OUR COMMUNITY:



Contact Us  |  Support Us!  |  Advertise  |  Site Terms  |  Archive  —   Search  |  Mobile Device Access  |  RSS  |  Facebook  |  Linkedin